Pull to refresh

Comments 217

UFO just landed and posted this here
Не постоянно, а один раз, не надо преувеличивать… и кстати это очень полезная фича, когда какой нить фонарик лезет в контакты это сразу наводит на определенные мысли
Когда фонарик лезет в контакты знать конечно полезно, а его при этом можно запустить не давая доступ к контактам?
UFO just landed and posted this here
Проще было бы просто выдать ему пустой лист контактов и пусть себе читает их. Не нужно перебирать десяток приложений в поисках того самого, которому интернет не нужен в довесок.
UFO just landed and posted this here
кхм, зато делают конечные вендоры типа сяоми и подобные. настраивается общая политика на телефоне на запрет всем, при установке приложений соглашаешься на установку, а затем уже в разделе безопасности можно отдельно давать разрешения однократные или авто. И тот самый приложение-фонарик получает обломинго при запросе контактов.
UFO just landed and posted this here
Так в iOS итак в sandbox все запускается, называется jails. И в macOS эта технология присутствует, правда обязательна она только для приложений из app store и так это не основной источник софта для мак, то и далеко не у всех программ она активна. Но можно убедится в этом открыт Activity Monitor:

Jails это термин из BSD. В макоси и айоси это зовется просто sandbox или seatbelt. Теже профили, которые описывают, что можно, а что нельзя делать приложения внутри песочницы, называются seatbelt профилями. Их много разных.
Кстати майки анонсировали свои сендбоксы в грядущей Win 10X.
Сендбоксы у них давно уже есть свои. Тот же хром ими пользуется.
Пустой лист вызовет подозрения, а вот лист контактов из 100 сгенерированный специально для приложения — уже нет. Вполне тривиальная задача.

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

UFO just landed and posted this here
На iOS — можно, конечно. Более того, гайдлайны App Store прямо говорят, что приложение должно работать по максимуму выданных пользователем прав.

А вот когда на Андроиде я скачал приложение одного известного банка, оно при первом запуске запросило меня кучу разрешений, включая доступ к контактам и GPS, я ему их запретил и оно тупо выключилось — вот тут я и удивился.
А почему его нельзя запустить, не дав ему достук к своим контактам? 0_о Странные вы, яблочники…
когда какой нить фонарик лезет в контакты это сразу наводит на определенные мысли

что его написали ленивые программисты, не заморачивающиеся вопросом а какие реально нужны права?
просто-напросто запрашивают сразу все без разбора?
а вы смешной… я вот сам из тех ленивых программистов, только вот есть одна маааленькая загвоздка, по умолчанию когда создаешь приложение, у него как раз отсутствуют права вообще на все, и вот как раз что бы получить доступ к контактам, как раз наоборот надо отрвать ленивую жопу и включать отдельные sanbox запросы, причем с псояснением для чего это нужно и т.д. Потом получать отдельно апрув у эпла. Так что не знаю о чем вы вообще.
UFO just landed and posted this here
Увы это тоже не прокатит, можно напихать вообще любой говнокод в приложение, но в настройках проекта программист все равно вынужден будет подключать sandbox и включать ручками те галочки которые ему нужны. Т.е. неглядя никакие сторонние модули ничего не могут самостоятельно попросить, т.к. это делается только исключительно вручную самим программистом, включая свой личный кабинет… плюс не достаточно просто включить галочки нужно также написать текст, который юзер увидит при запросе.

Не понимаю хайпа вокруг отказа от 32-битного софта. О том, что это легаси, сообщалось миллиард раз. У разработчиков было ну очень дофига времени к этому подготовиться. А профит заметен явно — я уже писал, что поддержка 32-бит Compatibility Mode в ядре — это полтонны костылей. Не говоря уж о том что 64-битный софт работает лучше и быстрее из-за бОльшего количества регистров и улучшенного набора инструкций.

К сожалению, не все могут себе позволить отказаться от 32битных приложений.
Насчет лучше и быстрее — так же спорное утверждение. К примеру, music от apple — сейчас стабильно крашися раз в день в зависимости от положения звезд и фазы луны.

И да, меня так же огорчает отсутствие возможности играть в старые игры.
Есть приложения, которые обновить ну никак, совсем.
Выход, конечно, сидеть на старой версии ОС. Вот только яблочко вынуждает разработчиков обновлять ос: например, swift -> xcode -> catalina
Я тоже считаю 32х битную архитектуру легаси.
Но вопрос не в новом софте, а в старом.
Microsoft создала туже проблему несколько лет назад, когда на WinPhone и Win8 (В маркете) не пропустили старое .exe ПО (хотя могли и ОС поддерживали, перед смертью они даже пару моделей WinPhone «разлочили»). Результатом оказалось вместо десятилетий наработок тысяч единиц качественного ПО под «устаревие» ОС — тонна мусорного ПО в маркете и полное отсутствие профессионального софта.
Сами посудите, если даже Adobe, как крупная корпорация не может оперативно к релизу перевести свой софт на новую платорму, чего ждать от мелких разработчиков?
Я уже молчу про игры, которые вообще никто не будет портировать.
Отказался от Adobe в пользу аналогов, к тому же без подписки, а с разовой покупкой, да ещё и работают шустрее, стабильнее, плюс давно уже нейросетки прикручены. Но не все готовы привыкнуть к новому хоть и очень похожему как по функциям, так и по интерфейсу.

а какие аналоги с нейросетками есть для дримвьюера?

Вы первый, от кого я услышал о нём первый раз за последние 10 (без шуток) лет. Из этого следует вывод, что аналогов более чем достаточно. Когда-то он был пионером, да. Ещё когда от Макромедии перешёл.

Спасибо за просвещение, т.к до этого момента и не слышал о «Dreamweaver». Моя работа и хобби крутятся около изображения, а не вёрстки, поэтому аналоги не подскажу, гуглите, кто ищет, тот найдёт =)
А не подскажите продукты с поддержкой нейросетей в вашей области?
Тоже работаю с изображениями (и видео), и пока ничего кроме набора Topaz в постоянной работе не использую. Может пропустил что-то интересное?
Luminar, Aurora HDR (тоже от skylum), Программы от Affinity, Pixelmator
UFO just landed and posted this here

