1. PHP / Говнокод #26483

    +1

    1. 1
    2. 2
    3. 3
    /index.php/module/action/param1/${@die(md5(HelloThinkPHP))}: 1 Time(s)
           /index.php?s=%2f%69%6e%64%65%78%2f%5c%74%6 ... %6e%6b%50%48%50: 1 Time(s)
           /index.php?s=/module/action/param1/${@die( ... elloThinkPHP))}: 1 Time(s)

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

    Запостил: MAKAKA, 09 Марта 2020

    Комментарии (112) RSS

    • сео
      пых
      Ответить
    • https://securitynews.sonicwall.com/xmlpost/thinkphp-remote-code-execution-rce-bug-is-actively-being-exploited/

      ThinkPHP has fixed the vulnerability by having additional checks using regular expression.




      ахахаххах
      блядь
      https://securitynews.sonicwall.com/wp-content/uploads/2018/12/ThinkPHP.png
      Ответить
      • Какой багор )))
        Ответить
      • А как уязвимость работает? Там что, eval делают?
        Ответить
        • да, там гетом передается имя класса

          The url query given below gets parsed by using the separator character ‘/’. Ideally controller class should not take ‘\’ in the name. Because of the existing bug, ‘\think\app’ is parsed as controller class name and ‘invokefunction’ as the function. It then creates an instance of the controller class ‘App’ within ‘think’ and then calls the method ‘invokefunction’. ‘invokefunction’ can take arbitrary function as its argument, allowing threat actors to perform remote code execution.
          Ответить
          • Тогда странный фикс с проверкой рагуляркой. Если у меня есть контролллер RM с методом rf_no_preserve_root?
            Ответить
            • Ну тогда ты сам виноват, что этот метод опубликовал и админские права не затребовал...
              Ответить
              • А метод ${die(huipizda())} я тоже публиковал и права не затребовал?
                Ответить
                • А это уже другая уязвимость, походу. guest8, имхо, о второй строке писал где всё в процентиках.
                  Ответить
            • То ты профессианальный разработчик апи.
              Ответить
      • > using regular expression

        Проверяют наличие HelloThinkPHP в аргументах?
        Ответить
        • Судя по мр там до этого вообще ничего не проверялось. Сказочный долбоёбфреймворк.
          Ответить
      • да там вообще много прекрасного

        https://github.com/top-think/framework/blob/6.0/src/tpl/think_exception.tpl

        какой темплейт ))

        https://github.com/top-think/framework/blob/6.0/src/think/facade/Console.php

        какой фасад ))
        Ответить
        • >> какой темплейт ))

          Странно, что в темплейте нет «SQL».

          >> какой фасад ))

          class Console extends Facade
          {
              protected static function getFacadeClass()
              {
                  return 'console';
              }
          }


          ООП гойловного мозга. Ни один метод ничего не делает, все только возвращают чьи-то имена. Даже не знаю, что лучше: спагетти из goto или спагетти из делегаций.
          Ответить
          • зато в шаблоне есть css и javascript

            проблема тут не в самом ооп, а в его кривом использовании
            Класс из одного статического метода, возвращающего строку-константу, существовать не должен.
            Ответить
            • Культ карго же. Насмотрелись на джавистов и теперь обмазываются классами.
              Ответить
              • Да, именно. Больше extends и implements, причем каждый класс вынесен в отдельный файл.

                А код все равно говно: самолеты из палочек не летают.
                Причем даже джависты уже такой хуйни не делают
                Ответить
                • Именно поэтому я за «PHP».
                  Ответить
                • > отдельный файл

                  Ага, и отдельные каталоги под контроллеры, вьюхи и т.п. Зачем? Зачем?
                  Ответить
                  • «MVC» не нужен. «Конардо» вообще всё пишет в один файл и течёт.
                    Ответить
                    • Плюсую. "MVC" - оверенжиниринг чуть менее, чем всегда.

                      В подавляющем большинстве случаев нужно деление на "логику" и "представление".

                      Всё прочее деление - последовательное деление "логики" и "представления" на их составляющие вплоть до квантов кода (деление "логики" на "подлогики" и "представления" на "подпредставления" и/или "логики" на "подлогику логики" и подпредставление логики", а "представления" на "подлогику представления" и подпредставление представления").

                      "Логика", "представление" и иерархия разбиения кода естественным образом в большинстве проектов, а отдельные слои "M", "V", "C" - нет.

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

                      Мудрый подход используют программисты на "PHP", создавая свои фреймворки. Когда их проект созрел до выделения какой-то идеологии, они пишут фреймворк, проповедующий эту идеологию.
                      Таким образом, одностраничное говно не успевает обрасти идеологией, родить фреймворк и заставлять следующего программиста копаться в этом говне. Для мелкого говна и городить фреймворк-то будет лень. А в более сложных проектах появляется фреймворк, который красиво дополняет суть проекта, черпает идеологию из предметной области и т.д.
                      Ответить
                      • Подтверждаю.
                        Причём топлива для блядского цирка добавляет то, что в «MVC» регулярно находят Фатальный Недостаток, в результате чего рождаются «MVP», «MVVM» и ещё М-хуй-знает-что в тысячах вореаций, а программисты вместо программирования занимаются натягиванием логики на модные баззворды.
                        Ответить
                        • Это всё программисты с двумя вышками из http://govnokod.ru/26472#comment532310, инфа сотка!

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

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

                          _____________________
                          * При шизофрении происходит "расстройство классификации". Абстрактное мышление пациента разрабатывается до такого состояния, что в нём можно спрятать банку сгущёнки, ибо у неё находятся тысячи логичных признаков сходства с любым другим объектом, из которых можно выделить несколько основных уровня "у банки сгущёнки и у X совпадает количество единичных битов в контрольной сумме их названия".
                          Ответить
                          • Именно поэтому я за «AnalPerOral».

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

                            Имхо, это всё тот же новичок, только начитавшийся про абстракции.

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

                                На самом деле есть три стадии развития программиста

                                Новичок срал на архитектуру: он пишет кашу из ui и логики в одном файле index.php, и течет

                                Среднячок начитался книжек про паттерны и пытается выдавить красивое решение, но пока не умеет этого делать. Его код может состоять из сотен классов, аккуратно разложенных в папочки с названиями типа businessLayer, uiLayer итд, но код всё равно полное говно, он хрупкий, а не гибкий. А если и гибкий, то совсем не там, где надо. Он удачно сочитает в себе ковбойский стиль и оверинжиниринг.

                                И только мудрый программист понимает, что абстракции не даются бесплатно, и что иногда действительно нужно много классов и сложные самописные фреймворки, а иногда правда лучше написать скрипт на 10 строчек, и не выебываться.
                                Ответить
                                • https://willamette.edu/~fruehr/haskell/evolution.html
                                  Ответить
                                  • -- explicit type recursion based on functors
                                    
                                    newtype Mu f = Mu (f (Mu f))  deriving Show
                                    
                                    in      x  = Mu x
                                    out (Mu x) = x
                                    
                                    
                                    -- cata- and ana-morphisms, now for *arbitrary* (regular) base functors
                                    
                                    cata phi = phi . fmap (cata phi) . out
                                    ana  psi = in  . fmap (ana  psi) . psi
                                    
                                    
                                    -- base functor and data type for natural numbers,
                                    -- using a curried elimination operator
                                    
                                    data N b = Zero | Succ b  deriving Show
                                    
                                    instance Functor N where
                                      fmap f = nelim Zero (Succ . f)
                                    
                                    nelim z s  Zero    = z
                                    nelim z s (Succ n) = s n
                                    
                                    type Nat = Mu N
                                    
                                    
                                    -- conversion to internal numbers, conveniences and applications
                                    
                                    int = cata (nelim 0 (1+))
                                    
                                    instance Show Nat where
                                      show = show . int
                                    
                                    zero = in   Zero
                                    suck = in . Succ       -- pardon my "French" (Prelude conflict)
                                    
                                    plus n = cata (nelim n     suck   )
                                    mult n = cata (nelim zero (plus n))
                                    
                                    
                                    -- base functor and data type for lists
                                    
                                    data L a b = Nil | Cons a b  deriving Show
                                    
                                    instance Functor (L a) where
                                      fmap f = lelim Nil (\a b -> Cons a (f b))
                                    
                                    lelim n c  Nil       = n
                                    lelim n c (Cons a b) = c a b
                                    
                                    type List a = Mu (L a)
                                    
                                    
                                    -- conversion to internal lists, conveniences and applications
                                    
                                    list = cata (lelim [] (:))
                                    
                                    instance Show a => Show (List a) where
                                      show = show . list
                                    
                                    prod = cata (lelim (suck zero) mult)
                                    
                                    upto = ana (nelim Nil (diag (Cons . suck)) . out)
                                    
                                    diag f x = f x x
                                    
                                    fac = prod . upto

                                    А мы тут гыгыкаем над метапрограммированием в крестах.
                                    Ответить
                                  • А, так вот что в ответ слал Мартин Алексеевич
                                    Ответить
                        • Зоопарк терминологии и правда бесит, но сам MVC не виноват.

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

                          Контроллер (вьюха в терминлогии джанги) принимает HTTP запросы или клики пользователя, и дергает нужные модели.

                          View (template в терминологии джанги) превращает результат в HTML, Swing, you name it.

                          В MVP все тоже самое, но вью там более пассивное и тупое.

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

                          Есть еще подход с байндингами модели ко вью (как в wpf), и наконец между контроллером и моделями может стоять service layer, представляющий API системы, проверяюзий пермишены итд.

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

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

                            Подтверждаю.
                            Ответить
                          • > В любой больмень сложной системе именно так оно и есть
                            Мне кажется, либо система слишком простая, чтобы этого там в явном виде не было, либо более сложная, где надо делить более сложно.

                            > Готовые фреймворки вроде джанги или спринг мвц представляют тебе бест практисес, заставляя даже макаку писать более-ли-менее логично
                            Ну так себе бест практисес уровня двача тематических форумов, где велосипедисту, желающему послушать музыку во время покатушек, предлагают продать Каму и купить Ультрапитух 9000 Горный Игровой с дисковыми тормозами и плазменным ускорителем, а музыку слушать вместо анскильных наушников дома со стационарных колонок за 20000 рублей (естественно, белорусских).
                            Ответить
                      • Пиздёж и провокация! MVC отличная парадигма, которая изящно представлена во фреймворке ларавель! Я реализовал собственноручно oauth2 протокол используя великолепный laravel/passport! И там всё безопасно, нанятые нами пентестеры не нашли совсем никаких уязвимостей! Я люблю принципы S.O.L.I.D. и классы с одним статичным методом! Я с огромной любовью использую фасады повсеместно и уникальный в своей гениальности орм Eloquent!

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

                          Попросили токаря и программиста сделать прямоугольный параллелепипед 10*20*30.

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

                          Программист взял шаблоны C++, кучу паттернов проектирования, boost, пару фреймворков, иерархическую файловую систему и отдельный сервер под репозиторий системы контроля версий. Попросил новый штеуд под IDE и компилятор. Взял два компилятора - предварительный и JIT. Создал синглтон, несколько пакетов, написал отдельный модуль для хранения конфигураций размеров, развёл иерархию с виртуальными методами. Реализовал многомерный гиперкуб со скруглёнными углами. Использовал декартово произведение и матричные формулы. При попытке объяснить, что гиперкуб n*n*...*n никак не может стать прямоугольным параллелепипедом 10*20*30, и за скруглённые углы никто не заплатит, начал ворчать что-то про вредных заказчиков и соответствие его кода Священным Паттернам и расширяемость на любое измерение.

                          P.S. Когда программист узнал, что токарь выточил прямоугольный параллелепипед на станке для работы с телами вращения, начал рассказывать, что токарь врёт, и это на самом деле цилиндр с нарисованными рёбрами, и вообще заказчику на самом деле нужен только гиперкуб.
                          Ответить
                          • И во всей этой питушне виноваты заказчики.

                            Потому что те программисты, которые просто берут и вытачивают параллелепипед 10*20*30, неизбежно оказываются в ситуации, когда заказчику вдруг оказывается надо пирамиду 15*42*265.

                            Ну и ещё отчасти виновата лень программистов, потому что они не хотят каждый раз вытачивать параллелепипед x*y*z, они хотят выточить многомерный гиперкуб один раз, а потом нажать одну кнопку и получать любые конфигурации выпуклых трёхмерных фигур любого размера.
                            Ответить
                            • Программирование оторвано от реального мира. Это менеджмент, а не выполнение работы конечным исполнителем. Если бы программист каждый раз сам выполнял свой код вместо компьютера, он бы всегда писал по-царски.
                              Ответить
                              • Нет никакого смысла в рассмотрении программирования в отрыве от реального мира.
                                Развитие программирования — это, в сущности, эволюционный процесс, главным критерием естественного отбора в котором является общая эффективность выполнения нужд заказчиков. При этом эффективность — параметр комплексный, включающий в себя и скорость разработки, и скорость работы конечной программы, и простоту обучения, и сложность поддержки, и надёжность решения, и много чего ещё. Разумеется, оптимизация каждого из этих параметров по отдельности совершенно не обязательно ведёт к улучшению общей эффективности, скорее даже наоборот.

                                Хороший пример работы этого процесса — «PHP»: в области разработки гостевух он имеет практически идеальные значения указанных параметров (быстрая разработка, крайне простое обучение => много программистов, а на все остальные параметры в этой области похуй).

                                Поэтому всё, на чём мы пишем, так или иначе, прямо или косвенно, является результатом выполнения желаний заказчиков.
                                Ответить
                                • Да, но нет. Я же говорю, программист только командует, но ничего сам не делает. Пока из реального мира не придут и не предложат самому грузить байты или обуздать обосравшийся "электрон", он так и будет оптимизировать длину кода и писать код стихами. Компьютер всё стерпит, время выполнения кода для программиста - величина косвенная, которая связана с его зарплатой как карма на х-ре с уровнем скилла.
                                  Ответить
                                  • В принципе, я не спорю с тем, что большинство* программистов — анскильные макаки. Правило 95% распространяется на любую произвольно выбранную группу, да.
                                    Беда не в том, что они есть. Беда в том, что они востребованы.
                                    А те немногие, которым не похуй на скорость выполнения и потребление ресурсов (они есть, не всё так плохо), вынуждены прозябать в очень узких областях и использовать инструменты, которые специально спроектированы для анскильных макак.

                                    *по результатам исследования ООО «НИИ ХУЯ» от 42.13.2021
                                    Ответить
                                • Или вот плиточник. Он один раз положил плитку красиво, второй раз положил плитку красиво, третий раз положил плитку красиво, так и до пенсии ложил плитку красиво. Когда его просили менять цвет плитки в комнате, он перекладывал плитку красиво в целой комнате.

                                  А программист один раз сделал код красиво, а он 100000 раз запустился, хотя программист не писал код остальные 99999 раз красиво. Когда его попросили переделать цвет менюшки, он не написал код красиво, а изменил строку кода, который потом ещё 1000000 раз запустился, хотя код был написан целиком только раз.

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

                                  Программирование - питушня, оторванная от мира.
                                  Ответить
                                  • Программирование — питушня, оторванная в область дипломатии.
                                    Ответить
                                    • Вот конкретное программирование. Реальное программирование тоже самое
                                      Ответить
                                      • Именно поэтому я за «реальный режим».
                                        Ответить
                                        • Подтверждаю. Заедушных анскиллябров в те времена было куда меньше, софт работал на шести сотках килбайт памяти, игры были интереснее, трава вкуснее, молоко выше,
                                          Ответить
                                  • Плохая аналогия. С тем же успехом это может быть автомобиль, который один раз сделали красиво, а потом катались на нём 100000 километров.

                                    Просто IT — это область, в которую крайне органично вписывается автоматизация (в том числе и из-за «ГОМОИКОННОСТИ»).
                                    Ты думаешь, что если бы у плиточника была волшебная машинка, которая по нажатию на одну кнопку перекрашивала все плитки во всей комнате, он бы ей из принципа не пользовался? Нет. Автоматизация рутины — это совершенно естественный процесс, присущий не только IT, но и абсолютно любой области человеческой деятельности.
                                    Ничего оторванного от мира в автоматизации нет.
                                    Ответить
                                    • Волшебная машинка должна была бы пройти расстояние, равное чему-то вроде отношения площади комнаты к площади кисти. А это джоули. Она должна поднять краску на высоту от пола до потолка, и это снова джоули.

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

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

                                      Поэтому плиточнику через годы будет нужна энергия на чудо-машинку, а программисту - только на поддержание мыслительной деятельности, т.к. анскильный мозг так и будет потреблять сотню ватт, тогда как аналогичный по мощности компьютер уже будет помещаться в часы, питаемые батарейкой из картофелины.
                                      Ответить
                                      • > Ворочать битами же можно почти бесплатно.
                                        Отнюдь не бесплатно. В реальном мире энергопотребление компьютеров — серьёзная проблема, в немалой степени ограничивающая рост производительности.
                                        Да, в теории, нижний предел характерной энергии, необходимой для переключения битов, находится в планковских районах.
                                        А вот на практике мы уже вплотную подошли к размерам, на которых квантовое туннелирование разрушает любые вычисления (это размеры транзисторов порядка нанометра). Скорость света компактизацией победить не получится по тем же причинам.

                                        > Информации как таковой в нашем мире не существует.
                                        > мира идей
                                        Оторванная от реального мира питушня. Как ты себе представляешь информацию, не имеющую никакого физического отображения? Такой «информации» в принципе существовать в реальном, физическом мире не может. Любая «идея» — это как минимум уникальная конфигурация нейронов в мозгах её создателя.

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

                                        Я всё никак не пойму, к чему ты клонишь. Да, создание программы может быть менее энергозатратно, чем создание какого-нибудь физического продукта (а может и не быть, кстати). Ну и что? Как из этого следует вывод, что автоматизация создания физических продуктов — ОК, а автоматизация создания программ — не ОК и вообще оторвано от мира?
                                        Ответить
                                        • > на практике
                                          В текущей реализации. У нас ещё остаются другие методы реализации, как минимум - оптушня и квантушня.
                                          В квантушне ещё уважают обратимые операторы, ведь только с ними можно написать царский код. Необратимый код так или иначе теряет информацию, а значит и энергию

                                          > Как ты себе представляешь информацию, не имеющую никакого физического отображения?
                                          Я представляю не её саму, а работу с ней. Как вселенский Интернет или устройство, замапленное в память. На материю налипают не сгустки информации, а информационные трубы, ведущие в мир идей.
                                          То есть есть у тебя жёсткий диск. Ты записываешь в первый сектор адрес, затем стираешь диск, чтобы считать информацию из трубы. После этого читаешь диск, а там отображение информации по нужному вселенскому адресу.

                                          > автоматизация создания физических продуктов — ОК, а автоматизация создания программ — не ОК и вообще оторвано от мира?
                                          Потому, что мир принципиально материален, а информация - нет. Оптимизация физикушни - перенаправление энергии (трата энергии не слабого человека, а сильных машин), а оптимизация программушни - уменьшение затрачиваемой энергии (трата энергии не на горячие лампы, а на процессор с пометкой U). Оптимизация физикушни будет всегда стоить примерно столько же, а оптимизация физикушни будет только дешеветь, либо достигнет точки, когда обменный курс массы будет I = m c^2 или больше.
                                          Ответить
                                          • > оптушня
                                            Те же самые проблемы.

                                            > квантушня
                                            Другие проблемы, до сих пор нерешённые. Некоторые учёные вообще сомневаются, что квантовые вычисления в принципе возможны в том виде, в котором их представляют маркетологи.

                                            > ведущие в мир идей
                                            Но ведь никакого «мира идей» не существует, во всяком случае, в рамках науки. А размышления о параллельных мирах несколько не состыкуются с изначальным тезисом о том, что программирование оторвано от реального мира.

                                            > а информация - нет.
                                            Но ведь я уже объяснил, что в реальном мире — в том, где мы живём — информация в любом случае будет выражена физическими объектами. Никаких Вселенских Интернетов, из которых нам магическим образом приходят знания, не существует.

                                            Ну да, мы можем до некоторых пределов оптимизировать затрачиваемую на вычисления энергию. И что?
                                            Чем принципиально отличается программист, автоматизирующий создание программы, от кузнеца, автоматизирующего создание лопат? В конечном итоге что первый, что второй просто нажимают кнопку и получают конечный продукт. Да, они затрачивают на это разное количество энергии. Но, например, создание самосвала требует на порядки больше энергии, чем создание лопаты. Из этого же не следует, что создание лопат оторвано от реального мира?
                                            Ответить
                                            • > Никаких Вселенских Интернетов, из которых нам магическим образом приходят знания, не существует.
                                              Нет. Это современной науке не удалось открыть вселенские интернеты.
                                              Нельзя доказать отсутствие вселенских интернетов, тогда как для доказательства их наличия достаточно всего лишь одного воспроизводимого эксперимента.

                                              > Чем принципиально отличается программист, автоматизирующий создание программы, от кузнеца, автоматизирующего создание лопат?
                                              Хороший вопрос. Вероятно, ничем.

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

                                              Кузнец своими/чужими делает сразу то, что нужно, программист своими/чужими руками делает не то, что действительно нужно, а то что косвенным путём решит задачу (например, намагничивание и испускание волн для автоматизации финансовой деятельности).

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

                                              > Из этого же не следует, что создание лопат оторвано от реального мира?
                                              Великолепно!

                                              Мне кажется, стоит ввести нормировочные коэффициенты вроде энергии или массы на штуку или пользу. Тогда самосвал будет стоить производителю чуть больше чем лопата, но не на порядки, а информациушня - всё ещё на порядки меньше. Или же наоборот, килограмм самосвалов и лопат будет где-то на одном уровне, а за килограмм программ можно будет отдать очень много.
                                              Ответить
                                              • Тут в игру вступают чайник Рассела и критерий Поппера. Сущность «Вселенские Интернеты» можно эквивалентным образом заменить на сущность «Аллах», по воле которого на жёстком диске образуются битики с гей-порно. Это ничего не изменит.
                                                Рассматривать принципиально нефальсифицируемые («нельзя доказать отсутствие») гипотезы — удел религии, а не науки.

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

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

                                                > Мне кажется, стоит ввести нормировочные коэффициенты вроде энергии или массы на штуку или пользу.
                                                А потом раскулачить программушков!
                                                Ответить
                                                • Снимите чайник Рассела с плитки. Не время ему кипеть!

                                                  > нефальсифицируемые («нельзя доказать отсутствие») гипотезы
                                                  А мне кажется, "нельзя доказать отсутствие" - свойство избранной нами логики, она не влияет фальсифицируемость высказываний про свои объекты. Нельзя доказать отстутствие чего угодно, как богов, так и электронов, не важно, фальсифицируемы ли высказывания про богов или электроны.

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

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

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

                                                  > напрямую воздействовали дыроколами на картон перфокарт
                                                  Они дыроколами косвенно воздействовали на информацию, которая должна была как-то обрабатываться!

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

                                                  Никакой информации в материальном мире нет. Программисты решают задачи материального мира через выдуманное их преобразование в информационные объекты. Преобразование выходит двойное - из реальной задачи в работу с "информацией", а затем из работы с "информацией" в реальный мир (программа управляет физическим ковшом экскаватора). Но в итоге программист средствами физические компьютеров воздействует на физические. И в этом смысле кузнец полностью эквивалентен программисту+админу на фабрике боевых копий.
                                                  Ответить
                                                  • Да, я неправильно понял исходное высказывание.
                                                    Можно доказать неверность (то есть опровергнуть) высказанной гипотезы в случае, если она фальсифицируема. Если этого сделать нельзя — значит, гипотеза нефальсифицируема, и рассматриваться в качестве источника научного знания не должна. Отдельно замечу, что анафеме подлежит именно гипотеза в целом, а не конкретные её идеи или предположения, которые вполне могут быть научными.

                                                    > Ненаучные идеи - сырая информация, не обязательно неверная. Ненаучные идеи могут описывать как небылицы, так и реальность будущего.
                                                    Верно, однако в научном контексте рассматривать ненаучные идеи бессмысленно. Это то же самое, что и чтение /dev/urandom в попытке найти там лекарство от рака. Безусловно, если достаточно долго читать (и если там достаточно энтропии, а то знаем мы эти ГПСЧ…), то оно в конце концов найдётся. Только времени это займёт несоизмеримо больше, чем поиск того же лекарства более… научными методами.

                                                    Более того, у всех нефильсифицируемых гипотез есть Фатальный Недостаток: они не предоставляют научно-значимых предсказаний.
                                                    Любая научная гипотеза может предсказывать определённые события исходя из определённых предпосылок. Из наличия двух материальных точек с массами m1 и m2, находящихся на расстоянии r, теория тяготения Ньютона предсказывает существование силы притяжения между ними, численно равной F = G*m1*m2/r^2 Н. Из этого предсказания выводится фальсифицируемость этой теории: если в корректно поставленном эксперименте вместо F наблюдается какая-то другая сила — значит, теория опровергнута.

                                                    Поэтому, если некоторая теория содержит проверяемые предсказания («кто рано встаёт — тому бог даёт сто рублей под подушку»), то её можно опровергнуть экспериментом. Обратно, если теория неопровергаема, значит, научно-значимых предсказаний она не содержит.

                                                    А если теория не содержит научно-значимых предсказаний — то зачем она вообще нужна? Любоваться на неё?
                                                    Ответить
                                                    • > А если теория не содержит научно-значимых предсказаний — то зачем она вообще нужна? Любоваться на неё?

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

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

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

                                                      Инженер вовсе может аппроксимировать ненаучные знания реальным прибором. Вместо скатерти-самобранки - сервис по доставке еды, вместо м...тв - указания голосовому помощнику.
                                                      Ответить
                                                      • Ну, пожалуй да, подобные рассуждения могут послужить вдохновением учёным, примерно как фантастика Золотого Века. Так что с философской точки зрения они могут представлять интерес.

                                                        Тем не менее, опираться на них в контексте научной дискуссии всё же не следует.
                                                        Ответить
                                                  • > Но в итоге программист средствами физические компьютеров воздействует на физические. И в этом смысле кузнец полностью эквивалентен программисту+админу на фабрике боевых копий.
                                                    А и правда, мы пришли к тотальному материализму. Именно поэтому я за «материализм».
                                                    Ответить
                            • Перефразирую - "Во всей этой питушне виноваты люди которые платят мне деньги и благодаря которым у меня есть работа".
                              Ты серьёзно? Просто смирись с тем что иногда (почти всегда) надо быстро высрать решение которое просто будет работать на данный момент и может ещё месяц а там уж как-то пофиксим.
                              Так в большинстве случаев. Вот сегдня надо было через анус завайтлистить в скрипте (!!!) регуляркой нахуй (!!111) ип провайдера который делает обращение на наш вебхуйк чтобы наш оператионс манагер мог протестить фичу, причём сука там пол интернета надо было вайтлиснуть потому что провайдер вконец охуел и ему тупо лень сказать с каких конкретно ип идут его ебучие хттп запросы.
                              Ты думаешь их нахуй это ебёт? Наши тесты прошли, клиенту понравилось. Он купил нашу услугу которая тоже сделана из поноса голодного мамонта.
                              Привыкай вытачивать параллелипипеды стенками своего ануса.
                              Ответить
                              • > Ты серьёзно?
                                А что, это не так?
                                Мы пишем говно на говне потому, что заказчики платят за говно.
                                Ответить
                                • Нет , кто угодно но не заказчики. Они не указывают на чём и как тебе писать. И сука с ними можно ещё человеческим языком договориться (не со всеми но всё же).
                                  Крутые тимлиды и манагеры которые хотят переписать все легаси проекты используя последнейшие свистоперделки потому что все крутые ребята так делают и потому что у них много тысяч звёздочек на гитхабе - вот главное пидоры. Хер что их убедишь что не стоит на хуй пойми чём писать апи для всех проектов (в том числе фин проекты) сразу, что не надо использовать этот ебаный фреймворк который выпускает по три мажорных версии в год потому что хотят продать тебе курсы и гайды, и у которых в LTS больше дыр чем в сыре.
                                  Это, конечно, взгляд с моей стороны, вполне возможно что с твоей всё по-другому.
                                  Ответить
                                  • Я чуть выше написал про эволюцию программирования и то, что в ней служит критерием естественного отбора.

                                    В массе своей заказчики хотят получить результат побыстрее и подешевле (и это вполне объяснимо). Но с другой стороны, мало кто из них задумывается над такими сложными понятиями, как «стоимость поддержки», «надёжность» и прочей питушнёй. Как результат — языки, поощряющие написание write-only говна, получают серьёзное эволюционное преимущество.
                                    Ответить
                                    • Это во всех областях. С банальной едой человек понимает, что надо что-то менять, а не жрать "сырок" для супа по 9 рублей только когда набирает несколько десятилетий опыта поедания. А в ИТ у заказчика опыта даже меньше, чем в потреблении еды.
                                      Ответить
                              • Зерно истины есть в твоих словах

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

                                А если бы он сначала получил PhD в CS, затем сделал бы нормальную архитектуру на нормальном языке, то как раз к марту этого года бы всё и закончил
                                Ответить
                                • Именно поэтому я за «PHP».
                                  Ответить
                                  • Важно так же помнить, что остальные 99.99% программистов на этом божественном языке тоже написали свои сайты и цмс, и до сих пор так и пишут их за еду.

                                    Повезло немногим
                                    Ответить
                          • > выточил
                            > на станке для работы с телами вращения
                            > параллелепипед

                            Странный токарь, видимо раньше на крестах писал...
                            Ответить
                            • Топор из куска рельса:
                              https://youtu.be/y4825p-_qZM

                              Вот это наверняка крестовик придумал.
                              Ответить
                              • Такой топор плох то что имеет некорректный центр тяжести и нужно долго пердолиться что бы было норм.
                                Ответить
                              • Serg
                                2 weeks ago
                                Топор зачёт, особенно понравилось как он палку толщиной не более 5 см втечение 50
                                ударов срубил, круто не то что мой с магазина за два удара срубает, а тут и время убить
                                можно и занять себя на неделю если дерево толщиной 15 см срубить понадобится, не
                                хороший топор ржаветь вот только будет, рельса же, но ничего покрасить можно да и
                                хреново что на ручка на эбоксидке да на сварке лопаться будет, ну ничего сварочный
                                есть с эбоксидкой можно будет ещё раз сделать всяко проще чем отверстие под
                                деревянную ручку сделать это ж очень просто будет, а тут изъебнуться можно со
                                сваркой да и эбоксидку девать некуда в общем топор зачёт

                                Какой топор )))
                                Ответить
                                • Топор ещё наверняка тупиться будет быстро. У рельсов железо довольно пластичное, чтобы рельс не раскалывался под проходящим поездом.

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

                                  В «Ютубе» я ещё видел массу бесполезных колунов. Например, такой:
                                  https://youtu.be/kfOlP7rEvmo

                                  Он же будет передавать деревяшке малость смешной импульс, так что понадобится 50 ударов на то, чтобы разрубить деревяшку, которую классический колун возьмёт за один удар.
                                  Ответить
                                  • > kfOlP7rEvmo
                                    Лол, он с такой натугой колет идеально ровные чурбаны, что аж смешно становится. Классическим топором такие штуки рубятся одной рукой и чуть ли не в свободном падении.
                                    Ответить
                                    • Введи в поиск «чудо-колун». Таких обезьяноидов много.
                                      Ответить
                                      • Проверил.

                                        https://www.youtube.com/watch?v=pdi8-YUgDSY&t=1m54s
                                        Эпический багор, я аж поржал.
                                        Ответить
                                      • https://www.youtube.com/watch?v=PAThovQasyc
                                        Какие комментарии )))
                                        Ответить
                                        • >> Прихуярь к ручкам еще две гири по 32 кг что бы подлива по ляшкам потекла вот тогда будет заебись...............
                                          Ответить
                                        • Из рекомендаций: «Самоделки наркоманов».

                                          https://youtu.be/tpTgsasA5xM
                                          Ответить
                                • > на эбоксидке
                                  Ну хоть не из ебонита. Удивительно, как это при "эбоксидке" написано "в общем" вместо классического "вообщем".
                                  Ответить
                          • > токарь врёт

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

                                Для тех, наткнулся на этот тред случайно, имеется видео по изготовлению параллелепипеда на токарном станке без сложного пердолинга: https://www.youtube.com/watch?v=IPQ9JwzO_Yo Для этого требуется только движение резца по прямой строго перпендикулярно оси вращения (иначе выйдёт конус или фигурная питушня).
                                Ответить
                                • Хорошее замечание: «Помним о технике безопасности».

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

                                  Из-за несимметричной установки болванки станок работает, как виброзвонок.
                                  Ответить
                                  • > технике безопасности
                                    > несимметричной установки

                                    Вспоминается ролик, где дедок точил вазочку из пня с сучками. Там резец ему пару раз чуть в лоб не отлетал.
                                    Ответить
                                    • У нас в школе была столярная мастерская. Там висел огромный плакат, на котором было написано, что сучковатый материал на токарном станке обрабатывать ни в коем случае нельзя. И даже вроде было написано, почему именно нельзя.
                                      Ответить
                                • Питушня какая-то. Что-то мне подсказывает, что и станку, и резцу от такого использования придёт пиздец.
                                  Ответить
                                  • Может произойти естественный отбор токарей, если недостаточно хорошо закрепить болванку. Если плохо закрепить цилиндрическую, она вылетит не с таким импульсом, как прямоугольная.
                                    Ответить
                                  • Резец с чем-то таким сталкивается (в прямом и переносном смысле) постоянно. Какая-нибудь погнутая труба с выбоинами не сильно лучше заготовки под параллелепипед. Можно не торопиться и не вонзать его в заготовку по самые помидоры.

                                    Заготовку можно попробовать зажать более симметрично, подставив мелкие твёрдые пластинки, а также не повышать обороты без надобности.
                                    Ответить
                                    • Всё равно это питушня и костыли, там прямо-таки видится все эти вот «*reinterpret_cast<int*>(fX) = 42;». В программировании такое через ревью не проходит.
                                      Ответить
                                • Я вообще-то писа́л зелёным. Но сейчас наткнулся на видеозапись, как умелец насадил дисковую фрезу на флешку палку, чтобы использовать токарный станок вместо циркулярной пилы:
                                  https://youtu.be/d43f8rXEd6o
                                  Ответить
                              • Ответить
        • Какие эвенты))) https://github.com/top-think/framework/tree/6.0/src/think/event. Целый отдельный неймспейс с классами, которые не делают ровно нихуя.
          Ответить
          • Я нашёл действие в конструкторе LogWrite:
            public function __construct($channel, $log)
                {
                    $this->channel = $channel;
                    $this->log     = $log;
                }
            Ответить
    • > ThinkPHP

      > Think
      > PHP
      Ответить
    • class Url
      {
          /**
           * 应用对象
           * @var App
           */
          protected $app;


      действительно, из чего же еще состоит урл
      Ответить
    • "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 143 "-" "python-requests/2.23.0"
      "GET /api/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 209 "-" "python-requests/2.23.0"
      "GET /laravel/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 143 "-" "python-requests/2.23.0"
      "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 143 "-" "python-requests/2.23.0"
      "GET /sites/all/libraries/mailchimp/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 143 "-" "python-requests/2.23.0"
      "GET /test/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 143 "-" "python-requests/2.23.0"
      "GET /admin/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 143 "-" "python-requests/2.23.0"
      "GET /composer/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 143 "-" "python-requests/2.23.0"
      "GET /modules/ps_facetedsearch/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 143 "-" "python-requests/2.23.0"
      "GET /payment/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 143 "-" "python-requests/2.23.0"
      "GET /concrete/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 143 "-" "python-requests/2.23.0"
      "GET /wp-content/plugins/dzs-videogallery/class_parts/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 143 "-" "python-requests/2.23.0"
      "GET /accounts/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 143 "-" "python-requests/2.23.0"
      "GET /blog/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 143 "-" "python-requests/2.23.0"
      "GET /system/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 143 "-" "python-requests/2.23.0"
      "GET /modules/gamification/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 143 "-" "python-requests/2.23.0"

      Какой анскилл )))
      Ответить
      • Какой багор )))
        Ответить
      • Бань по юзер-агенту.
        Ответить
        • Та нах надо. Он мало того, что меняется (сканят много разных скриптов), так ещё и вреда никакого не несёт, благо «PHP» у меня нигде нет.

          Плюс против «Питона» я ничего не имею.
          Ответить
      • Именно поэтому я за PHP
        Ответить
      • да кто такой этот ваш V E N D O R блядь?!
        Ответить
    • Именно поэтому я за Laravel
      Ответить
      • У каждого веб фреймворка должны быть свои коллекции
        https://laravel.com/docs/7.x/collections

        >macroable
        макроёббл?
        Ответить
        • А какой фатальный недостаток у штатного полиморфного ассоциативного массива, что пришлось городить свою коллекцию?
          Ответить
          • «NIH», конечно.

            Not Invented Here.
            Ответить
          • Не знаю, может не было раньше?
            Нахуйя в джаваскрипте все эти андерскоры?
            Ответить
          • синтаксический сахар, чтобы не писать каждый раз свою чанк портянку для вывода условных row в бутстрапе и т.д.
            Да и стандартные методы работы с массивами в пыхе УГ + можно цепочками методы клепать
            Ответить

    Добавить комментарий