Забавные новости 0й-Ti :)

Раз уж эта тема про ЯП. Я думал сутки. И тут до меня дошло. Перл посчитал байт 0x0A (номер сектора 10) возвратом каретки и решил, что он умней человеков, которые на нем пишут. Возможно в этом он был прав, но выхлоп получился так себе. Вы все еще недоумеваете, почему миллионы мух выбирают петон?

 

Может файл надо было открыть в binary-режиме?
Если память мне не изменяет POSIX вообще заколустался с этими переводами кареток мучаться и рекомендует всё всегда открывать в binary-режиме и забыть про text mode. Но это грабельки, да. Постоянно надо быть начеку.

 

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

Код (Text):

1. $dsk_track = [];
2. sysread(IN, $buff, 256*21 ); # Track 256 bytes * 21 sectors
3. push $dsk_track, unpack( 'C5376', $buff);

 

Хоспаде, кому в целом мире сейчас нужно писать на Перле? Искренне соболезную твоей боли.

 

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

 

экь всё скуржопливается..

 

Кто нибудь юзал такой способ активации Windows/Office обычным батником?
https://github.com/massgravel/Microsoft-Activation-Scripts

 

даа, это не Ассемблер, чёрт ногу сломит

 

Юзал. Это по-моему теперь самый популярный кряк на винду. И он лежит на гитхабе.
Разрабы в общих чертах описали используемые методы https://massgrave.dev/kms38

 

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

--- Сообщение объединено, 7 май 2024 ---

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

 

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

--- Сообщение объединено, 10 май 2024 ---

короче всю утиную типизацию и интерпретаторы на мыло отправил ради перформанса.

--- Сообщение объединено, 10 май 2024 ---

а лисп тем временем продолжает жить

 

Да, он не понимает клинкод. Проблема в том, что обе стороны конфликта (и адепты клинкода и адепты на 2 процента более быстрых циклов) не понимают одной важной вещи: если код будет идеально чистым, то он будет гораздо медленнее, чем он мог бы быть; если код будет идеально быстрым, то его будет слишком сложно поддерживать. В реальном мире нет идеального ни одного, ни другого, но почему-то одни продолжают навязывать одно, а другие - другое.

 

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

 

вот возьмём, к примеру, dry (don't repeat yourself) - очень плохая идея..
допустим, у нас 10 фунок пользуют одну базовую и нам нужно написать 11ую, коя тоже должна пользовать ту базовую, но нам необходимо внести изменения в базовую для удовлетворения нужд новой функи. что делать??? можно зафигачить изменения в базовую и сношаться с отладчиком по всему древу зависимостей. А можно скопировать базовую и сделать серию минорных изменений под новую функу.. то бишь мы проводим Атомизацию Кода и лишаем себе туЕвой Хучи печалей + АК помогает спид-апу проги и улучшает её портабельность + улучшаем читабельность кода, лишая себя мути доп условных ветвлений. Короче, правила спид-апа кода гораздо ближе к Чистому Коду, чем тот замшелый клинкод. потом - чем Тебе те свичи не нравятся - пользуй инлайн функи ==>> вот Тебе читабельность да спид-ап в одном флаконе

 

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

 

а нельзя быть за АК и бегать с интерфейсами клинкода клинявый код подразумевает работу сугубо с интерфейсами - у Тебя задача и Ты смотришь аким дикобразом её решить чрез набор доступных. но что происходит, когда не хватает функционала базовых модулей??? dry требует впихнуть новые функи, не нарушая кол-во модулей - ведь, повторяться нельзя клинявый код приводит к длинным абстракциям, что ввергает всю идею к полному Абсурду. абстракция не должна становиться источником проблемы, а размер длинной абстракции легко превышает весь базовый код в разы и в итоге погружаешься в кромешный идиотизм ==>> тестирование и отладка абстракций

 

А как относитесь к паттернам проектирования в промышленной разработке? Они нужны или нет?

 

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