Чем хорош дрим


  1. Папка сайта. Дрим позволяет просмотраивать в бокой панели структуру, открывая файлы или папки. В принципе это есть и в других редакторах
  2. Разделение экрана — визуальный и код. Вот этой фичи нигде не видел. Использую горизонтальное деление. Актуально для хтмл-файлов
  3. Поиск и замена в определенной папке (в коде). Например, если мне нужно создать новую тему для друпала на базе старой, мне надо изменить кусок текста в куче файлов. Или найти, в какой темплейт-файл я вставил код рекламного блока.
  4. Редактирование CSS, пхп: подсветка синтаксиса, подсказки по коду — это есть во многих редакторах
UFO just landed and posted this here

Спасибо, гляну. Так-то дрим устраивает (учитывая его одноглазую редакцию)

По пункту 2


  1. Плагины-превьюхи в code.visualstudio.com — именно что превью. Редактировать это нельзя. Вставить туда из браузера — нельзя


  2. Brackets — превьюха работает только для хтмл-файлов и надо открывать именно индекс.хтмл проекта. Неудобно. Не знаю, можно ли "превьюху" редактировать



В общем, пока дримвьюер без замены

Если вам под мак, то может помочь Panic Coda. Превью в сплит-скрине не помню, а всё остальное было ещё в версии года так 2013.

Аналоги:

Atom. Там множество плагинов на любой вкус и цвет. В том и числе и live view для html. Можно и самому дописать, если чего-то нехватает.
WebStorm — must have. Live Edit есть, но для браузера. На мой взгляд, так надежнее.
VSCode — тоже вариант, но мне не особо нравится.
UFO just landed and posted this here
UFO just landed and posted this here
Я даже не знал, что в 2019 им кто-то пользуется.
Не понимаю хайпа вокруг отказа от 32-битного софта. О том, что это легаси, сообщалось миллиард раз. У разработчиков было ну очень дофига времени к этому подготовиться.

Софт тем и принициально хорош, в отличие от людей, что созданный единожды — он работает и работает и кушать не просит, регулярная зарплата ему не нужна.
Баги фиксить, скажем, в отличном (и бесплатном) тренажере клавиатурном выпущенном в 2011 году? Их там по сути и нет, функции свои успешно выполняет тренажер.

Ну так и обновлять систему никто не заставляет. Работает — не трогай, если уж на то пошло

Система и софт — разные вещи.
Та-же проблема что сказана выше: xcode -> latest OS version

У меня раньше было много хороших слов по поводу хваленой совместимости у Майкрософт. Скажем между версиями Server OS, Exchange, Outlook, Client OS. Когда новый Outlook отказывается работать со старым Exchange, а новый Exchange нельзя установить на предыдущую версию серверной системы, а с новые серверные ОС не поддерживают старые клиентские машины и так далее в любых комбинациях. И в итоге ничего не работает, получается какая-то ядерная взаимоблокировка. В итоге приходится тратить кучу денег и времени чтобы с этим разобраться. Впрочем, очевидно что ради денег все и затевалось.
А обновления безопасности на старую версию как долго ещё будут приходить?
Аналогично удивляюсь по поводу такой же истерики вокруг дистрибутивов GNU/Linux. Я перешел на 64 бита у себя на десктопе в 2004 году, то есть 15 лет назад. Все эти годы из-за лени многих разрабов я вынужден был терпеть костыли обратной совместимости с 32 битами. Как только заходит разговор о том, что ходить надо на ногах, а не костылях, так начинаются визги и истерики.
Какие-то сборища неолуддитов готовых громить станки, право солово.
Аналогично удивляюсь по поводу такой же истерики вокруг дистрибутивов GNU/Linux. Я перешел на 64 бита у себя на десктопе в 2004 году, то есть 15 лет назад.

Написанное вами верно только для развивающихся программ, где постоянно добавляют функционал/фиксят баги. Там разработчики все равно «при программе».

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

А еще есть игры — большая часть из которых разрабатываются как «одноразовые». Такой длительной поддержки, как для рабочего софта для игр не делают (исключения — крайне небольшой процент самых успешных игр).

И если в мире GNU/Linux еще есть надежда на сообщество open source. Слабенькая такая надежда — ибо подавляющее большинство в сообществе это потребители, а не те, кто что то исправляют. Но она хоть есть.

А с традиционно закрытым ПО для Mac — все гораздо грустнее.
За такое количество лет любое ПО либо обновлялось и разрабы могли выпустить нормальную версию, либо устарело и ему на смену пришло другое.
За такое количество лет любое ПО либо обновлялось


Вопрос, а откуда деньги на это? Деньги если и были уплачены, то когда-то один раз довольно давно. Баги исправлены, полученная оплата этого как бы неявно требует. Но зачем вносить существенные изменения — переезд на другие API? И за чей счет будет этот банкет?

Вы видимо, сформировали своё мировоззрение во времена «сделаем тяп-ляп по быстрому, потому все равно можно будет заплаткой починить всё, интернет же есть»?

Поверьте, в мире существует огромное количество софта, который не исправляется сколько-нибудь серьезно (и даже вообще не исправляется) и по 10-15 лет.

Он же работает. Зачем туда лезть.

Я вам больше скажу — мы можем сейчас писать более совершенные, более функциональные программы вовсе не потому, что мы более крутые программисты, чем наши предки. Нет, не поэтому. А потому что наш софт опирается частично на софт, уже написанный предыдущими поколениями. И мы просто экономим себе кучу времени, не переписывая постоянно то, что уже и так работает.

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

Вот только сейчас Apple заставит переписать. И отвалится куча отличного софта (ну и куча говнософта, конечно, тоже отвалится).

Я сформировал свое мировозрение когда ты еще не родися, когда тебя даже в планах не было. Судя по глупости и агрессивности тебе лет 20, ты чуть младше моего сына, только вот сын у меня умный, а ты нет, так уж вышло.

В ответе нет глупости и агрессивности.
Более того, мысль содержит причинно-следственную связь.

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

