Комментарии 85
Софт жиреет далеко не от обратной совместимости.
Близкий к нам пример — намерение разработчиков Хабра полностью удалить старый редактор в пользу нового, чтобы сократить расходы на поддержку двух несовместимых редакторов.
В то же время новый редактор настолько глючный, что одна мысль о принудительном переходе на него вызывает ужас у некоторых пользователей. Если такое случится, это будет ещё одним примером «преждевременной оптимизации».
С содроганием жду этого события, потому что без привычного html верстать статьи даже не представляю. Пробовал новый, очень неудобен, плюс функциональности меньше. Туда же новая версия хабра в личных сообщениях не позволяет вставлять картинки, а старая позволяет.
А по теме статьи, проблема не только в софте, но и железе. Всем нам известные x86-amd64 архитектуры стремятся иметь обратную совместимость, наследуя особенности прошлых версий. Тут тоже бывают всякие странные решения.
А не проще избавляться от старых платформ простой эмуляцией, а не загружать ядро ненужным кодом?
Смотря насколько старых. Если совсем-совсем старых - то проще. Если активно эксплуатируемых, то вообще не проще. Если у новой версии не будет прямой совместимости с софтом трех-четырех предшествующих, многие пользователи вообще не будут на неё мигрировать.
Те же виндузятники так и делают, если слово эмуляция вообще применима.
Тоесть ты вызываешь один API но внутри он варпится на современный + теперь этот вызов работает в юзер спейсе.
старая платформа - это значит мало ресурсов, эмуляция дополнительно увеличит их потребление.
По сути, когда мы сохраняем поддержку устаревших технологий или специально внедряем ненужные опции чисто ради обратной совместимости (как этот менеджер памяти) — мы намеренно ухудшаем программное обеспечение по требованию менеджеров.
Мне категорически не нравится эта формулировка. С моей точки зрения, если мы сохраняем обратную совместимость, мы не ухудшаем программное обеспечение, а добавляем в него дополнительную, важную функциональность. Ваше приложение ценно не красивой архитектурой, оно ценно пользователями. И если новая версия уменьшает пользовательскую базу, грош цена её архитектуре и всем нововведениям.
Самим фактом своего появления он как бы намекает на возможность переписать всё с нуля, в лучшем виде.
Проблема в том, что "переписать всё в лучшем виде" чаще не работает, чем работает. Вот эти все костыли на костылях в легаси, они обычно собирают какие-то бизнес-требования, многие из которых оказываются актуальны, но просто не попадают в новый и чистый код.
Вот-вот. Мне тоже кажется странным, что люди не понимают, что первое, что должен делать код - выполнять пользовательские задачи. Второе - быть красивым и удобным в сопровождении.
Дальше начинаются всякие балансы в духе "да, мы не будем поддерживать 386 компы ради 0.01% пользователей" и это норм. Но обратная совместимость в целом - исключительно важная функциональность, нацеленная на поддержку тонн сохраненных пользователем данных (файлов, БД, конфигураций), которые могут быть обработаны ПО.
Да и сама статья по сути на 80% подтверждает это. Windows популярна благодаря костылям, а заголовок говорит, что это плохо. В качестве примера приводится клиентский софт того же произовдителя, который не осили системные вызовы судя по всему или пользовались какой то прослойкой для совместимости.
Проблема в том, что костыль для поддержки СимСити был актуален год-полтора после выхода Виндовз 95, но остался в коде навсегда, что код само по себе не облагораживает, но и открывает возможности для новых интересных багов, эксплойтов и так далее. Тут еще вопрос, надо ли было этот костыль впиливать ради скольки-то там пользователей, которые вполне бы могли запускать свою любимую ДОС программу тупо из ДОС, благо 95-я Виндовз ДОС целиком в себя включала.
Ну как навсегда? Через несколько лет и код тот потерял актуальность. А про эксплойты во времена Win95 вообще говорить не приходилось. В операционной системе, где область общих библиотек шарится между всеми процессами и доступна для записи, зловреду совсем не обязательно притворяться СимСити и организовывать вектор атаки через хитро закрученную задницу, если можно спокойно зайти с парадного входа.
Почему полгода? И сейчас пользователь наверняка может запустить тот старый SimCity на Windows 10.
Это другое (с). В Win9x приложения DOS запускались непосредственно операционкой, в которой было нативное 16-битное окружение для такого софта, и соответственно, хаки для совместимости нужно было внедрять в операционку. В линейке NT/2000/XP/Vista/7/8/10 для запуска приложений DOS используется эмулятор NTVDM, который по сути является виртуальной машиной, и со стороны ОС выглядит как обычное виндовое приложение, не требуя никаких хаков. Ну и под 64-битную винду он не был портирован, поэтому сейчас без эмуляторов от сторонних разработчиков уже СимСити не запустить.
А что там с совместимостью?
Перетягивал в своё время приложение с Delphi 7 на XE2, небольшие затруднения были только там, где строки не по назначению использовались. А помер он из-за невостребованности на рынке труда.
После выхода отличной Delphi 7, свернула не в ту степь Delphi 8, которая поддерживала разработку только под дотнет, потом они где-то похерили все исходники своего хорошего хелпа, потом они решили написать с нуля новую универсальную IDE, вышло две жутко сырые и падающие от каждого чиха версии Delphi 2005 и 2006, потом на волне критики они наконец занялись ремонтом и более-менее стабилизировались к версии 2007... но репутацию уже безвозвратно подмочили, разработчики начали сваливать. Не способствовала ещё и ценовая политика. В то время как MS делала студию лучше и доступнее, у Delphi цена наоборот, повышалась от версии к версии, и в общем-то они сами себе перекрыли кислород, сделав невозможным приток новых разработчиков. Т.к. стартовая цена лицухи составляла порядка килобакса, а бесплатная версия вроде как и была, но её сделали совершенно непригодной для разработки именно тех приложений, где "настоящая" Delphi имела основное применение. Так что проблема была комплексной, не только в совместимости. Тут и совместимость, и потеря документации, и отвратительное качество нескольких версий подряд, и ошибки менеджмента.
Да не умер он, ещё вполне жив)
Есть одна нужная программа 90-х годов. Приходится ради неё запускать виртуальную XP. Несмотря на слезы и уколы кактуса.
В wine старый софт неплохо живет, возможно и на windows есть аналог wine
https://wiki.winehq.org/Cygwin_and_More#Wine_on_Cygwin
На Windows есть сам Вайн через cygwin.
Эппл грохнула поддержку 32 битных приложений и до сих пор ноют. Так что может Майкрософт и правильно делают. А вот софт современный жиреет точно не от обратной совместимости, а от какой-то странной мании совать библиотеки и фрейворки туда, где они вообще не нужны. У меня в компании в проде крутится сервис из 5 джава-классов, который просто читает из рэббита, меняет структуру JSON и постит в SNS. И всех почему-то устраивает, что сервису нужен спринг бут, StringUtils для одной строчки кода и еще 3 библиотеки, которые можно заменить стандартным API за 5 минут.
А вот по поводу библиотек как раз все понятно: тут уже решает стоимость разработки. Бизнесу выгодно сэкономить на разработке здесь и сейчас, отложенные проблемы и скрытый оверхед (например потребность в более дорогом железе) бизнес не особо интересуют, пока оно его не клюнет непосредственным образом. И так везде.
Как по-хорошему такая задача решается: аналитики и архитекторы описывают всю систему, решают где и в каком виде нужны изменения, документируют их, и формулируют конкретную задачу. И все красиво: все спланировано и описано, результат, решение и последствия известны заранее.
Но это по сути получается несколько дней целый небольшой отдел будет занят одной такой задачей. Это дорого, даже если этот отдел есть. Но в большинстве контор не то что архитекторов и аналитиков, даже описания системы нет, знания передаются из уст в уста между разработчиками, т.е. даже процессы разработки тупо никак не выстроены, экономия на всем, и на разработке особенно.
И вот приходит новый разработчик и получает задачу невнятного вида, что данные есть тут но должны оказаться тут. И на этом все. Зачем, почему, как? Выясняй сам, и вообще крутись как хочешь: "мы вот тебе ТЗ выцсрали и считаем проблему закрытой, точка".
И у него остается немного вариантов:
1 - потратить тонну времени и усилий штурмуя всех вокруг в попытке выяснить как оно устроено, что и зачем, в чем смысл задачи, и как ее лучше сделать, т.е. выяснять то что в ТЗ должно было быть изначально, выполнять работу аналитиков и архитекторов, но без необходимого опыта и знаний. Он даже может озвучить такую идею, но его скорее всего просто пошлют, в духе "а что так много времени надо? Бери больше - кидай дальше, думать не надо, это дорого, мы за это платить не будем".
2 - сделать то что фактически написано в ТЗ, как бы бессмысленно это ни было, т.к. спрашивать будут по тому, что написали в ТЗ, а не по домыслам разработчика. И тут он просто берет и пилит сервис. Он знает спринг бут, поэтому берет и пилит на нем - решение получается однострочным, т.к. все необходимое уже есть в библиотеках, и их нужно только связать. Получается жирное, но рабочее решение, с минимальным временем разработки. Бизнес доволен - разработка обошлась дешево.
Конечно разработчик может сделать по канонам и написать все вручную, реализовав необходимый функционал из библиотек, но это много кода и много отладки, намного больше одной строчки. И большие затраты времени - бизнес недоволен, бизнес такую идею даже не одобрит.
Конечно может быть даже решение, которое не потребует дополнительного сервиса, и например можно просто перенастроить штатный функционал силами админов, поменять одну строчку в конфиге, это 5 минут работы. Но задача то спустилась в разработку, а не к админам. И нигде в ТЗ не написано что так вообще можно - задача пришла не проработанная, на аналитиках и архитекторах сэкономили.
Вот и получается что решал ее один разработчик, в меру своих знаний о системе и компетенции, в меру своей лени и понимания всей степени бюрократизма: иной раз даже к админам обратиться дольше и дороже, чем все на стороне софта реализовать более сложным образом, но закрыть проблему. Решал теми средствами, что имел здесь и сейчас. Поэтому и результат закономерен.
Так что без внятного ТЗ результат ХЗ, и это нормально. Хотели бы сделать хорошо - начали бы с ТЗ, и получили идеальный результат. Но это дорого, так что бизнес выбирает жирный код с однострочной разработкой.
я с этим не спорю, однако, я упомянул, что всё это можно заменить за 5 минут на стандартный API Java. Ок, вместе с тестами за час. Но если изначально делать на стандартном API, то и понадобилось бы на 5 минут больше. Я думаю, что проблема в методах обучения специалистов. Да, сейчас память дешёвая и можно об этом не думать. Но это относится не только к памяти. Просто на курсах сейчас дают конкретные рецепты как делать что-то без рассмотрения альтернатив. Вот например, курсы по Java для web-разработчиков. В качестве примера рассматривают spring boot для создания сервиса в среде AWS. Этот пример очень примитивный, там 2 класса, REST API и отдача 200 статуса наружу. Всё. И как пример, да, окей, это работает. Проблема в том, что человек выходит с курса, и воспроизводит простейший функционал с помощью того, что ему показали на курсе. То есть где-то там нет мысли, что это можно сделать без всего этого обвеса, этого на курсе не объясняли. Сюда добавляется ещё то, что многие не умеют пользоваться стандартной java. И не читают спеков для новых версий, ведь многие вещи уже реализованы в новых версиях.
Вот недавний пример.
StringUtils.equalsIgnoreCase(variable, "bla bla");Я говорю, тебе накой тут strignutils нужен, а человек говорит, так NullPointer словлю если сделаю variable.equalsIgnoreCase().... ну то есть сделать наоборот "bla bla".equalsIgnoreCase(variable) уже не круто, надо тащить библиотеку для этого. И это просто пример, такая-же борода на уровне создания сервиса, работы с файлами и т.д. Я не спорю, что библиотеки нужны, фреймворки нужны и т.д. Но использовать это надо с умом. Но с проблемой, сделай как-нибудь, чтоб работало по ТЗ, я тоже согласен и часто встречается.
Это норма.
Как можно качественно обучить айти-специалиста? И главное чему? В отрасли десятки языков и тысячи профессий, все это множится на множество фреймворков и технологий и их всевозможные сочетания: в каждой фирме, на каждом проекте свои стеки. Вот и учат основам в целом, да и то по верхам, с прицелом что дальше сам выплывет
А на всяческих курсах учат по минимуму, какой-то одной узкой, но востребованной в вакансиях, нише или инструменту, именно в формате "протащить через процесс разработки пару раз, дальше сам".
Вот и выходит, что на выходе после института + курсов совсем не специалист, а заготовка специалиста с какой-то минимальной базой, на основе которой можно что-то вырастить. А после голых курсов еще хуже - заготовка без базы, которой будет очень тяжко в дальнейшем карьерном росте.
Естественно в основах такие специалисты сильно плавают, т.к. их этому просто не учили. И такая ситуация на всех основных языках. По отрасли в целом много специалистов, которые освоили фреймворки, но при выходе за пределы фреймворка как слепые котята.
Тут решает только конкретный опыт, у каждого он уникальный. Конечно в целом хорошие или подающие надежды специалисты стремятся приобрести квалификацию, дообучаются дополнительно самостоятельно, читают книги, проходят параллельно множество курсов, ковыряют код, документацию, ядро языка, в общем добирают информацию как могут.
Но нужно быть честным: процент хороших специалистов относительно небольшой. Остальные просто уютненько сидят в освоенной нише и никуда не развиваются. И причины тут разные: интерес, характер, жизненные ценности, обстоятельства, плохой коллектив, бестолковое руководство. Если например человеку в свободное время дети по голове скачут или начальство работой заваливает выше ушей - какое уж тут развитие? Отработать сколько положено и откатиться, больше его ничего не интересует. Да что там, когда началась пандемия и людей погнали на удаленку, многие пытались остаться в офисах, просто потому что не имели возможности работать дома, не имели компьютеров, свободных помещений, или возможности элементарно создать спокойную обстановку. Те кто с комфортом ушел на удаленку - таких оказалось относительно немного.
Так что обилие непродуманных решений - вполне себе норма. Некогда думать, или нет ресурсов на тщательное обдумывание.
И то что склепали избыточный сервис - это мелочь. Потому что есть такие, кто сдает код, который ни разу не запускался, не проходил никакие тесты, и даже на глаз содержит большое количество синтаксических ошибок. Т.е. в принципе код, который даже не имеет шансов скомпилироваться или стартануть. Ну то есть человек видит что написал вообще бред, скорее всего даже понимает это (иначе как он попал на должность программера?), но... берет и отправляет его, еще и бодро рапортует: "задача выполнена!". Вот как это обозвать - я не знаю.
Здравствуйте. А какая альтернатива Spring Boot в данном случае, на Ваш взгляд?
А зачем вам вообще что-то, кроме собственно Java и пары библиотек для работы с JSON и SNS, в данном случае? Вам не нужен DI, IoC для таких маленьких приложений. Там нет сложных тестов и нет сложной иерархии. Нет базы данных. Просто запустите приложение, читайте что приходит на вход из SNS и обрабатывайте.
По поводу JSON — я для lua без библиотек писал за кружку кофе парсер, да. Но в любом другом случае предпочту библиотеку, потому что библиотеке скормили уже кучу JSONов, и там наверняка встречались всякие. И не факт, что нет каких-то уязвимостей, которые можно получить, раскрывая JSON в рекурсии, или, там, парся значение из строки. Так что тут выбор в пользу библиотеки оправдан.
Оправдан ещё и тем, что если появляется бага — ты её фиксишь раз и навсегда, а не до следующего раза.
P.S. Тем более, я не уверен, как под капотом работает Java, но мне казалось, что исходники там вполне так себе компилируются и оптимизируются. Вряд ли же она тащит в бинарник всю библиотеку, которую использует...
А я про библиотеку для работы с JSON и не говорил ничего. Также как и писать свою обёртку для SNS является глупым занятием, разве что для самообразования.
P.S. В Джаве оптимизируется ваш код, а скомпилированные библиотеки, которые вы подключаете, идут как есть внутрь финального Jar файла... Или вы думаете, что андроид приложения просто так разбухли с 10-15 МБ до 250-600 МБ? Там же просто код внутри, картинки - ну даже если там их сотня, то всё равно должно быть не более 50-70 МБ для какого-нибудь приложения Booking... а оно 150 МБ весит...и просто отрисовывает столбик с фильтрами, плашки с отелями и строку поиска, плюс десяток классов для запроса информации с сервера и аналитики. При этом картинки все - это кэш. Так что там просто 150 МБ кода.. представляете сколько кода там просто лежит и ничего не делает? А потом вы смотрите на цену 128 - 256 ГБ айфона, и думаете, чёт стоит дохрена, а если меньше памяти взять, то все приложения уже не влезут...
Или вот Вайбер. 200 МБ! Это блин просто мессенджер. ICQ весила 3.2 МБ. Ладно, добавим пару МБ на аналитику и пару МБ для шифрования. Но что там занимает еще 190 МБ?
Я просто считаю, что используемая память - это тоже ресурс, как оперативная память и процессорная мощность. И если разница в стоимости 10 ГБ или 100 ГБ на хостинге или в облаке вы особо не заметите, то есть другие сферы, где приложения не должны разбухать, потому что это влияет на пользователей довольно сильно. И я пока не видел, чтоб на собеседованиях спрашивали как сделать что-то без библиотеки.
Ну из первого поста про структуру JSON я понял, что и JSON тоже надо руками парсить)
Какие-то ужасы вы рассказываете... Мне казалось, что если библиотеки используется в исходниках как есть — то её тоже надо оптимизировать и брать только то, что надо. А нет — тогда есть /usr/lib и динамическая линковка... Хотя всякие приложения для винды, которые идут в комплекте с полным Net.Runtime в комплекте...
а у новых клиентов работали абсолютно все прежние программы.
Про «абсолютно все» в контексте 95 видны — это перебор :)
Падучая она была страшно — года два назад я поставил оригинальную 95 (с официального диска, не пиратского) на свой ретрокомп (233 пентиум) и смог вспомнить — как оно было тогда.
Пришлось сносить и ставить 98 (там таки норм)
А совместимость с SimCity действительно была важна, так как на тот момент она стояла практически на каждом компьютере (как позже стояли «Линии» :)
(к слову — а ведь я так больше и не играл в эту игру, начиная со времен 486 :)
У нас в компьютерном клубе был один мощный комп, сервер для целого зала бездисковых клиентов, об был на 486 кажется, или даже на одном из первых пентиумов. Так вот, каждый день, с утра до вечера, он выполнял ровно одну задачу: на нем беспрерывно катали цивилизацию. Игр было немного, что было то и катали. К тому же надо понимать: все остальные машины могли катать только досовские рогалики без графона, на фоне чего тот сервак с цветным дисплеем смотрелся просто божественно в глазах голодных до развлечений юнцов.
На второй — стек системных вызовов для веб-сервера Microsoft IIS под Windows.
И что, реально есть люди, которые могут разобраться с подобными схемами? :)
Более того, кроме чуть большей густоты линий на картинке IIS, глубина стеков кажется одинаковой
большей густоты линий
Я про сам принцип рисования схемы.
Вот более привычный мне пример изображения сложной схемы.
Тут все намного понятней :)
Тоже довольно сомнительный подход. Схема достаточно большая, разобраться в мешанине линий непросто. По хорошему, такие схемы стоит разбивать на функциональные блоки, располагать их на разных страницах, а всем соединениям присваивать обозначения в соответствии с расположением. Да, когда много страниц не очень удобно, но при реальной работе, читать такую схему оказывается гораздо проще, чем разбираться в этой пасте карбонаре, что образовалась вокруг мп
Да не такая уж и большая схема, если честно.
Вы правильно вспомнили Линукс в этом контексте, однако почему-то упомянули совместимость с аппаратным обеспечением, хотя вся статья про совместимость с ПО. В ядре принята и строго исполняется заповедь: не сломай программы пользователя твоего. И, что удивительно, эта совместимость сохраняется без мегатонн костылей и тысяч веток кода. Возможно проблема в этом:
репозиторий Windows 10 вырос до 3,5 миллиона файлов и 300 ГБ кода. В команде Windows около 4000 разработчиков, а инженерная система ежедневно выдаёт 1760 лабораторных билдов» в 440 ветках в дополнение к тысячам билдов для проверки пул-реквестов.
Может быть, в MS подобралась неудачная команда. А может в традиционной коммерческой разработке есть некий максимальный объём, при котором система ещё может сохранять техническое качество. И windows превысила этот объём
В ядре может и сохраняется, а вот если на какой-нибудь свежей Убунте запускать софт для старой Убунты, очень часто натыкаешься на "у вас такая-то библиотека новой версии, а нужна старой, не буду работать".
Вообще странное сравнение по объему репозитория-в линуксе говорится про ядро, в винде насколько я понимаю про по сути монорепо со всем от ядра до калькуляторя в системе.
Давайте тогда уж сведем кодобазу ядра+какой-нибудь убунты+ кед и т.д. А еще добавим туда андроид и другие операицонки на ядре линукса.
Я не сравниваю. Я указал на то, что является на мой взгляд корнем проблемы: слишком много людей и слишком много веток.
Ну есть подозрение что если посчитать то же самое для линукса окажется еще больше людей и веток-все таки дистрибутивов на линуксе вагон, и каждый второй пилит свои нескучные обои.
Винда штатно не декомпозируется, отделить nt kernel от kortana внешнему наблюдателю — невозможно. Репо закрытое, свободных данных нет. Компоненты часто сильно зависимы друг ото друга и функционал размазан по большому количеству их.
Вот и сравнивается то, что получается, с тем, что имеется.
Ну тогда хотя бы пытаться сранвивать сранвимое, а не теплое с мягким. У нас есть определенные данные про винду, давайте считать те же цифры для линукса(опенсорс же, все данные доступны), а не пытаться сравнить несколько операицонок на одном ядре, с кучей пользвоательских прилоежний, с голым ядром линукса.
а не теплое с мягким
Фикус в том, что какие-то цифры для винды можно получить только из утечек исходного кода, потому что все остальные, во-первых, не проверяемы, а во-вторых — не понятно, как они считались.
Но там не будут учтены ни 3rd-party компоненты, входящие в поставку, ни новые (а лет с тех пор прошло немало).
Далее, с чем будем сравнивать?
Вот, например, недавно каджит подвигал винду и устанавливал в dual-boot Arch на Thinkpad Tablet X1 Gen3.
Базовая, казалось бы, функциональность: установить уровни заряда батареи, чтобы уйти от нежно и горячо любимого сценария всех производителей буков трахаем аккум около 100% на проводе, потом, когда он становится нужен — выкидываем, потому что он затрахан вусмерть и больше заряд не держит.
Под пингвинами это делается через штаный интерфейс KDE или парой команд в консоли (которые можно завернуть в systemd unit).
Под виндой для этого нужно скачать полугигабайтный (!) инсталлятор Lenovo Vantage, в который входит отдельный движок electron.
И как будем считать: сранвивать сранвимое, то есть исходный код Lenovo Vantage плюсуем к исходникам винды, или теплое с мягким, патамушта иначи ничестна?
То же касается драйверов Realtek на звук и сеть, и еще очень и очень многих вещей.
Не имеет смысл сравнивать абсолюьно разные цифры, я говорю лишь о том что сравнивается размер ядра против размера нескольких операционок с софтом-что ни говорит вообще ни о чем. И весь вывод который делается на основе этого сравнения не имеет смысл т.к. исходный посыл некорректен.
Так юзерспейс разделяется с другими *nix, а у винды — часть общего монорепо.
Ну и вы так и не ответили: если мы включаем kde с зависимостями в сравнение, то Lenovo Vantage (с комплектным eletron вместе), Realtek и прочия и прочия — тоже включаем, или как?
Так юзерспейс разделяется с другими *nix, а у винды — часть общего монорепо
В чем принципиальная разница это хранится в монорепо или отдельных репах?
Ну и вы так и не ответили: если мы включаем kde с зависимостями в сравнение, то Lenovo Vantage (с комплектным eletron вместе), Realtek и прочия и прочия — тоже включаем, или как?
Я предлагаю если не можем сравнить -не сравниваем и не делаем из этого каких-то дальнейших выводов
Может возникать больше ошибок и патенциальных уязвимостей - да,
но не думаю, что это повлияет прямо на разжирение программ, я бы здесь рассуждал больше в сторону электрона и прочих высокоуровневых фреймворках, типа раньше писали всё на C++ и на WinAPI, что занимало всего несколько килобайт, а сейчас на QT и занимает уже 30+ мегабайт.
30+? В одной крутой фирме мы писали всё только на своем внутреннем фреймфорке и прога Hello Word занимала 350 мег.
Ну, по сравнению с электронами и прочим, Qt не настолько уж и жирный. А по функционалу и удобству кроссплатформенной разработки для с++ я даже не знаю, с чем его адекватно сравнить... wxwidgets да GTK есть, но что то оно всё не то..
Я собрал голый винмейн из вижуалки... 10.5КБ(((
Надо в настроечки тыкать что бы меньше места занимало(((
Электрон из коробки работает на всех популярных платформах одинаково. Авторы решили миллион проблем совместимости за пользователя. Потратили на это столетия человеко-часов, которых проект меньшего размера себе позволить не может.
Альтернатив, которые позволяют написать программу на популярном высокоуровневом языке, и чтобы она совершенно одинаково всюду заработала, просто нету.
QT хороша, но всё равно вам придётся сопровождать сборку на каждой системе и бороться со специфичными глюками. А тут можно даже не запускать программу на других системах - заработало на одной, точно так же заработает и на других.
Да, все это верно и всё это правильно. Так оно и есть, да. Но это уже Кроссплатформенное называется.
Именно обратная совместимость, такая как в статье, здесь как мне кажется не совсем причём. Если мы говорим именно про разжиревшие программы. Контексте операционной системы возможно да. А в контексте каких-то прикладных программ, ну допустим сохранили поддержку старого формата файлов, но не выросло же программа за счет этого на 100 МБ условно
По идее виртуализация должна решать проблемы. Сделать её полностью прозрачной, хочет пользователь запускать программу, которая работает только в windows 3.1, значит запускать виртуальную машину с этой ОС, зачем в основной системе поддержка старого кода? Используя виртуальные машины можно эмулировать не то что старые ОС, но и другие архитектуры, производительности современных ПК вполне думаю хватит.
Используя виртуальные машины можно эмулировать не то что старые ОС, но и другие архитектуры, производительности современных ПК вполне думаю хватит.
1)Не факт что хватит. i5-3570k в досбокс master of orion 2 заметно подлагивает. Даже после настройки производительности.
2)а как-же сеть? Вот хочу я поиграть в старый red alert по сети... а ему нужен ipx. Ну и толку от того, того что программа запустилась?
А в wine? Это что-то среднее между виртуалками и нативом: прослойка с трансляцией вызовов и костылями для обратной совместимости.
Вот человеку удалось запустить ipx через ipxemu
i5-3570k в досбокс master of orion 2 заметно подлагивает
Досбокс какой версии? А то оригинал похоже заброшен, а вот Dosbox-X вполне нормально гоняет второй Орион.
1)Не факт что хватит. i5-3570k в досбокс master of orion 2 заметно подлагивает. Даже после настройки производительности.А с Remnants of the Precursors вы ещё не сталкивались? Вполне залипательная космическая 4x стратегия в стиле первого MOO. Галактика в ней может быть ОЧЕНЬ большой, как и количество конкурирующих цивилизаций. Репозиторий с исходниками игры находится на GitHub.
2)а как-же сеть? Вот хочу я поиграть в старый red alert по сети... а ему нужен ipx. Ну и толку от того, того что программа запустилась?
Так, вроде, при виртуализации и сеть виртуализируется - не то, что протоколы - модели сетевого адаптера для разных виртуалок вполне могут быть разными - я как-то даже "NE2000" прописывал для совсем древней ОС...
Каждая следующая версия Windows была обязана запускать все программы, которые запускались на предыдущей версии
Неправда. На 64 битных версиях программы под дос не запускаются без стороннего эмулятора.
Помянем IA64, окончательно похороненный в июле прошлого года, минутой молчания
В общем, Microsoft была одержима обратной совместимостью. И это сохранилось в последующие гогоды.
Ну до нас это не дожило, или мелкомягкие просто игнорят проблему того, что их режим совместимости точно не работал ещё во времена спермёрки.
Аналогичную по смыслу статью читал в журнале "Хакер" за 1999 год. Тогда этот журнал был еще бумажный, и его продавали в киосках. Но там, правда, в ожирении софта обвинялось не стремление к обратной совместимости софта, а лень разработчиков. Которые не желают тратить силы на оптимизацию кода. Так что софт жиреет уже давно. И пока прогресс в производительности железа это ожирение компенсирует.
Ключевой момент в том, что старый софт даже после того, как перестаёт поддерживаться, остаётся тайной. Если бы код открыли, в таком случае желающие могли бы адаптировать этот под под новую реальность и никаких проблем со старым софтом не было. Нам старый хлам не нужен, но исходники этого хлама мы вам не отдадим.
Друг как-то притащил исходники одной лабораторной работы на Pascal, которую мы в колледже делали. Была она под DOS. Поколдовав с исходниками сделали аналогичную работу в Delphi для запуска в Windows. Спустя много лет ради интереса запустил эту же работу под Linux. При чём не просто запустив её в Wine, что тоже работает, а скомпилировав её с помощью Lazarus. Переделать пришлось совсем немного.
Сорри, если текст цитаты не точен, но смысл ровно тот:
Linus Torvalds: you don't fucking break userspace!
Если if не исполняется 1000 раз в секунду, он бесплатен.
У юзеров не рвёт пуканы = уже хорошо = PROFIT!!!11 для разработчика.
Тот самый, первый сим-сити был офигенен
Как портят софт ради обратной совместимости