Еще больше смазанности, когда параметров два или больше. Где один, например, количество данных, а другой - размер окна или алфавита, которые значительно меньше количества. И ты вроде пытаешься уменьшить часть, на которую умножается зависимость от количества, а она не уменьшается. При этом еще и дополнительные ограничения возникают.
Все это конечно очень интересно, но у подобных задач при переходе к практике могут возникать конфузы. Решение в лоб может оказаться эффективней при реализации на конкретных языках, причем даже при достаточном для некоторых практических применений количестве данных. Например, алгоритм может иметь низкую энтропию условных переходов, компилятор может удачно подобрать SIMD инструкции, плюс расходы на работу с памятью, зависимость от реализации контейнеров стандартной библиотеки, и куча других факторов. Единственный способ узнать реальную эффективность - это написать код и прогнать по бенчмаркам, которые тоже нужно правильно уметь писать.
Как минимум, очень сильно обфусцировать можно. Когда-то давно размышлял над подобным, и идея была следующая.
Создать виртуальную машину из M блоков одинаковой длины, скажем в N бит, которые по сути являются просто числами. В каждом блоке должно быть отведено какое-то количество бит для обмена информацией между собой, бит регистров, служебных бит, и возможно какое-то избыточное количество бит для повышения стойкости к реверс инжинирингу.
У блока будет конечное количество всех возможных состояний, для каждого из которых будет ровно одно следующее. Все эти состояния и переходы можно заранее просчитать, и представить массивом чисел вида "state[current] = next". После чего номера состояний можно перемешать хорошим рандомом, и используя их создать обфусцированный массив. На вычисляющей машине будет только обфусцированный массив, а карта соответствий значений из изначального и обфусцированного масссива будет служить ключем.
Упрощенный пример для понимания. Допустим блок имеет например структуру "RRRRXXYY", где XX и YY биты входных регистров, RRRR биты регистра результата, а операция скажем сумма. Тогда в изначальном массиве индексу "0000.01.10" будет соответствовать число "0011.00.00" (разделил регистры точками для удобства чтения). В изначальном массиве это будет "state[6] = 48". А после рандомизации эти же два состояния могут оказаться любыми числами, например "state[37456] = 91204". Главное, чтобы направление всех переходов сохранялись.
Само собой, в реальной реализации входные и выходные регистры могут совмещаться для экономии, будет много других служебных бит, и сами операции скорее всего будут другого уровня абстракций (логические вентили, например), и т.д. и т.п., но общий принцип примерно такой.
Каждый шаг каждый из M блоков виртуальной машины переключается в свое следующее состояние. Самая сложная часть, вероятно, будет общением между блоками - условная "шина" должна вещать данные всем блокам сразу, а блоки у себя внутри как-то понимать, им это адресовано, или нет. Большая часть бит скорее всего на эту адресацию и уйдет. Соответственно самих блоков тоже понадобится много. Они, кстати, не обязательно должны быть однотипными, и возможно несколько массивов состояний будут удобней при том же суммарном объеме. Ввод вывод - отдельная проблема.
Работать все это будет очень медленно, зато весьма обфусцированно. Тут конечно, нужно вспомнить принцип "каждый может создать шифр, который сам не может взломать", а поскольку я не спец по криптографии, даже теоретическая эффективность описанного выше сомнительна. Тем более, что я даже не пытался все это реализовать в коде, лишь на уровне идеи, и может даже оказаться что это толком невозможно.
Сознание, это когда ты смотришь на красное, и чувствуешь красный цвет, в том смысле, в каком оно понимается в понятии квалиа. При этом тебе не нужно знать что такое красный, что такое цвет, и вообще быть разумным. Самим фактом такого наблюдения ты доказываешь сам себе что сознание лично у тебя есть. На самом деле, это вообще единственный факт который существо обладающее сознанием может достоверно доказать само себе. Все остальное гипотетически может быть чем угодно, поданным на гипотетический вход условного наблюдателя.
Логотип Firefox конечно все более минималистичен с каждой новой версией, но как минимум первые десять лет на нем отчетливо узнается слева лиса, а справа огонь. Причем там даже пигментация морды прорисована, а так же характерные щеки, острые длинные рыжие уши, тонкие рыжие лапы, длинная морда, острый нос, хвост без полос и т.д. и т.п. Т.е. полное совпадение с тем, как выглядит обычная лиса, и полная противоположность тому, как выглядит красная панда.
А если на логотипе лиса и огонь, то значит назван он в честь лисы и огня. Более того, он чисто исторически был сначала Phoenix, потом Firebird, а потом bird поменяли на fox, а fire всегда был центральной темой логотипа.
В qBittorrent уже очень давно (более пяти лет точно) есть возможность и отказа от создания корневой папки (сейчас выпадающий список "Content layout -> Don't create subfolder", раньше была галочка "Create subfolder"), и перемещения файлов в другую локацию ("ПКМ -> Set location").
Ну так можно же банально иметь две версии. Меня например наоборот бесят все приложения, которые куда-то в профиль ставятся, а не в папку которую я укажу.
Удивительно, что электрон-монстрятину не догадались реализовать в виде фреймворка. Т.е. чтобы он стоял в система один (как Java, NET, и т.д.), складировал отдельно пакеты разных версий, а приложения в основном занимали бы по 5 МБ кастомного js, иконок, и прочей мелочи.
То что в статье - это и есть классический интрузивный односвязный список. Это потом уже придумали разделять на контейнер и его узлы. И то, это удобней лишь при наличии встроенных в язык средств ООП.
В этой ситуации "кодом" фактически становится набор промптов на естественном языке.
Не совсем. Код это текст на формальном языке программирования. К примеру, автор данной статьи сам не писал ни строчки кода. Каких-то особых навыков чтобы общаться с программистом не нужно, и по мере улучшения ИИ к ним это тоже должно стать применимо. Причем со временем это скорее всего будет совмещено с распознаванием речи. Т.е. владелец продукта сможет просто позвонить ИИ через например телеграм, и сказать "подними пожалуйста аватарку пользователя чуть выше", и через минуту это будет уже в проде.
Потребуется разве что набор автоматизированных тестов интерфейсов, которые нейросеть сама будет запускать чтобы проверить код на совместимость с предыдущим. Причем нейросеть сама может написать эти тесты в собственную память, а людям для проверки переводить их на естественный человеческий язык. Если это будет экономически эффективней традиционных способов разработки, то и на это тоже со временем перейдут.
Трекеры багов и задач - это всего-лишь костыли, необходимые людишкам которые не могут даже разработать все приложение с нуля за пять минут. Ситема контроля версий - тоже костыль, который нужен людишкам, которые не могут разработать приложение в одиночку, и которым нужно собираться в группы и одновременно работать над разными фичами, а потом мержить их в главную ветку. Достаточно продвинутой нейросети умеющей в контекст и память это все может быть не нужно. Останется лишь хранить историю общения, но только в качестве бекапа, чтобы в случае форс-мажора взять чистый инстанс ИИ из дампа и заново ему ее скормить.
Еще есть гипотетическая вероятность, что нейросети когда-нибудь смогут не теряя в надежности и безопасности выдавать более быстрый код в обход компилятора. Т.е. сразу из текстового описания в бинарник. Например, дропнув все абстракции (и библиотеки с фреймворками заодно), ведь нейросеть все равно каждый раз почти с нуля приложение переписывает (ей нужно лишь совместимость всего входящего-исходящего сохранять), а значит и человеческие костыли в виде SOLID/DRY/KISS/и т.д. ей не нужны. Или генерируя код используя предположения, которые обычный компилятор заранее знать не может. Если такие приложения будут быстрее, то это конкурентное преимущество, а значит на него будет экономически выгодно переходить. Но при этом в бинарнике будет такой же непостижимый для человека черный ящик, как и сама обученная нейросеть.
С того же, с чего калькулятор у людей выше 10 секунд запускается, а система жрет в разы больше ресурсов чем раньше, даже в простое. В теории все красиво, а на практике и в совокупности результат на табло.
Если вы про файловые кэши и в этом духе
Не про них. Но я код конкретно блокнота не видел, и не знаю что там. Но сказанное про вкладки и не только блокнота касается.
не понятно о чем вы беспокоитесь
Давайте еще раз. Человек сказал что после добавления вкладок приложения становятся менее быстрыми и простыми. Я нигде не писал какой в абсолютной величине будет разница (может даже околонулувой), но указал факторы, которые указывают что она будет в пользу вкладок.
Общие read-only сегменты кода(в том числе ресурсы) будут расшарены между процессами.
А то, что этот самый код будет работать, и тратить процессорное время, уже не считается?
Какие там кэши могут быть в блокноте?
Списки шрифтов в системе, впомогательные данные для локализации ввода, что-то для растеризации текста (кеш глифов), например. Подождите, пока его перепишут на электрон. Тогда в нем будут ВСЕ кэши.
Площадь окна на экране, вы серьезно?
Да. Это гораздо более правдоподобно, чем нарушение "Базовая ОС должна предоставлять БЫСТРЫЙ и ПРОСТОЙ софт. Который работает быстро, просто и не вызывает проблем взаимодействия" добавлением функционала вкладок.
Если его не видно, то оно вряд ли будет даже отрисовываться.
Его не видно только если его специально свернули, или открыли что-то другое во весь экран. А обычно у пользователя блокнота открыт рабочий стол с кучей файлов, слева блокнот, справа блокнот, и над ними еще один блокнот.
Потому что каждый отдельный инстанс программы будет дублировать часть работы, которую делают все другие инстансы, и хранить данные аналогичные хранимым другими инстансами (например, кеши). Потому что в системе на каждый инстанс будет по иконке, превью, и встроенному трояну. Потому что одно окно дефолтного размера банально имеет меньшую площадь на экране, чем два окна дефолтного размера. И т.д. и т.п.
Странная претензия. Одно окно с вкладками быстрее работает, требует меньше памяти, и удобней для переключений между документами чем куча отдельных запущенных приложений. За исключением случая когда два файла нужно отобразить на экране одновременно, вариант с вкладками выигрывает буквально почти во всем.
Чтобы получить второго мясного эксперта, нужны десятилетия времени, место для его физического размещения, много денег, и удовлетворение всяких его потребностей. Получить тысячу электронных экспертов при отточенной технологии - почти сразу, почти бесплатно, и работать они могут не просто круглосуточно, а еще и смотреть при этом на кожаных мешков в ускоренной сьемке как Нео из матрицы.
Еще больше смазанности, когда параметров два или больше. Где один, например, количество данных, а другой - размер окна или алфавита, которые значительно меньше количества. И ты вроде пытаешься уменьшить часть, на которую умножается зависимость от количества, а она не уменьшается. При этом еще и дополнительные ограничения возникают.
Все это конечно очень интересно, но у подобных задач при переходе к практике могут возникать конфузы. Решение в лоб может оказаться эффективней при реализации на конкретных языках, причем даже при достаточном для некоторых практических применений количестве данных. Например, алгоритм может иметь низкую энтропию условных переходов, компилятор может удачно подобрать SIMD инструкции, плюс расходы на работу с памятью, зависимость от реализации контейнеров стандартной библиотеки, и куча других факторов. Единственный способ узнать реальную эффективность - это написать код и прогнать по бенчмаркам, которые тоже нужно правильно уметь писать.
Как минимум, очень сильно обфусцировать можно. Когда-то давно размышлял над подобным, и идея была следующая.
Создать виртуальную машину из M блоков одинаковой длины, скажем в N бит, которые по сути являются просто числами. В каждом блоке должно быть отведено какое-то количество бит для обмена информацией между собой, бит регистров, служебных бит, и возможно какое-то избыточное количество бит для повышения стойкости к реверс инжинирингу.
У блока будет конечное количество всех возможных состояний, для каждого из которых будет ровно одно следующее. Все эти состояния и переходы можно заранее просчитать, и представить массивом чисел вида "state[current] = next". После чего номера состояний можно перемешать хорошим рандомом, и используя их создать обфусцированный массив. На вычисляющей машине будет только обфусцированный массив, а карта соответствий значений из изначального и обфусцированного масссива будет служить ключем.
Упрощенный пример для понимания. Допустим блок имеет например структуру "RRRRXXYY", где XX и YY биты входных регистров, RRRR биты регистра результата, а операция скажем сумма. Тогда в изначальном массиве индексу "0000.01.10" будет соответствовать число "0011.00.00" (разделил регистры точками для удобства чтения). В изначальном массиве это будет "state[6] = 48". А после рандомизации эти же два состояния могут оказаться любыми числами, например "state[37456] = 91204". Главное, чтобы направление всех переходов сохранялись.
Само собой, в реальной реализации входные и выходные регистры могут совмещаться для экономии, будет много других служебных бит, и сами операции скорее всего будут другого уровня абстракций (логические вентили, например), и т.д. и т.п., но общий принцип примерно такой.
Каждый шаг каждый из M блоков виртуальной машины переключается в свое следующее состояние. Самая сложная часть, вероятно, будет общением между блоками - условная "шина" должна вещать данные всем блокам сразу, а блоки у себя внутри как-то понимать, им это адресовано, или нет. Большая часть бит скорее всего на эту адресацию и уйдет. Соответственно самих блоков тоже понадобится много. Они, кстати, не обязательно должны быть однотипными, и возможно несколько массивов состояний будут удобней при том же суммарном объеме. Ввод вывод - отдельная проблема.
Работать все это будет очень медленно, зато весьма обфусцированно. Тут конечно, нужно вспомнить принцип "каждый может создать шифр, который сам не может взломать", а поскольку я не спец по криптографии, даже теоретическая эффективность описанного выше сомнительна. Тем более, что я даже не пытался все это реализовать в коде, лишь на уровне идеи, и может даже оказаться что это толком невозможно.
Сознание, это когда ты смотришь на красное, и чувствуешь красный цвет, в том смысле, в каком оно понимается в понятии квалиа. При этом тебе не нужно знать что такое красный, что такое цвет, и вообще быть разумным. Самим фактом такого наблюдения ты доказываешь сам себе что сознание лично у тебя есть. На самом деле, это вообще единственный факт который существо обладающее сознанием может достоверно доказать само себе. Все остальное гипотетически может быть чем угодно, поданным на гипотетический вход условного наблюдателя.
Это существо которое по поведению неотличимо от существа обладающего сознанием, но при этом не обладающее им в действительности.
Логотип Firefox конечно все более минималистичен с каждой новой версией, но как минимум первые десять лет на нем отчетливо узнается слева лиса, а справа огонь. Причем там даже пигментация морды прорисована, а так же характерные щеки, острые длинные рыжие уши, тонкие рыжие лапы, длинная морда, острый нос, хвост без полос и т.д. и т.п. Т.е. полное совпадение с тем, как выглядит обычная лиса, и полная противоположность тому, как выглядит красная панда.
А если на логотипе лиса и огонь, то значит назван он в честь лисы и огня. Более того, он чисто исторически был сначала Phoenix, потом Firebird, а потом bird поменяли на fox, а fire всегда был центральной темой логотипа.
"Я всю ночь не спал. Не мог заснуть! Всё думал,
чем у вас восьмой инженер занимаетсякто выполнил эти условия кроме Tree?" /sГенерирует. Например почитайте этот комментарий и его ветку.
В qBittorrent уже очень давно (более пяти лет точно) есть возможность и отказа от создания корневой папки (сейчас выпадающий список "Content layout -> Don't create subfolder", раньше была галочка "Create subfolder"), и перемещения файлов в другую локацию ("ПКМ -> Set location").
Ну так можно же банально иметь две версии. Меня например наоборот бесят все приложения, которые куда-то в профиль ставятся, а не в папку которую я укажу.
Удивительно, что электрон-монстрятину не догадались реализовать в виде фреймворка. Т.е. чтобы он стоял в система один (как Java, NET, и т.д.), складировал отдельно пакеты разных версий, а приложения в основном занимали бы по 5 МБ кастомного js, иконок, и прочей мелочи.
То что в статье - это и есть классический интрузивный односвязный список. Это потом уже придумали разделять на контейнер и его узлы. И то, это удобней лишь при наличии встроенных в язык средств ООП.
Не совсем. Код это текст на формальном языке программирования. К примеру, автор данной статьи сам не писал ни строчки кода. Каких-то особых навыков чтобы общаться с программистом не нужно, и по мере улучшения ИИ к ним это тоже должно стать применимо. Причем со временем это скорее всего будет совмещено с распознаванием речи. Т.е. владелец продукта сможет просто позвонить ИИ через например телеграм, и сказать "подними пожалуйста аватарку пользователя чуть выше", и через минуту это будет уже в проде.
Потребуется разве что набор автоматизированных тестов интерфейсов, которые нейросеть сама будет запускать чтобы проверить код на совместимость с предыдущим. Причем нейросеть сама может написать эти тесты в собственную память, а людям для проверки переводить их на естественный человеческий язык. Если это будет экономически эффективней традиционных способов разработки, то и на это тоже со временем перейдут.
Трекеры багов и задач - это всего-лишь костыли, необходимые людишкам которые не могут даже разработать все приложение с нуля за пять минут. Ситема контроля версий - тоже костыль, который нужен людишкам, которые не могут разработать приложение в одиночку, и которым нужно собираться в группы и одновременно работать над разными фичами, а потом мержить их в главную ветку. Достаточно продвинутой нейросети умеющей в контекст и память это все может быть не нужно. Останется лишь хранить историю общения, но только в качестве бекапа, чтобы в случае форс-мажора взять чистый инстанс ИИ из дампа и заново ему ее скормить.
Еще есть гипотетическая вероятность, что нейросети когда-нибудь смогут не теряя в надежности и безопасности выдавать более быстрый код в обход компилятора. Т.е. сразу из текстового описания в бинарник. Например, дропнув все абстракции (и библиотеки с фреймворками заодно), ведь нейросеть все равно каждый раз почти с нуля приложение переписывает (ей нужно лишь совместимость всего входящего-исходящего сохранять), а значит и человеческие костыли в виде SOLID/DRY/KISS/и т.д. ей не нужны. Или генерируя код используя предположения, которые обычный компилятор заранее знать не может. Если такие приложения будут быстрее, то это конкурентное преимущество, а значит на него будет экономически выгодно переходить. Но при этом в бинарнике будет такой же непостижимый для человека черный ящик, как и сама обученная нейросеть.
Рекомендую попробовать Flashnote.
Киллерфичи:
1) Легковесный как блокнот. После лет 10 накопления заметок прямо сейчас он занимает лишь 13 МБ ОЗУ.
2) Есть хоткей на развернуть/свернуть в трей. У меня на Crtl+Shift-Z. Открывается примерно мгновенно.
3) Концепции сохранения в нем просто нет. Любые изменения сразу пишутся в файл (который просто база sqlite).
4) Древовидная структура заметок и поиск по ней. Весь мой хлам хранится в одном файле.
5) Есть portable версия. Ей и пользуюсь.
Минусы:
1) Не считая перечисленного выше по функционалу это просто блокнот. Даже форматирования текста нет.
С того же, с чего калькулятор у людей выше 10 секунд запускается, а система жрет в разы больше ресурсов чем раньше, даже в простое. В теории все красиво, а на практике и в совокупности результат на табло.
Не про них. Но я код конкретно блокнота не видел, и не знаю что там. Но сказанное про вкладки и не только блокнота касается.
Давайте еще раз. Человек сказал что после добавления вкладок приложения становятся менее быстрыми и простыми. Я нигде не писал какой в абсолютной величине будет разница (может даже околонулувой), но указал факторы, которые указывают что она будет в пользу вкладок.
А то, что этот самый код будет работать, и тратить процессорное время, уже не считается?
Списки шрифтов в системе, впомогательные данные для локализации ввода, что-то для растеризации текста (кеш глифов), например. Подождите, пока его перепишут на электрон. Тогда в нем будут ВСЕ кэши.
Да. Это гораздо более правдоподобно, чем нарушение "Базовая ОС должна предоставлять БЫСТРЫЙ и ПРОСТОЙ софт. Который работает быстро, просто и не вызывает проблем взаимодействия" добавлением функционала вкладок.
Его не видно только если его специально свернули, или открыли что-то другое во весь экран. А обычно у пользователя блокнота открыт рабочий стол с кучей файлов, слева блокнот, справа блокнот, и над ними еще один блокнот.
Потому что каждый отдельный инстанс программы будет дублировать часть работы, которую делают все другие инстансы, и хранить данные аналогичные хранимым другими инстансами (например, кеши). Потому что в системе на каждый инстанс будет по иконке, превью, и встроенному трояну. Потому что одно окно дефолтного размера банально имеет меньшую площадь на экране, чем два окна дефолтного размера. И т.д. и т.п.
Странная претензия. Одно окно с вкладками быстрее работает, требует меньше памяти, и удобней для переключений между документами чем куча отдельных запущенных приложений. За исключением случая когда два файла нужно отобразить на экране одновременно, вариант с вкладками выигрывает буквально почти во всем.
Чтобы получить второго мясного эксперта, нужны десятилетия времени, место для его физического размещения, много денег, и удовлетворение всяких его потребностей. Получить тысячу электронных экспертов при отточенной технологии - почти сразу, почти бесплатно, и работать они могут не просто круглосуточно, а еще и смотреть при этом на кожаных мешков в ускоренной сьемке как Нео из матрицы.