Что касается темы разговора. Вот например обновление воркстейшена стоит 150 баксов. Допустим, я использую дома вмваре для того, чтобы на основную систему не ставить кучу тестового софта. Меня все устраивает. Функцию выполняет. Тут же с меня спрашивают 150 баксов просто так.
Или например купил я в 2016 году какой-нибудь бессрочный AutoCad, меня все устраивает. Тут такой раз, и не работает куча плагинов. Ты идешь такой на сайт, а тебе предлагают за 60к рублей в год подписку. Итого ты вынужден платить кучу денег просто за обновление. В крупных компаниях очень принято сидеть на старых версиях, потому-что просто очень дорого обновлять весь рабочий софт и при обновлении софта тоже много чего может поломаться. Это очень опасная дорожка. Заставляя выбирать либо обновление, либо совместимость вы вынуждаете кучу пользователей сидеть на старых версиях с кучей уязвимостей и багов.
В очередной раз наслаждаюсь тем, что на хабре в основном представители интеллектуального большинства, то есть люди глупые и что здесь пропаганда неолуддизма не нужна, тут неолуддиты давно победили.
Всегда очень смешно от факта, что неолуддиты победили на IT-ресурсе
В очередной раз вижу хамоватое быдло с полным отсутствием аргументации и переходом на личности, пытающееся замаскировать своё плохое воспитание и крайнюю степень ограниченности псевдоинтеллектуальностью, возрастом и какими-то фантомными сыновьями.

Забавно что пациент обвиняет большинство в глупости, даже не зная с кем разговаривает, хотя я абсолютно уверен, что большинство на хабре весьма образованное и знающее.
Малыш, я на хабре с 2006 года, когда тут еще было приличное общество, а хамов и неолуддитов, типа тебя тут не было, да вы еще просто и не знали про интернет
Но потом вы узнали про интернет и все стало плохо.
Вы против прогресса, вы от него беситесь, но почему-то лезете к нам в интернет, лезете в IT, что бы у нас в индустрии орать «Прогресс недопустим!»
> я на хабре с 2006 года
> Зарегистрирован 6 октября 2019 г.
Вот я не поленился даже зарегистрироваться, что бы ответить.

Человек либо троль, либо троль. Общался с ним немного в другой теме. Наверняка уже 10ый акк, возможно, что есть и основной с хорошим рейтингом.
Малыш, я пишу код в продакшн с 2006 года. А вот Вы, судя по манере общения, в 2006 под стол ходили. Ну и дата регистрации для 2006 года странная «Зарегистрирован 6 октября 2019 г.» И сразу хамить начал.
По моему вы напрасно тратите свое время и силы на обычного, нетолстого троля…
А если он не троль, то это еще хуже. Ведь давно известно — чем меньше у человека мозгов и знаний, тем тверже его позиция)
Правильно, не надо кормить троля. Это не тот самый 32-ух битный троль, к которому все привыкли. Тут у нас уже современный более толстый 64-ёх битный троль.
А разгадка проста: как раз профессионалы на IT-ресурсе прекрасно понимают, что подход «прогресс ради прогресса» и «сжигание мостов» далеко не всегда оправданы, и уж тем более не могут быть признаны однозначно удачной практикой. А уж хамство, огульные обвинения, апелляция к возрасту и потрясание виртуальным членом ни на одном ресурсе, будь то IT или не IT, не приветствуется.
В крупных компаниях очень принято сидеть на старых версиях, потому-что просто очень дорого обновлять весь рабочий софт и при обновлении софта тоже много чего может поломаться.
Вот именно! А если в своей компании вы еще используете уникальный софт, написанный за несколько лет своей командой? Переписывать его? тратить 100-500 часов на адаптацию? и столько же сотен тысяч денег. Софт мог быть написан аутсорсом, распущеной уже командой или просто быть очень большим и дорогим.
Я подозреваю, что автор выше любит обновляться с торрентов. Потому что если ты привык платить за софт, то даже 150 баксов за программу, которую запускаешь пару раз в месяц и денег с нее не зарабатываешь (пет проекты) это дорого.

Что касается разработки, то вы все верно отметили, очень часто дело не заканчивается простым сбилдил под x64, а выливается в кучу багов, и хорошо если код ваш.

Да и производительность — это вопрос не самый простой. Не везде это хоть как-то влияет, а вот памяти жрет больше — факт.
а вот памяти жрет больше — факт
Какой именно памяти жрёт больше? Как так получается, что непременно «жрёт больше»? Я исхожу из того, что если, к примеру, приложение выделяет мегабайтный буфер, то какая разница на какой архитектуре это происходит? Понимаю, что можно придумать специфичные кейсы типа буфера не на мегабайт, а скажем, на 1000 указателей, но вы-то, насколько я понял, имеете ввиду общий случай, а не какие-то частности.
Вот выдержка из теста 2017 года

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 килобайт больше памяти. Вы это и имели ввиду, когда говорили, что «памяти жрет больше»? Если да, то спорить, конечно, никто не станет, но звучит несколько громче, чем есть на самом деле. Такое и заметить-то непросто, если специально в код не добавлять соответствующие замеры.
Ну вот, например, 10000 указателей займёт на x64 на 40 килобайт больше памяти. Вы это и имели ввиду, когда говорили, что «памяти жрет больше»?

А 10 000 указателей это много или мало?
Такое и заметить-то непросто, если специально в код не добавлять соответствующие замеры.
Я сравнивал потребление firefox. Разница заметна на глаз и составляет не меньше сотни мегабайт на все процессы в сумме после непродолжительного использования.
Ну если прям сам firefox и даже на глаз, то согласен, это всё проясняет. Очевидно, вы правы, и всё дело в указателях.
Без указателей не обойдётся ни одна программа. В каких-то случаях использование x64 на домашнем пк ещё хоть как-то оправдано(адресация более 4 Гб), плюс всё ещё то что под x32 abi ещё не всё портировано. Но для мессенджеров, сред разработки, файловых редакторов и прочего x64 явно не оправдан.
Да никто не спорит с тем, что указатель на x64 занимает в 2 раза больше места, чем на x86. Речь о том, что эти все указатели и выравнивания часто оказываются просто копейками по сравнению с динамически выделяемыми буферами, которые также не редко не содержат ни указателей, ни каких-то других платформозависимых данных.

Изначальное утверждение состояло в том, что в некоем общем сферическом случае памяти потребляется значительно больше, и без этого прям никак, и это прям факт. Я говорю, что это далеко не всегда так даже для объёмного и серьёзного кода. Это «жрет больше» может порой выражаться в сотнях килобайт всего навсего; это ничто по сравнению даже с каким-нибудь буфером в десяток или хотя бы пару мегабайт, который может выделять приложение. Такое практически нереально заметить без профилирования.

И если какое-то приложение, собранное под x64, потребляет значительно больше памяти, чем его же сборка под x86, то это далеко не всегда связано с размером указателей или выравнивания. Я пару раз видел в коде такое, что автор просто выделял под x64 буферы бОльшего размера, мотивируя это тем, что у юзера на x64 наверняка будет больше оперативки (лично слышал такое).

