Comments 217
А вот когда на Андроиде я скачал приложение одного известного банка, оно при первом запуске запросило меня кучу разрешений, включая доступ к контактам и GPS, я ему их запретил и оно тупо выключилось — вот тут я и удивился.
когда какой нить фонарик лезет в контакты это сразу наводит на определенные мысли
что его написали ленивые программисты, не заморачивающиеся вопросом а какие реально нужны права?
просто-напросто запрашивают сразу все без разбора?
Не понимаю хайпа вокруг отказа от 32-битного софта. О том, что это легаси, сообщалось миллиард раз. У разработчиков было ну очень дофига времени к этому подготовиться. А профит заметен явно — я уже писал, что поддержка 32-бит Compatibility Mode в ядре — это полтонны костылей. Не говоря уж о том что 64-битный софт работает лучше и быстрее из-за бОльшего количества регистров и улучшенного набора инструкций.
Насчет лучше и быстрее — так же спорное утверждение. К примеру, music от apple — сейчас стабильно крашися раз в день в зависимости от положения звезд и фазы луны.
И да, меня так же огорчает отсутствие возможности играть в старые игры.
Выход, конечно, сидеть на старой версии ОС. Вот только яблочко вынуждает разработчиков обновлять ос: например, swift -> xcode -> catalina
Но вопрос не в новом софте, а в старом.
Microsoft создала туже проблему несколько лет назад, когда на WinPhone и Win8 (В маркете) не пропустили старое .exe ПО (хотя могли и ОС поддерживали, перед смертью они даже пару моделей WinPhone «разлочили»). Результатом оказалось вместо десятилетий наработок тысяч единиц качественного ПО под «устаревие» ОС — тонна мусорного ПО в маркете и полное отсутствие профессионального софта.
Сами посудите, если даже Adobe, как крупная корпорация не может оперативно к релизу перевести свой софт на новую платорму, чего ждать от мелких разработчиков?
Я уже молчу про игры, которые вообще никто не будет портировать.
а какие аналоги с нейросетками есть для дримвьюера?
Вы первый, от кого я услышал о нём первый раз за последние 10 (без шуток) лет. Из этого следует вывод, что аналогов более чем достаточно. Когда-то он был пионером, да. Ещё когда от Макромедии перешёл.
Чем хорош дрим
- Папка сайта. Дрим позволяет просмотраивать в бокой панели структуру, открывая файлы или папки. В принципе это есть и в других редакторах
- Разделение экрана — визуальный и код. Вот этой фичи нигде не видел. Использую горизонтальное деление. Актуально для хтмл-файлов
- Поиск и замена в определенной папке (в коде). Например, если мне нужно создать новую тему для друпала на базе старой, мне надо изменить кусок текста в куче файлов. Или найти, в какой темплейт-файл я вставил код рекламного блока.
- Редактирование CSS, пхп: подсветка синтаксиса, подсказки по коду — это есть во многих редакторах
Спасибо, гляну. Так-то дрим устраивает (учитывая его одноглазую редакцию)
По пункту 2
Плагины-превьюхи в code.visualstudio.com — именно что превью. Редактировать это нельзя. Вставить туда из браузера — нельзя
Brackets — превьюха работает только для хтмл-файлов и надо открывать именно индекс.хтмл проекта. Неудобно. Не знаю, можно ли "превьюху" редактировать
В общем, пока дримвьюер без замены
Если вам под мак, то может помочь Panic Coda. Превью в сплит-скрине не помню, а всё остальное было ещё в версии года так 2013.
Atom. Там множество плагинов на любой вкус и цвет. В том и числе и live view для html. Можно и самому дописать, если чего-то нехватает.
WebStorm — must have. Live Edit есть, но для браузера. На мой взгляд, так надежнее.
VSCode — тоже вариант, но мне не особо нравится.
Не понимаю хайпа вокруг отказа от 32-битного софта. О том, что это легаси, сообщалось миллиард раз. У разработчиков было ну очень дофига времени к этому подготовиться.
Софт тем и принициально хорош, в отличие от людей, что созданный единожды — он работает и работает и кушать не просит, регулярная зарплата ему не нужна.
Баги фиксить, скажем, в отличном (и бесплатном) тренажере клавиатурном выпущенном в 2011 году? Их там по сути и нет, функции свои успешно выполняет тренажер.
Система и софт — разные вещи.
Та-же проблема что сказана выше: xcode -> latest OS version
en.wikipedia.org/wiki/MacOS_Mojave
Какие-то сборища неолуддитов готовых громить станки, право солово.
Аналогично удивляюсь по поводу такой же истерики вокруг дистрибутивов GNU/Linux. Я перешел на 64 бита у себя на десктопе в 2004 году, то есть 15 лет назад.
Написанное вами верно только для развивающихся программ, где постоянно добавляют функционал/фиксят баги. Там разработчики все равно «при программе».
А еще есть стабильные программы, что работают хорошо и давно уже не поддерживаются авторами, ибо не надо и так все хорошо.
А еще есть игры — большая часть из которых разрабатываются как «одноразовые». Такой длительной поддержки, как для рабочего софта для игр не делают (исключения — крайне небольшой процент самых успешных игр).
И если в мире GNU/Linux еще есть надежда на сообщество open source. Слабенькая такая надежда — ибо подавляющее большинство в сообществе это потребители, а не те, кто что то исправляют. Но она хоть есть.
А с традиционно закрытым ПО для Mac — все гораздо грустнее.
За такое количество лет любое ПО либо обновлялось
Вопрос, а откуда деньги на это? Деньги если и были уплачены, то когда-то один раз довольно давно. Баги исправлены, полученная оплата этого как бы неявно требует. Но зачем вносить существенные изменения — переезд на другие API? И за чей счет будет этот банкет?
Вы видимо, сформировали своё мировоззрение во времена «сделаем тяп-ляп по быстрому, потому все равно можно будет заплаткой починить всё, интернет же есть»?
Поверьте, в мире существует огромное количество софта, который не исправляется сколько-нибудь серьезно (и даже вообще не исправляется) и по 10-15 лет.
Он же работает. Зачем туда лезть.
Я вам больше скажу — мы можем сейчас писать более совершенные, более функциональные программы вовсе не потому, что мы более крутые программисты, чем наши предки. Нет, не поэтому. А потому что наш софт опирается частично на софт, уже написанный предыдущими поколениями. И мы просто экономим себе кучу времени, не переписывая постоянно то, что уже и так работает.
И переписывать его весь, дорого. Очевидно, что ни вы и никто другой финансировать не желают. Работает же хорошо, зачем переписывать?
Вот только сейчас Apple заставит переписать. И отвалится куча отличного софта (ну и куча говнософта, конечно, тоже отвалится).
В ответе нет глупости и агрессивности.
Более того, мысль содержит причинно-следственную связь.
Что касается темы разговора. Вот например обновление воркстейшена стоит 150 баксов. Допустим, я использую дома вмваре для того, чтобы на основную систему не ставить кучу тестового софта. Меня все устраивает. Функцию выполняет. Тут же с меня спрашивают 150 баксов просто так.
Или например купил я в 2016 году какой-нибудь бессрочный AutoCad, меня все устраивает. Тут такой раз, и не работает куча плагинов. Ты идешь такой на сайт, а тебе предлагают за 60к рублей в год подписку. Итого ты вынужден платить кучу денег просто за обновление. В крупных компаниях очень принято сидеть на старых версиях, потому-что просто очень дорого обновлять весь рабочий софт и при обновлении софта тоже много чего может поломаться. Это очень опасная дорожка. Заставляя выбирать либо обновление, либо совместимость вы вынуждаете кучу пользователей сидеть на старых версиях с кучей уязвимостей и багов.
Всегда очень смешно от факта, что неолуддиты победили на IT-ресурсе
Забавно что пациент обвиняет большинство в глупости, даже не зная с кем разговаривает, хотя я абсолютно уверен, что большинство на хабре весьма образованное и знающее.
Но потом вы узнали про интернет и все стало плохо.
Вы против прогресса, вы от него беситесь, но почему-то лезете к нам в интернет, лезете в IT, что бы у нас в индустрии орать «Прогресс недопустим!»
> Зарегистрирован 6 октября 2019 г.
А если он не троль, то это еще хуже. Ведь давно известно — чем меньше у человека мозгов и знаний, тем тверже его позиция)
В крупных компаниях очень принято сидеть на старых версиях, потому-что просто очень дорого обновлять весь рабочий софт и при обновлении софта тоже много чего может поломаться.Вот именно! А если в своей компании вы еще используете уникальный софт, написанный за несколько лет своей командой? Переписывать его? тратить 100-500 часов на адаптацию? и столько же сотен тысяч денег. Софт мог быть написан аутсорсом, распущеной уже командой или просто быть очень большим и дорогим.
Что касается разработки, то вы все верно отметили, очень часто дело не заканчивается простым сбилдил под x64, а выливается в кучу багов, и хорошо если код ваш.
Да и производительность — это вопрос не самый простой. Не везде это хоть как-то влияет, а вот памяти жрет больше — факт.
а вот памяти жрет больше — фактКакой именно памяти жрёт больше? Как так получается, что непременно «жрёт больше»? Я исхожу из того, что если, к примеру, приложение выделяет мегабайтный буфер, то какая разница на какой архитектуре это происходит? Понимаю, что можно придумать специфичные кейсы типа буфера не на мегабайт, а скажем, на 1000 указателей, но вы-то, насколько я понял, имеете ввиду общий случай, а не какие-то частности.
RAM consumption
RAM consumption is another important element to take into account, especially on low-end devices since Chrome is incredibly voracious in this sense.
For the test, a scenario as real as possible and identical for the two versions was used by opening several tabs running Gmail, Facebook, CNN, YouTube, BoredPanda and two for Digital Citizen themselves. The test tried to get the maximum possible content playing in each one of them by playing a video on YouTube and loading news on the social network tab.
The results turned out as expected. Chrome 64-bit eats up a lot more memory, taking 1.19 GB in this case, almost doubling the 32-bit version’s 634 MB, according to the OS’ task manager.
laptoplcdrepair.net/chrome-64-bit-vs-chrome-32-bit-performance-ram-consumption-and-security
В любой программе где активно используются указатели, будет использоваться существенно больше памяти.
Ну вот, например, 10000 указателей займёт на x64 на 40 килобайт больше памяти. Вы это и имели ввиду, когда говорили, что «памяти жрет больше»?
А 10 000 указателей это много или мало?
Такое и заметить-то непросто, если специально в код не добавлять соответствующие замеры.Я сравнивал потребление firefox. Разница заметна на глаз и составляет не меньше сотни мегабайт на все процессы в сумме после непродолжительного использования.
Изначальное утверждение состояло в том, что в некоем общем сферическом случае памяти потребляется значительно больше, и без этого прям никак, и это прям факт. Я говорю, что это далеко не всегда так даже для объёмного и серьёзного кода. Это «жрет больше» может порой выражаться в сотнях килобайт всего навсего; это ничто по сравнению даже с каким-нибудь буфером в десяток или хотя бы пару мегабайт, который может выделять приложение. Такое практически нереально заметить без профилирования.
И если какое-то приложение, собранное под x64, потребляет значительно больше памяти, чем его же сборка под x86, то это далеко не всегда связано с размером указателей или выравнивания. Я пару раз видел в коде такое, что автор просто выделял под x64 буферы бОльшего размера, мотивируя это тем, что у юзера на x64 наверняка будет больше оперативки (лично слышал такое).
Факт, что потребление памяти увеличится — очевиден. Хоть один указатель и 32 битный инт в программе да найдется.
Да, теоретически, есть программы, где это увеличение будет ничтожно.
Но на практике — для самых популярных приложений увеличение довольно значительное.
Факт, что потребление памяти увеличится — очевиден. Хоть один указатель и 32 битный инт в программе да найдется.Если вы не испытываете проблем с русским языком, то, наверняка, заметили на пару комментов выше следующее.
никто не спорит с тем, что указатель на x64 занимает в 2 раза больше места, чем на x86ну так зачем писать одно и то же по несколько раз, если уже давно объяснили, что предмет спора не в этом. Если вы не понимаете в чём состоит этот самый предмет, то нет смысла принимать участие в споре.
на практике — для самых популярных приложений увеличение довольно значительное.А вы точно проверили все самые популярные приложения, ну или почти все?
Да никто не спорит с тем, что указатель на x64 занимает в 2 раза больше места, чем на x86. Речь о том, что эти все указатели и выравнивания часто оказываются просто копейками по сравнению с динамически выделяемыми буферами, которые также не редко не содержат ни указателей, ни каких-то других платформозависимых данных.Похоже вы не понимаете глобальность этого утверждения. Какие-то единичные огромные буферы — редкостная редкость, так как чуть ли не любая обработка бьёт блоб на крошечные фрагменты. Была строка, стал dom, ast, дерево, список… Ни браузер, ни компилятор, ни файловый менеджер, ни игра, ни видеоплеер не могут просто взять блоб в память и ничего с ним больше не делать, кроме как хранить.
Ни браузер, ни компилятор, ни файловый менеджер, ни игра, ни видеоплеер не могут просто взять блоб в память и ничего с ним больше не делать, кроме как хранить.Я, простите, окончательно перестал вас понимать. Я никогда не утверждал, что им нужно только хранить данные и ничего с ними не делать (хотя всё же бывает и такое, но обычно не в памяти). Это вы сами придумали и приписали мне свою мысль. И это лишает дискуссию смысла. Я говорил о том, что в этих данных часто могут отсутствовать платформозависимые части вроде указателей. А обработка этих данных часто, хоть и не всегда, может требовать меньше памяти (и это нормально), чем объём самих данных.
Видеоплеер может получать видеопоток без всяких указателей и складывать в буфер с целью дальнейшего воспроизведения. Так же как и, например, мессенджеры и ещё куча приложений работающих с сетью, а также аудио/видео потоками. Файловый менеджер в простейшем случае может наполнять какой-нибудь свой буфер именами файлов с путями и ещё какой-нибудь инфой вообще без всяких указателей. Вы, должно быть, сейчас очень удивитесь, но в данных, которые драйверы и прочий софт получают от разных устройств, также обычно нет никаких указателей. И я подозреваю, что драйвера — это намного более распространённый софт, чем любой отдельно-взятый браузер.
Какие-то единичные огромные буферы — редкостная редкостьВ вашей личной практике (если таковая была) — возможно. Но если рассматривать это глобально, то это просто голословное заявление и не более того. Не вижу ничего такого редкого и вычурного в буфере на несколько мегабайт, например, для того, чтобы сложить в него тот же html (если речь о браузере) с целью дальнейшей обработки.
Я говорил о том, что в этих данных часто могут отсутствовать платформозависимые части вроде указателей.
А вам говорят, что нет, на практике почти любой достаточно сложный продукт (кроме некоторых редких исключений) сильно набит этими частями.
Все механизмы ООП (по крайней мере в с++) на указателях. Виртуальные таблицы всякие. Параметры, переданные по значению — указатели фактически. А еще есть адреса функций и адреса возврата. Вы можете в своем коде вообще указатели ни разу не использовать, но скомпилированный код будет ими набит. А еще любая локальная переменная почти наверняка будет выравнена и в 64 битном коде занимать в 2 раза больше места.
Это подтверждается тестами, которые показывают почти двукратное увеличение потребления памяти.
Не вижу ничего такого редкого и вычурного в буфере на несколько мегабайт, например, для того, чтобы сложить в него тот же html (если речь о браузере) с целью дальнейшей обработки.
Ну и эта самая дальнейшая обработка и займет почти в 2 раза больше места, а после обработки и буфер уже и не нужен. Поэтому пиковое потребление, может и не увеличится в 2 раза, а вот среднее — вполне себе.
Да, можно придумать приложение, которое берет буфер и почти ничего с ним не делает, только хранит и передает куда-то. Например какой-нибудь cat — будет таким примером. Но таких приложений ничтожное меньшинство.
Параметры, переданные по значению — указатели фактически.Я понял вас. До свидания.
Ну очевидно, же, что описался. Имелись ввиду, конечно, по ссылке.
Имелись ввиду, конечно, по ссылке.
Вы вообще в курсе, что параметры можно передавать через регистры, и что на x64 по дефолту так и происходит (для нескольких первых параметров, по крайней мере для майкрософтовского компилера)? Это, конечно, риторический вопрос.
Вы вообще в курсе, что параметры можно передавать через регистры, и что на x64 по дефолту так и происходит (для нескольких первых параметров, по крайней мере для майкрософтовского компилера)?Полагаю вы в курсе, что это всё равно не помогает?
Я, простите, окончательно перестал вас пониматьУ вас есть опыт разработки, хотя бы на уровне крестиков-ноликов?
Я говорил о том, что в этих данных часто могут отсутствовать платформозависимые части вроде указателейВерно. Размер сообщения в мессенджере не должен зависеть от архитектуры процессора.
Так же как и, например, мессенджеры и ещё куча приложений работающих с сетьюС каких пор мессенджеры стали работать с блобами? Каждое сообщение, в которое вы видите — это отдельный объект(указатель), время отправки, автор, аватар автора — всё это указатели. Каждая кнопка вроде «ответить», каждое форматирование текста это тоже указатели. Гиперссыкла это минимум два указателя — текст ссылки и адрес. Поскольку у всего этого есть достаточно сложное оформление, то вполне логично что это представлено в виде DOM в котором есть указатели на родительские, предыдущие, следующие, дочерние элементы для каждой кнопочки, для каждого элемента оформления.
Файловый менеджер в простейшем случае может наполнять какой-нибудь свой буфер именами файлов с путями и ещё какой-нибудь инфой вообще без всяких указателей.Возможно(не проверял) ваши слова верны для ls. Для графического файлового менеджера требуется как минимум два указателя — на иконку и имя файла. Список всего этого будет хранится как минимум в одном массиве. Так экономить память очень тяжело, ведь этот код нужно будет каждый раз писать с нуля, по этому на отображение одной единственной иконки и подписи к ней уйдёт гораздо больше, чем пара указателей.
Вы, должно быть, сейчас очень удивитесь, но в данных, которые драйверы и прочий софт получают от разных устройств, также обычно нет никаких указателейНашли чем удивить. А на что будут указатели, если данные пришли из внешнего источника? На оперативную память сканнера или веб камеры?
И я подозреваю, что драйвера — это намного более распространённый софт, чем любой отдельно-взятый браузер.Как только драйвер становится сложнее, чем при получении пары байт ответить другой парой, в драйвере тут же заведутся структуры данных, а с ними придут и указатели.
Не вижу ничего такого редкого и вычурного в буфере на несколько мегабайт, например, для того, чтобы сложить в него тот же html (если речь о браузере) с целью дальнейшей обработки.Явите свои познания миру, что произйдёт дальше, после того как html положен в буфер на мегабайт. Каким образом браузер узнает что именно рисовать на экране?
Размер сообщения в мессенджере не должен зависеть от архитектуры процессора.Аллилуйя, до вас дошло.
Каждое сообщение, в которое вы видите — это отдельный объект(указатель), время отправки, автор, аватар автора — всё это указатели.Вы в трезвом (?) виде полагаете, что время отправки — это указатель? Или на него непременно где-то есть указатель? Это какое-то новое слово в разработке. Почему непременно должен быть указатель на автора? Точно не может быть в виде айдишника в таблице, нет? Вы посмотрели все месенжеры и пришли к выводу, что там именно указатель на автора?
А на что будут указатели, если данные пришли из внешнего источника? На оперативную память сканнера или веб камеры?Аллилуйя, опять дошло.
Как только драйвер становится сложнее, чем при получении пары байт ответить другой парой, в драйвере тут же заведутся структуры данных, а с ними придут и указатели.Ну заведутся. И что, много заведётся? Я ещё раз вам говорю (уже бог знает который раз), что часто это копейки, по сравнения с фиксированными буферами, которые выделяет драйвер для получения данных.
Драйвер, обрабатывающий видеопоток, это для вас серьёзный драйвер? Надеюсь, вы согласитесь, что в этом случае речь не идёт про пару байт. Ну и что с того? На десятки мегабайт видеопотока появится… ну пусть даже тысяча указателей (непонятно зачем столько, но это, конечно, зависит от того, как драйвер обрабатывает поток, какими порциями и что конкретно делает). По сравнению с буфером (размер которого не зависит от платформы) это пшик (даже 2000 указателей это менее 8 Кб разницы, Карл!), и говорить что прям стало «жрать больше»… ну если хочется, то кто ж запретит.
Явите свои познания миру, что произйдёт дальше, после того как html положен в буфер на мегабайт. Каким образом браузер узнает что именно рисовать на экране?К сожалению, ваша желчь заляпала мне лицо, и писать становится труднее. Но я ещё раз повторю специально для вас. Я не спорю с тем, что бывают случаи (тот же гигантский DOM), когда разница в потреблении будет весьма заметной. И никогда не утверждал, что такого не может быть. Я говорю, что это не является неким сферическим общим случаем. Суть в том, что даже для серьёзного, объёмного софта это не обязательно будет так, и даже для такого софта разница в потреблении может быть незначительной (менее 1%). У меня нет статистики, как оно бывает чаще (и по причине ли указателей и выравниваний), но так и у вас её тоже нет.
Размер отправленного по сети или сохранённого на диск, прошу заметить.Размер сообщения в мессенджере не должен зависеть от архитектуры процессора.Аллилуйя, до вас дошло.
Вы в трезвом (?) виде полагаете, что время отправки — это указатель? Или на него непременно где-то есть указатель?Приведите сюда объявление сообщения. При этом не случайного из-головы, а либо из какого-то популярного проекта, либо на основе какой-то популярной библиотеки
Это какое-то новое слово в разработке. Почему непременно должен быть указатель на автора? Точно не может быть в виде айдишника в таблице, нет?Мы говорим о файле базы данных или же о мессенджере? Опять же, приведите сюда объявление сообщения, чтобы доказать свою правоту.
Вы посмотрели все месенжеры и пришли к выводу, что там именно указатель на автора?И сколько мессенджеров должно существовать, чтобы я был неправ?
Скажите, а драйвер той же веб камеры состоит только из strcpy? Вы не допускаете, что после получения блоба он будет разобран на множество мелких структур уже самим драйвером?А на что будут указатели, если данные пришли из внешнего источника? На оперативную память сканнера или веб камеры?Аллилуйя, опять дошло.
На десятки мегабайт видеопотока появится… ну пусть даже тысяча указателей (непонятно зачем столько, но это, конечно, зависит от того, как драйвер обрабатывает поток, какими порциями и что конкретно делает)Предположения это так хорошо.
По сравнению с буфером (размер которого не зависит от платформы) это пшик (даже 2000 указателей это менее 8 Кб разницы, Карл!)Я не писал драйвера, так что ни подтвердить, ни опровергнуть ваши слова не могу. А почему из всех драйверов вы выбрали именно драйвер видеокарты? Почему не драйвер баз данных? Почему не драйвер принтера?
К сожалению, ваша желчь заляпала мне лицо, и писать становится труднее.Хорошо, прошу без желчи: вот получили html и положили в буфер. Что дальше?
Я не спорю с тем, что бывают случаи (тот же гигантский DOM), когда разница в потреблении будет весьма заметной.html 2 Кб в виде блоба в буфере. Что с ним будет дальше? Или 2 Кб это гиганский размер?
У меня нет статистики, как оно бывает чаще (и по причине ли указателей и выравниваний)Тогда на чём основаны ваши предположения?
но так и у вас её тоже нетДля очевидных вещей статистика не нужна, их просто нужно увидеть.
Вы в трезвом (?) виде полагаете, что время отправки — это указатель? Или на него непременно где-то есть указатель? Это какое-то новое слово в разработке. Почему непременно должен быть указатель на автора? Точно не может быть в виде айдишника в таблице, нет? Вы посмотрели все месенжеры и пришли к выводу, что там именно указатель на автора?
Вы действительно мало чего понимаете в том, как устроен современный софт. Вы хоть один то мессенджер видели как устроен?
Могу привести пример того, как хранят подобные данные большинство популярных мессенджеров, код которых приходилось реверсить. Каждое сообщение это объект, потому что класс. Каждое поле сообщения — это объект. Примеры. Автор — потому что это как минимум строка с идентификатором, а еще может быть объект сам по себе из нескольких полей. Время отправки — да, это очень вероятно указатель, потому что нормальные люди для представления времени используют специальные классы. Текст — класс строки. Какая-нить картинка во вложении — обычно сложный иерархический объект с тучей вспомогательных полей, из которых сам блоб картинки одно ничтожное поле. И то, картинка в памяти не хранится блобом, а пихается в нативный объект для представлениям картинок, который внутри себя еще черти сколько всего содержит прежде чем где-то там хранить блоб с пикселями.
Еще более усугубляется это дело в продуктах гугла, где очень любят орудовать протобуферами даже на уровне кода приложения. А уж как наводнены указателями протобуфер сообщения это уж вообще.
Не вижу ничего такого редкого и вычурного в буфере на несколько мегабайт, например, для того, чтобы сложить в него тот же html (если речь о браузере) с целью дальнейшей обработки.
Такое ощущение, что у вас даже малейшего понятия нет о том, как устроены программы внутри. Никто никогда не работает так с данными. Если говорить об HTML, то это всегда сложная (скорее всего иерархическая) структура данных, в которой каждый элемент, каждый атрибут это отдельный объект. Во всем этом тучи указателей. Так делают, потому что именно так удобно работать с данными программе, а не блобы таскать. HTML превратится в блоб только в один единственный момент — при сериализации для посылки по сети. Даже если мы начнем упарываться data oriented design, что большая редкость для приложений (обычно игры такое делают только), все равно там будут тучи указателей и никто не будет орудовать блобами.
Все ваши примеры не имеют ничего общего с реальностью, и я могу лишь лишний раз подтвердить слова остальных. Любая программа, которая хоть что-то делает, набита указателями под завязку. Даже в hello world они есть. Никто не оперируется блобами, так программы не работают. Даже если вам кажется, что ваш любимый С++ все вам оптимизирует и дает полный контроль над данными, то нифига подобного. Компилятор запросто вставит указатели там, где их никто не ждет. И в итоге это действительно приводит к горькой правде — 64-бита далеко не бесплатны и имеют очень большой оверхед просто из-за указателей, выравниваний и прочего и прочего.
Какой именно памяти жрёт больше? Как так получается, что непременно «жрёт больше»? Я исхожу из того, что если, к примеру, приложение выделяет мегабайтный буфер, то какая разница на какой архитектуре это происходит? Понимаю, что можно придумать специфичные кейсы типа буфера не на мегабайт, а скажем, на 1000 указателей, но вы-то, насколько я понял, имеете ввиду общий случай, а не какие-то частности.Скажите, а откуда такая уверенность, что есть один указатель на огромный буфер? В том же dom будет куча мелких объектов с кучей указателей. И это если не вспоминать про стек вызова, который тоже растёт.
Все указатели в 2 раза больше, все данные выравнены в 64 бита, вместо 32. Да, если у вас на всю программу один большой буфер — то разницы нет. Но большинство современного ООП кода полно указателей и выравненных данных.
Конечно эпл с их политикой сервиса этого никогда не понять, но некоторые станки работают не 10 лет и не 20, медецинское оборудование и много-много чего. И для этого нужно это самое «ненужное легаси».
Вам не нужное, а много кому нужное.
Оскорбления увидел, оставьте их себе пожалуйста, мне не нужны
Все дело в том, что ты пытаешься оправдывать свою луддитскую позицию, а я обслуживаю одну медицинскую(не «медецинскую») организацию уже 10 лет и хорошо знаю как обстоят дела.
Обычно конечный цикл жизни таких систем такой — виртуалка cо старой версией os и проброшенным портом. С теми кто использует LPT, ISA или SCSI сложнее.
И это еще относительно нестарая материнка :)
1. Эти материнки еще есть на aliexpress правда БУ продают чуть ли не по цене новых. (9000-9500р.)
2. Современные материнки того же класса поддерживают и 7 pcie но стоят процентов на 25-30 дороже чем на али (10000-14000 р.). А еще потребуются новые процессор и память.
Тут сложно будет довести до руководства, что подключаемое оборудование стоит гораздо больше, чем топовая материнка процессор и память вместе взятые.
И только какой-то крутой скандал может сподвигнуть вышестоящее руководство из министерства выделить бабло из других фондов, например не сделают ремонт текущей крыши в каком-нить сельском фельдшерско-акушерском пункте, а пустят его на ремонт томографа например.
Для большинства старых программ наверняка можно было сделать legacy-эмулятор а-ля dosbox/dfend for mac и жить спокойно, нет?
CSP, безопасность.
А для хобби — появились бесплатные сервисы, выдающие SSL сертификаты.
А аналогия «сайт для хобби» — ну, такое себе.
Это как не делать пандус для инвалидов, по новым требованиям законодательства с аргументацией «к нам они не ходят».
При этом, если придёт какой-то ДачСтройИнвалидМонитор и скажет, что строения не предназначены для инвалидов — я просто кивну, а не кинусь устранять выявленные недостатки.
Так же и с сайтами — я хочу иметь возможность поднять в локальной домашней сетке пяток сайтов без https и всего остального, не оглядываясь на мнение хедлайнеров интеренета.
Если же дополнить вашу аналогию: вы не просто кивнете ДачСтройИнвалидМонитору, а пойдете устранять если они владеют самой удобной дорогой к вашей даче и не дают ей пользоваться при наличии нарушений, а ваши друзья (да и вы сами) не горят желанием ездить околотками по грязи.
И, как я написал ниже, с гипотетическим переходом на новые процессоры это никак не связано, потому что на новой архитектуре перестанут работать абсолютно все современные приложения, не важно, 32 или 64-битные.
Почитайте, как работает Compatibility Mode (против нативного Long Mode), как ОС переключается в него и обратно, как работают в нём Syscalls (без которых "системные библиотеки" лишь ничего не значащий набор байт), и как это всё запихивается в thread scheduler в ядре. Всё это хорошо описывается в документации AMD на x86_64.
А Apple хочет перейти на свои. И вот они так не умеют.
Аналогично удивляюсь по поводу такой же истерики вокруг дистрибутивов GNU/Linux. Я перешел на 64 бита у себя на десктопе в 2004 году, то есть 15 лет назад. Все эти годы из-за лени многих разрабов я вынужден был терпеть костыли обратной совместимости с 32 битами. Как только заходит разговор о том, что ходить надо на ногах, а не костылях, так начинаются визги и истерики.И почему же вы не выкинули все костыли сами? Ставте генту, выбираете флаги компиляции. Не осилили?
Какие-то сборища неолуддитов готовых громить станки, право солово.
В нём есть пяток платформ, некоторые из них довольно редкие. Сам PIO работает нормально, но компилятор для какой-нибудь херни от TI вышел в 2013 году и не пересобирался с тех пор и не заведётся.
Есть клиент для какого-нибудь станка, который настраивает режимы резки. Станок, по меркам станков, новый, года 2005. Софтинка тоже ничего, даже не под PPC сделана.
Что с этим делать? Вообще НИКАКОГО способа сохранить работу этих программ нет, ни виртуалки, ничего.
Смысл в том, что с каждым обновлением после Sierra ноут работает все медленнее и медленнее, а вот фич, ради которых стоит обновляться нет (конкретно для меня).
P.S. Catalina действительно глючная.
В основном подлагиваний не заметно, но PyCharm почему-то быстрее работает именно на Sierra.
P.S. Я все обновления макоси провожу чистой установкой. Грубо говоря заодно и старый хлам снести, который адекватно не вычищается (не все производител ПО заботятся о пользователе в этом плане).
или обновления не суть как важны?
А что с батареей на каталине? Пишут, что батарейка чересчур расходуется только первые пару дней, пока не завершились фоновые процессы. Потом всё должно прийти в норму
В общем, кто раздумывает над апгрейдом — не стоит пока
Придерживаюсь такой политики ещё со времён 10.9.5 и ни разу не пожалел :-)
Черт с 32 битными приложениями, пусть они заставят ядро работать нормально. После обновления на Калеку 10.15 постоянно падает при засыпании и ругается на EFI. Каждый день по разу. Я в шоке.
Ядро падает возможно из-за того что ноут свежий MBA 2019. Неужели на нем не дотестировали?
На чистую MacOS ставиться без проблем. Что-то мешает ей обновиться.
Решил откатиться полностью на 10.14, а жаль.
Когда в Винде выходил SP с DEP, то инсталлер предупреждал, что такой-то софт на машине работать не будет. Учитывая специфику отрезания API, данную проверку не составило-бы больших проблем реализовать
Так ведь реализовали. Установщик Каталины в самом начале выводит список установленных приложений, которые перестанут работать. Может, у вас просто не было таких приложений, поэтому вы его и не увидели?
Выводит те, что недавно использовались. Про давно заброшенные и затерянные в недрах /Applications не предупреждает.
Вот тут можно посмотреть пример такого предупреждения: https://support.apple.com/en-us/HT208436
Transmit 4.1.7 выпущен 30 апреля 2012!!!
1Password 2.12.2 текущая версия — 7!
iStats Menu 2.9 — уже версия 6
Parallels 2.5 — текущая версия 15!!! Вот тут история версий
А сколько таких же маленьких полезных интересных программок перестали работать при переходах с DOS на Win95, с Win95 на Win2000? И ничего, как-то находилась им замена. Из личного опыта: студентом написал простенькую игрушку под 98, которая ни на 2000, ни на XP уже не завелась, потому что мышиный API поменялся. Так что всегда и на любой операционке случаются моменты выбора: либо возможность нативного запуска старой полезной программки, либо новая функциональность ОС.
Это первое обновление, где Apple отказалась от поддержки 32-разрядных приложений, что необходимо для будущего ухода с процессоров Intel
Ну да, я помню ту знаковую презентацию (2005!), на которой Стив сказал народу, что Apple работает на Intel. Зал ахнул, когда на экране крупно показали это:
Тогда были слова про шаги, которые будут предприняты, чтобы переехать на Intel безболезненно — именно чтобы юзеры не сбежали.
Сегодня, как мы видим, движение пошло в обратном направлении — только пинками и безо всякой «совместимости». И я, почему-то, даже не удивился.
Впрочем, Intel и сам сбавил темпы выдачи на-года хорошего и надежного.
Ну как, движение в сторону делать процы "самим", причем с ничего не говорящими именами, делать под них ПО, платы, вообще все свое — это отличный вендор-лок. Правда, стоит сломать любую мелочь (ОС, или клаву кривую родить) — и ой везде становится.
Подозреваю, что однажды станет нужно покупать подписку на часы использования ОС в течении календарного месяца. А что, за автобус покупаете билет, за каршеринг платите даже за время стояния на светофоре, чего бы не заплатить за право использовать ОС на уже купленном железе, про которое кто-то думает, что оно уже его, собственное?
делать процы «самим», причем с ничего не говорящими именами, делать под них ПО, платы, вообще все своеТак вроде уже проходили это один раз?
Хотят сделать так, чтобы на все платформы ставилось одно и то же приложение, а не три разных. Стоимость разработки должна упасть (1 приложение против двух-трех).
А для этого нужно унифицировать железо.
По сути, они хотят сделать качественный скачок вперед.
Разработчикам все равно придется делать разные приложения и поддерживать их по отдельности. Так что такая унификация — это не качественный скачок вперед. Это гонка за утопической идеей которая принципиально не сможет работать пока будет заметный разрыв в мощности устройств, в их устройствах ввода и в сценариях их использования. Стоимость разработки для всех кроме, возможно, эпла останется такой же, если не вырастет из-за очередного изменения которое сломает все предыдущие наработки. Стоимость разработки для разработчиков из эпл может быть и упадет. В итоге. После того как они перепишут систему с нуля на новой архитектуре что не совсем бесплатно. А к моменту когда они наконец-то выйдут в плюс (если это вообще возможно) — эпл придумает что-то новое и революционное и цикл повторится.
Речь про ipad.
Если любой софт будет запускаться на обеих платформах: max os / ipad os, то это будет реальный качественный скачок.
Разные требования к железу? У софта? ipad pro очень мощная штука.
По UI — согласен. Но это лишь UI. Этот слой будет кастомным для платформ, согласен.
Разные требования к железу? У софта? ipad pro очень мощная штука.
Рендерит видео он так же быстро как и MBP на i7 с 32Гб оперативки?
Виртуалки так же легко вывозит палаллельно с IDE и DB?
Сомневаюсь.
А простые вещи (простые IDE, скрипты, терминал) и сейчас отлично работают. Виртуалка на планшете? Чтобы выжра всю батарею? Для этого есть VPS и прочие сервера.
Это не замена ноуту. Это отличное дополнение.
Доп. экран для вашей прошки. Походный вариант в дороге.
И он вполне способен на многое. И на много не способен.
Ваш MBR обрабатывает данные также как сервак с >125gb RAM и с десятками ядер?
Нет. Но он это делает быстрее, чем планшет.
А простые вещи (простые IDE, скрипты, терминал) и сейчас отлично работают.
Вот давайте возмем относительно простой мой сценарий.
Python IDE (с поддержкой VueJS), PosgreSQL, redis.
У меня язык не поворачивается сказать, что это будет отлично работать.
Виртуалка на планшете? Чтобы выжра всю батарею?
Откуда тогда это удивление?
Разные требования к железу? У софта?
Поддержка виртуализации — это как раз требование к железу у софта. Мы же говорим про любой софт, верно?
Это не замена ноуту. Это отличное дополнение.
Доп. экран для вашей прошки. Походный вариант в дороге.
Это именно дополнение, а не походный вариант. Походный вариант — это ноут.
И он вполне способен на многое. И на много не способен.
Ваши сообщения как-то больше склоняются к замене, а не дополнению.
P.S. У айпада слабое железо.
Речь про ipad.Который все равно заметно слабее даже ноутбуков, имеет отличающийся от ноутбуков и ПК интерфейс ввода и, соответственно, другие сценарии использования. Софт все равно будет либо легковесным и примитивным (в плане количества фич и их сложности, это не эмоциональная оценка, только количественная), либо будет иметь разные версии для разных устройств. И поддерживать их придется отдельно. Понятно что что-то можно будет переиспользовать, но это и сейчас можно — делайте себе легкий клиент с сервером и в путь.
ipad pro очень мощная штукаДля планшета — может быть. По сравнению с ноутбуком? Даже не стационарным ПК, просто ноутбуком. В ipad pro 4-6 Гб оперативной памяти. На стационарном ПК столько может съесть один браузер. Процессор? Нормального сравнения я не нашел, но пока мне не покажут цифры я не поверю что с охлаждением которое можно запихнуть в ipad даже теоретически можно достигнуть каких-то впечатляющих (по меркам хотя бы ноутбуков) результатов. Память? Ладно, это не так уж важно для приложения. Пользовательский опыт использования устройства которое не умеет из коробки даже флешку прочитать мы опустим.
Собственно основные сценарии использования — потребление медиаконтента: видео, музыка, веб серфинг, чтение каких-нибудь комиксов. Может быть какие-нибудь мобильные и браузерные игры или что-то старое, но со старым будут проблемы с интерфейсом. Для всего этого — замечательное устройство (если не смотреть на цену). Но это ведь маленькая часть всего того для чего может быть нужно ПО. И любое ПО которое не выполняет эти сценарии на айпаде будет иметь проблемы. Его все равно придется переписывать, неважно будет ли оно компилироваться тем же компилятором или другим.
Одно точно. Реакты, флутеры и прочие кроссплатформенные UI фреймворки никуда не денутся. SwiftUI не решает глобальной проблемы. Только приводит в порядок экосистему эпл.
Пытаетесь покрыть предложенным решением 100% кейсов.
Намеренно ищите изъяны.
Никто не говорил
По вопросам:
— по бенчмаркам проц в ipad pro близок к прошке, загуглите
— флешку читает из коробки
Дальше продолжать разговор смысла не имеет, ибо вы оперируете своим видением, а не фактами.
Вы пытаетесь планшетом заменить ноут.Вот именно это предложение великолепно иллюстрирует то, что я пытаюсь сказать. Вы сами признаете что у ноута другие сценарии использования и вообще это другой мир. Но потом почему-то опять заводите рассказ о том как ipad такой же как ноутбук по мощности.
P.S. Ну а про флешку вот вам ссылка. Можно и другие источники найти если этот вам не нравится, я в прошлый раз в другом месте об этом читал.
А на виртуальной машине нельзя старую операционку установить и в старые игрушки в виртуалке играть?
У конкурентов Apple — Android и Windows обратная совместимость частично или полностью поддерживается десятилетиями и совсем не хочется, чтобы это менялось.
Тем более, стало очевидно, что модель разработки «все сломать и переписать с нуля» в итоге приводит даже к менее стабильному и эффективному продукту
Ну так-то Win16 и DOS благополучно отвалились в amd64.
С Android тоже не всё гладко. Старые приложения запускаются, но без кнопки «Меню» и костылей для её эмуляции работать с ними крайне сложно и порой невозможно.
Народ видимо уже забыл что висту вообще-то за деньги покупали, а она при этом ломала совместимость со многими драйверами и софтом. Да и по системным требованиями была в полтора-два раза прожорливей предыдущих систем.
Сравнение с вистой, кстати, было не из-за проблем и прохладного приема публикой, а из-за запросов системы безопасности при запуске ПО, которое требует доступ к небезопасным с точки зрения приватности API. При этом, у того же Ализара можно отыскать статьи где он также поливает грязью Apple за наличие этих «дыр» — вроде возможности любой программы захватывать экран и подобное.
Время идёт только вперед
В висте впиливалось новое ядро NT (6.0), которое с небольшими доработками используется и в нынешних 7-8-10.
В висте впиливался UAC, паралельно с которым практически все существующие приложения в принудительном порядке отучивались хранить свои данные в c:\windows\system или в c:\Program Files\
В висте был внедрен component-based servicing (CBS) — тот самый, который превратил систему из кучи дллей в набор связанных компонентов. Всякий оффлайн сёрвисинг появился, опять же. Появились журналы событий и трассировки в том виде, в котором они известны сейчас.
В висте был осуществлен переход на новую модель драйверов — появились userspace-драйвера, а Display driver model была полностью изобретена заново. Звуковая подсистема тоже была заново построена — и это только то, что приходит в голову навскидку за время написания одного комментария.
При этом огромный кусок работы был проведен как раз-таки для того, чтобы сохранить совместимость со старыми приложениями. Была реализована виртуализация ФС, были всякие Installer Detection API, да дофига всего было реализовано.
Естественно, что при таком объеме работы «всё и сразу» не могло взять и сходу заработать. С Вистой было много мороки как у производителей железа, так и у производителей старого софта. Но именно из-за висты стал возможен успех Windows 7 — системе с UI висты, с ядром висты, с софтом из висты — но вышедшей через 3 года, за которые производители ПО подтянули совместимость (а сам Microsoft — подтянул свои средства обеспечения совместимости).
А что такого ломающе-нового в Каталине? Three new features in Apple Mail: mute a thread, block a sender, and unsubscribe. Серьёзно?
Хотят сделать поддержку работы приложений на любом устройстве, без необходимости разрабатывать отдельные версии. UI поправить под каждое устройство — и гуд. Качественный скачек, который не осилил Microsoft.
А поддержка x32 увеличивает стоимость перехода. Вот и сбрасывают.
Ну и мне слабо верится в переход на арм как его видят люди — раз и вся макось на арм. Новое ядро, новые драйвера, новый юзерспейс, все новое. И если переход на интел они смягчили эмулятором повера и тогда не было банально столько софта разного, то здесь ситуация будет во иного раз хуже. Без похожего решения как у МС с эмуляцией x86 приложений на арм ОС это будет катастрофа. Будет проще назвать это другой ОС и плавно вытеснять ею основную макось, либо делать новый формфактор. Им не впервой называть одну и туже ОС разными именами. ios, ipad os, watch os. Теперь будет какая-нить mac os XS pro max.
Пока пользуюсь Firefox — к счастью там в Advanced пока есть кнопка «сам знаю что безопасно, а что нет»
Производительность, на мой субъективный взгляд, выросла после обновления, интерфейс стал лагать намного реже. Мне нравится тренд на закручивание гаек приложениям, который идёт в последних мажорных релизах: лучше явно говорить приложению, что ему можно и нельзя делать, чем позволять делать всё.
Чот чувствую такими темпами следующий мой ноут будет снова винда. Пожил 8 лет с маками и хватит
Как-то раз вечерком, мне пришло сообщение об автообновлении. Как ни в чем ни бывало, я нажал «скачать и перезагрузить», думая что ничего важного в ближайшие пол-часа все равно не планирую. Первое обновление отказалось устанавливаться, т.к. к моменту завершения закачки оно было удалено разработчиками (ребята совершенствуют код на лету!) и мне предложили скачать еще одно. Думаю, ну молодцы же! И еще пара часов у меня как раз есть.
В последующие сутки я получил отличный бонус к стрессоустойчивости и установил новый рекорд без сна. Зависание при установке и настройке позволило мне приобрести бесценный опыт. К тому же это был отличный повод обновить старые 32-битные версии приложений и изучить новые способы принудительной деинсталяции)
Надо сказать, что обновление прошло довольно давно. Но экран системных настроек до сих пор заставляет меня поддерживать тонус, периодически предлагая установить все настройки системы заново. А сколько раз мне пришлось пройти двойную аутентификацию! Потом он захотел пароль от мака, который был у меня много лет назад (когда деревья были большими). Вот это требования к безопасности! Зато я выучил наизусть свой 20-символьный пароль.
Устал перечислять все плюсы, думаю вы и без меня их уже увидели!
С волнением и удовольствием жду какие еще приключения приготовил нам проказник Кук! Надо будет купить мак жене, перенести на него все рабочие проекты и уехать на пару недель в командировку. Пусть тоже порадуется)
Новую macOS Catalina сравнивают по качеству с Windows Vista