Для тех же браузеров вам уже приводили данные. Почти в 2 раза больше потребление памяти. У большинства пользователей самые тяжелые по памяти приложения, после игр, это браузер и есть.

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

Факт, что потребление памяти увеличится — очевиден. Хоть один указатель и 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. Да, если у вас на всю программу один большой буфер — то разницы нет. Но большинство современного ООП кода полно указателей и выравненных данных.

UFO just landed and posted this here
Часто ПО привязано к железу, а железо что-то само по себе не апдейтится. Оно работает, но его тоже нужно обслуживать
Конечно эпл с их политикой сервиса этого никогда не понять, но некоторые станки работают не 10 лет и не 20, медецинское оборудование и много-много чего. И для этого нужно это самое «ненужное легаси».
Вам не нужное, а много кому нужное.
На «медецинском» оборудовании не обновляют ОС и никуда не пропадет поддержка 32 бит. Там работает то что было продано изначально. Аналогично со станками. Так что данный луддит промазал и сказал глупость.
На оборудовании да, но само оборудование нужно обслуживать и для этого есть софтины, которые внезапно ставятся на ноуты/компы, а вот ноуты/компы обновляются.
Оскорбления увидел, оставьте их себе пожалуйста, мне не нужны
И используется с «медецинским» оборудованием те самые компы и ноуты, которые шли в комплекте, современные тупо не подключаются, нет RS-232, а через переходник не выходит.
Все дело в том, что ты пытаешься оправдывать свою луддитскую позицию, а я обслуживаю одну медицинскую(не «медецинскую») организацию уже 10 лет и хорошо знаю как обстоят дела.
И что-же там будут делать если ноутбук однажды скончается? Выбросят томограф? Будут искать на барахолке совместимое железо? Переходники USB-RS-232 не такая большая редкость.
По ноутбукам не скажу, но новую материнку под сокет 1151v2 не только с RS-232 но и с LPT, причем уже выведенные на заднюю панель, купить не проблема. Совершенно ширпотребную, в обычной рознице.
Там могут быть повышенные требования к надежности. Насколько я знаю asus уже несколько лет лепит китайские nuvoton.
Обычно конечный цикл жизни таких систем такой — виртуалка cо старой версией os и проброшенным портом. С теми кто использует LPT, ISA или SCSI сложнее.
Дык недавно знакомый искал материнку P8Z77-V, потому что в каком-то медоборудовании такая, нужны 5 слотов pcie, тот же сокет ну и еще что-то и найти ее нетривиально. С учетом того что еще и бюджет у медиков не резиновый — это прямо вообще проблема.
И это еще относительно нестарая материнка :)
Ну тут хотя бы есть варинты:
1. Эти материнки еще есть на aliexpress правда БУ продают чуть ли не по цене новых. (9000-9500р.)
2. Современные материнки того же класса поддерживают и 7 pcie но стоят процентов на 25-30 дороже чем на али (10000-14000 р.). А еще потребуются новые процессор и память.
Тут сложно будет довести до руководства, что подключаемое оборудование стоит гораздо больше, чем топовая материнка процессор и память вместе взятые.
Я просто представляю как это бывает: доносить до руководства можно, но у руководства есть бюджеты. И когда в рамках бюджета можно либо отремонтировать один аппарат, либо 10 других то выбирают 10 (потому что десять решенных проблем лучше чем одна проблема). При этом каждый год эти бюджеты еще и оптимизируют, мол согласуем если он будет на 10% меньше чем в прошлом году.
И только какой-то крутой скандал может сподвигнуть вышестоящее руководство из министерства выделить бабло из других фондов, например не сделают ремонт текущей крыши в каком-нить сельском фельдшерско-акушерском пункте, а пустят его на ремонт томографа например.
RS-232 переживёт нас с вами. Альтернативы по соотношению цена\возможности — нет.
Хоть я и согласен, пора избавляться от костылей — но с другой стороны, это немного похоже на гугл с идеей «нет https = ты не пройдёшь на сайт!». А то, что сайт просто хобби для 2.5 людей и никто не будет его переделывать — это шерифа не волнует.
Для большинства старых программ наверняка можно было сделать legacy-эмулятор а-ля dosbox/dfend for mac и жить спокойно, нет?
Думаю, что не выйдет. Эмулятор это по факту виртуалка, а программы должны обращаться к системным ресурсам (банально файлам), так что получается, что уже надо пробрасывать диск, сеть, графику. В общем, та ещё задача получается. Даже если взять Фотошоп, который сам по себе 64 бита, но часть компонентов — 32 бита. Тут уже ничего не заэмулировать. Проще и дешевле оставить слой совместимости 32 бита, который Apple как раз и выпилила.
Думаю, что станет просто медленно: нужно инструкции конвертить x32 => x64.
Firefox тоже включился в это, экстеншенам запрещено стучаться на http:// ресурсы.
CSP, безопасность.
А для хобби — появились бесплатные сервисы, выдающие SSL сертификаты.

А аналогия «сайт для хобби» — ну, такое себе.
Это как не делать пандус для инвалидов, по новым требованиям законодательства с аргументацией «к нам они не ходят».
Допустим, я делаю сарай и баню без пандусов для инвалидов, потому что это хобби-проект и пользоваться этим всем будут я и друзья.
При этом, если придёт какой-то ДачСтройИнвалидМонитор и скажет, что строения не предназначены для инвалидов — я просто кивну, а не кинусь устранять выявленные недостатки.
Так же и с сайтами — я хочу иметь возможность поднять в локальной домашней сетке пяток сайтов без https и всего остального, не оглядываясь на мнение хедлайнеров интеренета.
Все конечно правильно, но вы не учитываете тот факт, что в случае с хэдлайнерами интернета — именно их инструментами пользутся для доступа к вашим сайтам. Собственно никто не мешает вам поднять сайт на http и объяснить каким браузером пользоваться чтобы все заработало у ваших друзей.
Если же дополнить вашу аналогию: вы не просто кивнете ДачСтройИнвалидМонитору, а пойдете устранять если они владеют самой удобной дорогой к вашей даче и не дают ей пользоваться при наличии нарушений, а ваши друзья (да и вы сами) не горят желанием ездить околотками по грязи.
Я пользуюсь 64-разрядной Windows, которая поддерживает 32-разрядные приложения без всяких проблем. Не понимаю, какие такие «костыли» вам приходится аж «терпеть», тем более, что это и не костыли вовсе, а всего лишь дублирующий набор 32-разрядных системных библиотек. Может быть в вашей ОС это не так, но тогда это проблема исключительно вашей ОС, а не поддержки 32-разрядных приложений в целом. Нормальная реализация такой поддержки не должна доставлять никаких неудобств, и более того, она вообще не должна быть заметна для пользователя — всё просто должно работать. И к луддизму это тоже никак не относится, потому что простая перекомпиляция приложения под 64-разрядную архитектуру не является прогрессом — меняется только архитектура, но не функциональность.
UFO just landed and posted this here
тут говорится о проблемах в железе ( что процы выполняют кучу ненужной работы по 64 в 32 и назад) и как сказано в статье, эпл хочет себе проц чисто под 64, соответственно для этого нужна ось чисто под 64, вот и имеем, что имеем
Никакой ненужной работы, по преобразованию из 32-битного кода в 64-битный, процессоры не выполняют, архитектура x86-64 поддерживает нативное исполнение 32-битного кода. Таким образом, вопрос поддержки — наличие 32-разрядных версий системных библиотек.
И, как я написал ниже, с гипотетическим переходом на новые процессоры это никак не связано, потому что на новой архитектуре перестанут работать абсолютно все современные приложения, не важно, 32 или 64-битные.

Почитайте, как работает Compatibility Mode (против нативного Long Mode), как ОС переключается в него и обратно, как работают в нём Syscalls (без которых "системные библиотеки" лишь ничего не значащий набор байт), и как это всё запихивается в thread scheduler в ядре. Всё это хорошо описывается в документации AMD на x86_64.

Поддерживают и выполняют intel процы.
А Apple хочет перейти на свои. И вот они так не умеют.
Apple процы не будут x86. Речь об этом. Если эпл делает свой проц, то это будет арм, а там не будет работать, ни x86, ни x64 код. Ну если только они не решат осилить то, что делает микрософт.
Ну вот, а теперь представьте себе, чисто гипотетически, что майкрософт в Windows 11 тоже заявит о полном отказе от поддержки 32-битных приложений и драйверов. А новые материнки уже не будут совместимы с Windows 10 (как сейчас они не совместимы с Windows 7). И придётся вам также запускать Win 7/10 в виртуалке для какого-нибудь старого хорошего софта.
Более вероятным мне видится отказ от поддержки всех нативных приложений в пользу .NET и UWP — а им уже пофиг на какой архитектуре работать.
Аналогично удивляюсь по поводу такой же истерики вокруг дистрибутивов GNU/Linux. Я перешел на 64 бита у себя на десктопе в 2004 году, то есть 15 лет назад. Все эти годы из-за лени многих разрабов я вынужден был терпеть костыли обратной совместимости с 32 битами. Как только заходит разговор о том, что ходить надо на ногах, а не костылях, так начинаются визги и истерики.
Какие-то сборища неолуддитов готовых громить станки, право солово.
И почему же вы не выкинули все костыли сами? Ставте генту, выбираете флаги компиляции. Не осилили?
Вот есть, скажем, PlatformIO.
В нём есть пяток платформ, некоторые из них довольно редкие. Сам PIO работает нормально, но компилятор для какой-нибудь херни от TI вышел в 2013 году и не пересобирался с тех пор и не заведётся.
Есть клиент для какого-нибудь станка, который настраивает режимы резки. Станок, по меркам станков, новый, года 2005. Софтинка тоже ничего, даже не под PPC сделана.

Что с этим делать? Вообще НИКАКОГО способа сохранить работу этих программ нет, ни виртуалки, ничего.
Если попробовать выпросить исходники у производителя или реверсить?
Интересный вариант для того чтобы остаться на маке. Переехать на линукс или винду выглядит несколько более простой задачей в данном случае. И я сомневаюсь что софт для станка не получится запустить на линуксе.
UFO just landed and posted this here
Не обновляйтесь до Каталины, продолжайте использовать инструмент как раньше.
Не буду утверждать на 100%, но я сильно сомневаюсь, что какая-нибудь Windows 15 без поддержки 32-битных программ будет хоть чуточку стабильнее/быстрее/надёжнее хоть той же семёрки.
UFO just landed and posted this here
Установите систему с чистого листа, а не обновлением. У меня есть приятель который на протяжении наверное 5 лет обновлял свой мак только как обычное обновление и все работало. В какой-то момент правда мусор взял свое. Я уже взял за правило крупные релизы ставить на чистый диск. Немного геморно, потому что надо и приложения установить. Но с обновлением приложений тоже мусор накапливается и плюс новые версии выходят так что здесь как бы профилактика. А потом всю эту установку система и программы на тайм машину. И в любой момент есть чистая копия система плюс программа. А тут глобальное обновление с отказом от 32-х.
UFO just landed and posted this here
По моим наблюдением это уже правило делать более тяжелую версию OSX, но это наблюдение не оценили и заминусили :) habr.com/ru/news/t/470580
Я все тыркаюсь и тыркаюсь… MBP17 скорее всего буду откатывать на High Sierra или даже Sierra.
Смысл в том, что с каждым обновлением после Sierra ноут работает все медленнее и медленнее, а вот фич, ради которых стоит обновляться нет (конкретно для меня).

P.S. Catalina действительно глючная.
UFO just landed and posted this here
Нет, это еще не Т2 и специально брал версию без тачбара (как потом оказалось это был вин).
В основном подлагиваний не заметно, но PyCharm почему-то быстрее работает именно на Sierra.

P.S. Я все обновления макоси провожу чистой установкой. Грубо говоря заодно и старый хлам снести, который адекватно не вычищается (не все производител ПО заботятся о пользователе в этом плане).
но ведь Sierra уже не поддерживается, в следующем году закончится поддержка и у High Sierra
или обновления не суть как важны?
У меня, кстати, после последнего обновления на High Sierra начали частенько крашиться странички в Сафари 11, особенно Ютуб. Надоело до жути.
Спасибо за интересную информацию о том, что проблема с камерой на mojave связана с шифрованием диска.

А что с батареей на каталине? Пишут, что батарейка чересчур расходуется только первые пару дней, пока не завершились фоновые процессы. Потом всё должно прийти в норму
Батарею не заметил что сильно жрать стала. Все в пределах нормы.
UFO just landed and posted this here
В общем, кто раздумывает над апгрейдом — не стоит пока

Придерживаюсь такой политики ещё со времён 10.9.5 и ни разу не пожалел :-)

Черт с 32 битными приложениями, пусть они заставят ядро работать нормально. После обновления на Калеку 10.15 постоянно падает при засыпании и ругается на EFI. Каждый день по разу. Я в шоке.

UFO just landed and posted this here
Пока только обновлением. Еще вылезла неприятность, не удается обновиться на XCode 11.1. Ни обновлением, ни с чистой установки не получается. Придется откатываться.

Ядро падает возможно из-за того что ноут свежий MBA 2019. Неужели на нем не дотестировали?
а полностью закрыть старый икскоде, удалить старую версию в корзину, очистить корзину и только затем уже установить из сторе нову версию?
И так уже делал. Результат тот-же. Скачивает и пытается установить, а потом пишет что не может установить.

На чистую MacOS ставиться без проблем. Что-то мешает ей обновиться.

Решил откатиться полностью на 10.14, а жаль.
UFO just landed and posted this here
Спасибо, за подсказки. Так и сделал. Откатываюсь.
UFO just landed and posted this here
Так статья для хайпа. Я, например, вообще не ощутил никаких проблем от обновления.
Ну так посмотрите кто автор и какие он обычно статьи пишет.

Когда в Винде выходил SP с DEP, то инсталлер предупреждал, что такой-то софт на машине работать не будет. Учитывая специфику отрезания API, данную проверку не составило-бы больших проблем реализовать

Так ведь реализовали. Установщик Каталины в самом начале выводит список установленных приложений, которые перестанут работать. Может, у вас просто не было таких приложений, поэтому вы его и не увидели?

Не выводит. После установки в /Applications лежало одно 32-битное приложение, которое забыл и обнаружил только с помощью информации о системе, где есть список легаси софта.
У меня было единственное уведомление о MS Office

Выводит те, что недавно использовались. Про давно заброшенные и затерянные в недрах /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!!! Вот тут история версий
UFO just landed and posted this here

А сколько таких же маленьких полезных интересных программок перестали работать при переходах с DOS на Win95, с Win95 на Win2000? И ничего, как-то находилась им замена. Из личного опыта: студентом написал простенькую игрушку под 98, которая ни на 2000, ни на XP уже не завелась, потому что мышиный API поменялся. Так что всегда и на любой операционке случаются моменты выбора: либо возможность нативного запуска старой полезной программки, либо новая функциональность ОС.

До сих пор встречается оборудование, которое работает на DOS и W95/W98. И никто ничего не переписал. Есть и ещё более интересные мамонты и мы все пользуемся результатами работы этих устройств, хоть можем и не знать об этом.
Это первое обновление, где Apple отказалась от поддержки 32-разрядных приложений, что необходимо для будущего ухода с процессоров Intel

Ну да, я помню ту знаковую презентацию (2005!), на которой Стив сказал народу, что Apple работает на Intel. Зал ахнул, когда на экране крупно показали это:

Тогда были слова про шаги, которые будут предприняты, чтобы переехать на Intel безболезненно — именно чтобы юзеры не сбежали.

Сегодня, как мы видим, движение пошло в обратном направлении — только пинками и безо всякой «совместимости». И я, почему-то, даже не удивился.

Впрочем, Intel и сам сбавил темпы выдачи на-года хорошего и надежного.

Ну как, движение в сторону делать процы "самим", причем с ничего не говорящими именами, делать под них ПО, платы, вообще все свое — это отличный вендор-лок. Правда, стоит сломать любую мелочь (ОС, или клаву кривую родить) — и ой везде становится.

Эпл спит и видит как будет совать в маки за оверхреналион дерег дешевые АРМ с соответствующей производительностью, а на презентации показывать очередной раз проценты.
«Вы так говорите, словно мы этим, как их, юзерам, обязаны свою прибыль дарить!»

Подозреваю, что однажды станет нужно покупать подписку на часы использования ОС в течении календарного месяца. А что, за автобус покупаете билет, за каршеринг платите даже за время стояния на светофоре, чего бы не заплатить за право использовать ОС на уже купленном железе, про которое кто-то думает, что оно уже его, собственное?
Эм, готовится идейный продолжатель office 365 — MS Office 24/7?
делать процы «самим», причем с ничего не говорящими именами, делать под них ПО, платы, вообще все свое
Так вроде уже проходили это один раз?
Ну вот зачем им это нужно? Неужто чтобы народ перестал Хакинтоши ставить? Иначе не понимаю. Шаг назад. Как выясняется ось допилить до «близко к идеалу» не могут, так ещё и забот с процем прибавится.
Не договорились о чем-нибудь с интелом, посчитали ресурсы и решили что проще заменить на свое и не иметь проблем на переговорах чем идти на уступки. Просто предположение конечно, но мне кажется именно это наиболее вероятная причина ухода от интела.
Apple двигается в сторону унификации — macos/ipad os/ios.
Хотят сделать так, чтобы на все платформы ставилось одно и то же приложение, а не три разных. Стоимость разработки должна упасть (1 приложение против двух-трех).
А для этого нужно унифицировать железо.

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

Если любой софт будет запускаться на обеих платформах: max os / ipad os, то это будет реальный качественный скачок.

Разные требования к железу? У софта? ipad pro очень мощная штука.
По UI — согласен. Но это лишь UI. Этот слой будет кастомным для платформ, согласен.
Разные требования к железу? У софта? ipad pro очень мощная штука.

Рендерит видео он так же быстро как и MBP на i7 с 32Гб оперативки?
Виртуалки так же легко вывозит палаллельно с IDE и DB?
Ваш MBR обрабатывает данные также как сервак с >125gb RAM и с десятками ядер?
Сомневаюсь.

А простые вещи (простые IDE, скрипты, терминал) и сейчас отлично работают. Виртуалка на планшете? Чтобы выжра всю батарею? Для этого есть VPS и прочие сервера.

Это не замена ноуту. Это отличное дополнение.
Доп. экран для вашей прошки. Походный вариант в дороге.

И он вполне способен на многое. И на много не способен.
Ваш MBR обрабатывает данные также как сервак с >125gb RAM и с десятками ядер?

Нет. Но он это делает быстрее, чем планшет.

А простые вещи (простые IDE, скрипты, терминал) и сейчас отлично работают.

Вот давайте возмем относительно простой мой сценарий.
Python IDE (с поддержкой VueJS), PosgreSQL, redis.
У меня язык не поворачивается сказать, что это будет отлично работать.

Виртуалка на планшете? Чтобы выжра всю батарею?

Откуда тогда это удивление?
Разные требования к железу? У софта?

Поддержка виртуализации — это как раз требование к железу у софта. Мы же говорим про любой софт, верно?

Это не замена ноуту. Это отличное дополнение.
Доп. экран для вашей прошки. Походный вариант в дороге.

Это именно дополнение, а не походный вариант. Походный вариант — это ноут.

И он вполне способен на многое. И на много не способен.

Ваши сообщения как-то больше склоняются к замене, а не дополнению.

P.S. У айпада слабое железо.
Речь про ipad.
Который все равно заметно слабее даже ноутбуков, имеет отличающийся от ноутбуков и ПК интерфейс ввода и, соответственно, другие сценарии использования. Софт все равно будет либо легковесным и примитивным (в плане количества фич и их сложности, это не эмоциональная оценка, только количественная), либо будет иметь разные версии для разных устройств. И поддерживать их придется отдельно. Понятно что что-то можно будет переиспользовать, но это и сейчас можно — делайте себе легкий клиент с сервером и в путь.
ipad pro очень мощная штука
Для планшета — может быть. По сравнению с ноутбуком? Даже не стационарным ПК, просто ноутбуком. В ipad pro 4-6 Гб оперативной памяти. На стационарном ПК столько может съесть один браузер. Процессор? Нормального сравнения я не нашел, но пока мне не покажут цифры я не поверю что с охлаждением которое можно запихнуть в ipad даже теоретически можно достигнуть каких-то впечатляющих (по меркам хотя бы ноутбуков) результатов. Память? Ладно, это не так уж важно для приложения. Пользовательский опыт использования устройства которое не умеет из коробки даже флешку прочитать мы опустим.
Собственно основные сценарии использования — потребление медиаконтента: видео, музыка, веб серфинг, чтение каких-нибудь комиксов. Может быть какие-нибудь мобильные и браузерные игры или что-то старое, но со старым будут проблемы с интерфейсом. Для всего этого — замечательное устройство (если не смотреть на цену). Но это ведь маленькая часть всего того для чего может быть нужно ПО. И любое ПО которое не выполняет эти сценарии на айпаде будет иметь проблемы. Его все равно придется переписывать, неважно будет ли оно компилироваться тем же компилятором или другим.
Соглашусь. Программа на планшете даже из-за «пальцевого» интерфейса и отсутствия клавиатуры будет проще декстопного аналога. Следовательно они в принципе не могут быть идентичны. Ну если свои программы они Свифте, то разве не должны они легко компилироваться и для планшетов и для Маков?
Конечно компилируются, но при условии использования одного UI фреймворка, что стало действительностью только что с приходом SwiftUI (iOS 13 и macOS 10.15). До этого был AppKit на макос и UIKit на айос. Совершенно разные и никак не связанные фреймворки. Хотя подозреваю, что сколько нибудь сложный проект все равно выродится в тоже самое — общее ядро и свой UI под каждую платформу. Даже на iOS для телефонов и планшетов такая ситуация, хотя UIKit общий. Собственно, решение эпл назвать iOS, запущенную на планшете, iPadOS лишнее подтверждение, что все эти платформы сильно разные.

Одно точно. Реакты, флутеры и прочие кроссплатформенные UI фреймворки никуда не денутся. SwiftUI не решает глобальной проблемы. Только приводит в порядок экосистему эпл.
Вы пытаетесь планшетом заменить ноут.
Пытаетесь покрыть предложенным решением 100% кейсов.
Намеренно ищите изъяны.
Никто не говорил

По вопросам:
— по бенчмаркам проц в ipad pro близок к прошке, загуглите
— флешку читает из коробки

Дальше продолжать разговор смысла не имеет, ибо вы оперируете своим видением, а не фактами.
Вы пытаетесь планшетом заменить ноут.
Вот именно это предложение великолепно иллюстрирует то, что я пытаюсь сказать. Вы сами признаете что у ноута другие сценарии использования и вообще это другой мир. Но потом почему-то опять заводите рассказ о том как ipad такой же как ноутбук по мощности.
P.S. Ну а про флешку вот вам ссылка. Можно и другие источники найти если этот вам не нравится, я в прошлый раз в другом месте об этом читал.
UFO just landed and posted this here
UFO just landed and posted this here

А на виртуальной машине нельзя старую операционку установить и в старые игрушки в виртуалке играть?

Поставить OS X в виртуалку вы можете без особых напрягов даже под GNU/Linux в KVM, но вот с видюхой для игр, если видюх у вас не две и не делать passthrough будут некоторые проблемы, виртуальная не очень для этого подойдет.
По моим наблюдениям, все виртуалки даже на топовых Маках работают медленно и вызывают перегрев. Даже на простом тестировании в IE11 с помощью VirtualBox современные Маки иногда надолго задумываются.
UFO just landed and posted this here
Главное, чтобы это не стало заразительным примером для остальных.
У конкурентов Apple — Android и Windows обратная совместимость частично или полностью поддерживается десятилетиями и совсем не хочется, чтобы это менялось.
Тем более, стало очевидно, что модель разработки «все сломать и переписать с нуля» в итоге приводит даже к менее стабильному и эффективному продукту
> Android и Windows обратная совместимость частично или полностью поддерживается
Ну так-то Win16 и DOS благополучно отвалились в amd64.
С Android тоже не всё гладко. Старые приложения запускаются, но без кнопки «Меню» и костылей для её эмуляции работать с ними крайне сложно и порой невозможно.
UFO just landed and posted this here
UFO just landed and posted this here
Дык оно и с 7кой так было и с 8кой и тд.
Старый софт не работал или чудил тайминг или еще что-то с ASIO было, нет драйверов для старых карт, Taskam us-122 например. Так что с музыкой те же проблемы :)
Один перевод хотя бы такой статьи в сто раз полезнее чем очередное кликбейтное нытье и высасывание домыслов из пальца.
Народ видимо уже забыл что висту вообще-то за деньги покупали, а она при этом ломала совместимость со многими драйверами и софтом. Да и по системным требованиями была в полтора-два раза прожорливей предыдущих систем.
Сравнение с вистой, кстати, было не из-за проблем и прохладного приема публикой, а из-за запросов системы безопасности при запуске ПО, которое требует доступ к небезопасным с точки зрения приватности 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. Серьёзно?
Уже не раз слышал, что Apple собирается делать новые Маки с 2020 на своих ARM процессорах. Может, они как раз и начали внедрять в Catalin'е эту поддержку ARM, и это заставило их обрезать совместимость с 32 битами, и никаких толком новых фич не запилить, так как идет фактически переход на новую архитектуру.
Вряд ли. При переходе на ARM отвалятся абсолютно все приложения скомпилированные для Intel, неважно, 32- или 64-разрядные: то есть, все существующие. Возможно, они сделают что-то вроде Rosetta для запуска приложений предыдущей архитектуры, но учитывая последние тенденции — скорее всего нет.
Вряд ли. Если они и пилят ядро под ARM (хотя чего там особо пилить с учетом, что с iOS у них практически общее ядро), то вряд ли это как-то должно касаться x86 ветки. 32 бита убрали по самой банальной причине — сброс с себя забот по поддержке слоя совместимости.
Ну так логично, хотят перейти на ARM, унифицировать железо на всех устройствах.
Хотят сделать поддержку работы приложений на любом устройстве, без необходимости разрабатывать отдельные версии. UI поправить под каждое устройство — и гуд. Качественный скачек, который не осилил Microsoft.

А поддержка x32 увеличивает стоимость перехода. Вот и сбрасывают.
Этот скачек не осилила уже сама эпл. project catalyst особых успехов не делает. И это скорее всего вообще тупиковая идея. МС давно дали всем то, что надо и что работает — один общий фреймворк. Логика приложения вся общая, а UI для каждой платформы свой. Эпл эта судьба тоже не обойдет и у них есть кандидат на «общий фреймворк» в виде свифта и swift UI.

Ну и мне слабо верится в переход на арм как его видят люди — раз и вся макось на арм. Новое ядро, новые драйвера, новый юзерспейс, все новое. И если переход на интел они смягчили эмулятором повера и тогда не было банально столько софта разного, то здесь ситуация будет во иного раз хуже. Без похожего решения как у МС с эмуляцией x86 приложений на арм ОС это будет катастрофа. Будет проще назвать это другой ОС и плавно вытеснять ею основную макось, либо делать новый формфактор. Им не впервой называть одну и туже ОС разными именами. ios, ipad os, watch os. Теперь будет какая-нить mac os XS pro max.
Сatalyst вышел в этом году. Успехов не делает — я бы так не сказал.
Это технология для облегчения создания одного приложения под обе платформы.
А все ожидали чудо-кнопку.

Эмуляция, конечно, будет. Как без нее.
Я говорю лишь о том, что легче делать лишь под x64, не поддерживать x32.
Я кажется знаю, чего там ломающего. Глючный тунец они частично внедрили прямо в Finder. Теперь глючит вся ОС.
Аппле как всегда железной рукой гонят своих клиентов к «счастью».
У меня в графиках iStat Pro точно виден момент апгрейда OS — нагрузка на CPU заметно выросла.
У меня некоторые внутренние ресурсы по HTTPS перестали открываться в браузерах Chrome и Safari. Нагугленные свистопляски с добавлением сертификатов в Keychain и выставлением Always Trust не помогли — сейчас браузеры показывают валидную цепочку до ресурса, но браузер открыть их не дает.
Пока пользуюсь Firefox — к счастью там в Advanced пока есть кнопка «сам знаю что безопасно, а что нет»
UFO just landed and posted this here
UFO just landed and posted this here
До сих пор сижу на 10.12.6, точнее после кривой 10.13 и обратного отката на 10.12.6, и не знаю что делать дальше, чем дальше тем хуже, 10.13-10.14 глючные и ничего особо не дающие…
так уж и быть напишу еще раз(выше уже писал))) — а как же обновления безопасности? вдруг что
UFO just landed and posted this here
3 года, Сиерра — закончилась, на следующий год закончится и Хай Сиерра
Господи, как хорошо что я не программист, а простой юзер, и мне можно сидеть на любой операционке, на любом понравившемся железе и хоть совсем ничего не обновлять. Так же можно с грустью смотреть на игры корпораций, ибо все равно лет через дцать они тебя нагонят :(
UFO just landed and posted this here
Мне одному кажется, что после обновления на macOS 10.15 трэкпад стал менее отзывчивым? Ощущение, будто увеличилась задержка между движением пальцев и движением на экране. Объективные замеры показывают задержку 50–60мс. Это единственный минус, который я нашёл.

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

Чот чувствую такими темпами следующий мой ноут будет снова винда. Пожил 8 лет с маками и хватит

UFO just landed and posted this here
Ну зря вы так… Попробую вас убедить на своем примере)
Как-то раз вечерком, мне пришло сообщение об автообновлении. Как ни в чем ни бывало, я нажал «скачать и перезагрузить», думая что ничего важного в ближайшие пол-часа все равно не планирую. Первое обновление отказалось устанавливаться, т.к. к моменту завершения закачки оно было удалено разработчиками (ребята совершенствуют код на лету!) и мне предложили скачать еще одно. Думаю, ну молодцы же! И еще пара часов у меня как раз есть.
В последующие сутки я получил отличный бонус к стрессоустойчивости и установил новый рекорд без сна. Зависание при установке и настройке позволило мне приобрести бесценный опыт. К тому же это был отличный повод обновить старые 32-битные версии приложений и изучить новые способы принудительной деинсталяции)
Надо сказать, что обновление прошло довольно давно. Но экран системных настроек до сих пор заставляет меня поддерживать тонус, периодически предлагая установить все настройки системы заново. А сколько раз мне пришлось пройти двойную аутентификацию! Потом он захотел пароль от мака, который был у меня много лет назад (когда деревья были большими). Вот это требования к безопасности! Зато я выучил наизусть свой 20-символьный пароль.
Устал перечислять все плюсы, думаю вы и без меня их уже увидели!
С волнением и удовольствием жду какие еще приключения приготовил нам проказник Кук! Надо будет купить мак жене, перенести на него все рабочие проекты и уехать на пару недель в командировку. Пусть тоже порадуется)
Sign up to leave a comment.

Other news