Как сказать, по мне классический desktop с главным меню часто удобнее, хотя б тем, что не требуется разгадывать, в какой из 1001 вкладок заспрятана кнопка с нужной функцией, в главном меню искать нужную функцию обычно несравнимо проще. Этим мне не нравится Ribbon в Windows, причём, в отличие от MacOS, в оном функции поиска по UI почти никогда нет. А про типичный Web-интерфейс мне вообще сложно что-то сказать цензурными словами, разве что само слово Web помогает делать эпитеты чуть менее явными. MacOS в этом плане до сей поры держался, но, видать, он тоже начинает капитулировать.
В качестве физических устройств кораздо чаще используются iPhone 6 или iPhone SE, чем iPhone X, к примеру. Так что заметно было б. Скажем, длинные действия в UI-потоке становятся заметными сразу, даже parsing, к примеру. А вот использование enum с параметром, к примеру, заметным в плане производительности не становится. Догадываюсь, что оптимизатор в компиляторе прекрасно справляется с тем, чтоб конечные инструкции процессора не влияли сильно на производительность. Скорость компиляции, как я уже говорил, при этом, конечно, не радует, причём на том самом iCore 5 в три с лишним гигагерца, но если альтернативы — ошибки в runtime — мой выбор однозначен.
Структуру можно создать и в Swift, но по каждому поводу — это будет слишком громоздко. Тем более на практике обычно дело до валидации не доходит. Но для меня смысл не в валидации, а в том, чтоб, например, не спутать местами два параметра, если они оба строковые. К тому ж с отдельной структурой неудобство в том, что параметр скорее всего далее будет в составе другой структуры, а вложенные структуры тоже будут всё запутывать.
Кстати, typealais я нередко пользуюсь, особенно для внутренних типов какого-то стороннего модуля, чтоб, если его вдруг понадобится заменить, то было проще — где он используется, остаётся прежний typealais, меняется только его обхявление.
По моему впечатлению у D достоинств много, впрочем, недостатки узнаются в процессе использования, а с D мне это не доводилось — мало под него toolkit'ов всяких, хоть UI, хоть ORM, и ещё много чего. А вот если говорить о языках программирования, что я знаю с разных сторон, например, Swift, то именно чего-то подобного мне часто не хватает. Я конечно могу влепить что-то вроде typealais Email = String
но тогда, если объявит var email: Email;
то никто не помещает этому свойству присвоить переменную типа String, даже если это someUri.absoluteString. Наследование в этом случае не то, ибо оно, как минимум, невозможно для структур, хотя полиморфизм для этой цели вовсе не нужен.
Если говорить о влиянии на производительность конечного приложения, то я не подмечал, чтоб подобные решения сильно влияли, особенно если учесть т. с. типичный уровень оптимизированности массово создаваемых приложений. На скорость компиляции влиять, конечно, может, но уж лучше пусть долго компилируется, чем искать те ж ошибки в runtime.
И как этот Realm? Мои впечатления от него ужасные, в итоге заменил на CoreData — с ним проблем меньше. Самая главная проблема с Realm у меня — потоки, решения я так и не нашёл, пришлось "менять коней на переправе". Если обращение к базе данных происходит из разных потоков — именно потоков, а не DispatchQueue — выдаёт ошибку. Решения так и не нашёл, смотрел в исходники, а там всё проверяется в классе на C++. Понятно — это даёт межплатформенность, но работать с ним на Swift становится почти невозможно. Мало того, что единственный вариант — создавать свой STA через класс Thread, ибо DispatchQueue, даже если serial, может обрабатывать в разных потоках, ибо кто нынче так часто работает именно на уровне потоков в эпоху многоядерных процессоров, когда пришлось б оптимизировать под каждый процессор отдельно; так ещё и никаким способом не удаётся вообще не нагружать процессор, т. е. по факту избежать разряда аккумулятора. Я некогда в итоге плюнул на этот Realm и решил использовать CoreData.
Интересно даже, кому и как удалось решить эту проблему с Realm.
Хоть у меня о плазме лишь самые общие представления, полагаю, время удержания тоже имеет значение. 15 минут раз в несколько месяцев сделает внедрение чрезвычайно затратным даже при очень высокой мощности. Кстати, небольшое «лирическое отступление» — по самой статье мне тоже не очень понятно, если там речь всего про полторы минуты — может у них больше мощность? Но (возвращаясь к исходной теме) какой б мощности ни удавалось достичь, ведь выработанную энергию надо как-то зайдествовать. Несколько месяцев есть возможность хранить только химическую энергию, в перспективность других вариантов я не верю. Допустим, вырабатываем метиловый спирт или ещё какое-то ограническое топливо. Но чтоб выработать таким «залпом» с хоть сколько-то разумным КПД нужны достаточные мощности оборудования. Которые потом несколько месяцев будут стоять без дела, нечем будет загрузить такую мощность хотя б на 1%. И ещё надо как-то передать эту энергию на установки синтеза топлива, которые в таком количестве будут тоже занимать немалое пространство, а если надо такое количество энергиии вывести из небольшого пространства, то это тоже потребует очень сложной инфраструктуры. Получается, что в таком режиме внедрение станет чрезвычайно затратным, чтоб оно получило хоть какое-то распространение. Разве что для загрузки оборудования по «сбору» энергии ставить несколько реакторов, но много ли их удастся построить в разумные сроки.
Впрочем, если сложно что-то придумать с оболочкой реактора, чтоб та не попадала в виде отдельных ядер в сам реактор, то, полагаю, это тоже мешает увеличить время непрерывной работы реактора.
Кстати, о метиловом спирте — что-то про топливные элементы давно не слышно. Всё как-то пытаются совершенствовать аккумуляторы, но что-то мне кажется, что они всё равно не смогут химическое топливо в ближайшие десятки лет.
Даже удобнее, чем в Windows это на MacOS. Для начала строки вообще отдельная комбинация Ctrl+A, а над стрелками клавиши только для прокрутки. Я про полноразмерную клавиатуру, однако, пользовался в основном Mac-mini, но, полагаю, и на ноутбуках это продумано. И вообще в MacOS на мой взгляд полезных hot key польше, чем в Windows.
Есть данные, что Сфинкс «пел» при определённом ветре. Точно не помню, но чуть ли не до 18-го века. Специалисты-историки, если не путаю, в те времена уже были, так что с документированием проблем не должно было быть. Т. е. не только точность обработки, но и продержалось тысячи лет. Как они (древние египтяне) справились при тогдашних технологиях?
Я слышал, что когда-то давно это говорили. И, насколько понимаю, тогда ещё не знали, что в облаках венеры не вода, а серная кислота. И, вероятно, не знали об активности вулканов. А может и про время оборота вокруг своей оси. А потом с этим стало всё понятно.
Хотя, дело за технологиями, может, к примеру, придумают нанороботов, которые это смогут. Скажем, покроют поверхность алмазами. Или графеном, не знаю на счёт последнего, какая у него температура горения, но алмазы вроде как при 500° C не горят. Ну что делать с серой, тоже что-нибудь придумать. Задача посложнее — как сделать, чтоб вулканы вскоре не вернули status quo. Да и медленное вращение этому может поспособствовать.
Причина, по которой тяжёлые частицы распадаются, когда могут, состоит в том, что они это могут. Если у нас есть одна тяжёлая частица (допустим, мюон), она может распасться на электрон, мюонное нейтрино и электронное антинейтрино. Возможен и противоположный процесс, но для него требуется, чтобы в одном месте собрались три продукта распада. Следовательно, вероятность его мала.
Вот только интересно — протонам в приципе есть на что распадаться, но они не распадаются. В чём их уникальность?
Я имею в виду, что если весь или почти весь углекислый газ превратить в кислород, то доля будет более 90% в отличие от 21% на земле. Для человека такая концентрация кислорода комфортна при давлении ниже земного.
Я б восполнил тем, что не обязательно воссоздавать идентичные условия. Может, азота на марсе и впрямь слишком мало вообще, а не только в атмосфере, точно не знаю. Но об остальном — скажем, больше концентрация кислорода, полученного переработкой цианобактериями углекислого газа — меньше атмосферного давления хватит для дыхания человека. С водой, полагаю, тоже можно найти «адаптивное» решение.
Для сравнения, если появятся технологии, как утилизировать серу и углерод на венере, чтоб из серной кислоты получилась вода, а из углекислого газа — кислород, и даже если от этого в условиях атмосферы почти из одного кислорода на вершинах венерианских гор температура снизится, скажем, до +50° C, это всё равно не позволит опуститься ниже уровня нынешних облаков без сканафдра — давление даже в 10 атмосфер из чистого кислорода моментально вызовет ожог лёгких.
Так что параметры можно и варьировать, но «адаптивно».
О каких, блин, транзакциях мы говорим? Зачем вам транзакции внутри процесса обновления? Делаем снапшот, делаем обновление, если не получилось — возвращаемся назад. Нафига вам в этом процессе ещё внутри какие-то транзакции?
Я не о восстановлении. Если ничего не путаю, в MSI оно вообще отдельно реализуется и опыт показывает, что его полноценной реализацией обычно никто не заморачивается. Но есть такие специфические двоичные файлы, как system.dat и user.dat. И Windows построен так, что информация о DLL должна быть записана ещё и в них. Если запись в них осталась, а файл удалён — потом все использующие приложения будут падать, поэтому нужно обеспечивать атомарность таких действий с учётом того, что электричество могут отключить в любой момент.
Да применялось это. Начиная с 70х годов OS/360 могла вкладываться внутрь OS/360. А туда — можно было ещё одну OS/360 вложить. И там — хоть 100 раз, пока памяти хватит.
Я вообще не об этом. В те годы применялись ERP? Не в теории, а на практике? Реально внедрённых их во всём мире было больше, чем пальцев на одной руке?
После восполнения атмосферы путём растапливания углекислого газа и воды. Думаю, восстановленная атмосфера при отсутствии магнитного поля заметно поредеет не раньше, чем через 1000 лет.
Кстати, запустить сам процесс, насколько я слышал, можно достаточно безопасным способом — нужно синтезировать соединение фтора и серы — наиболее сильный парниковый газ, а дальше цепная реакция. Но толку, если согласно последним данным атмосфера восполнится лишь чуть-чуть.
Что-то я одного не понял — если атмосферу и воду с марса уже большей частью сдуло в космос, то как они вернутся даже при искусственном магнитном оле? Оно лишь остановит этот процесс, но что уже было, обратно не воротить таким способом.
Если б замёрзшей воды и углекислого газа хвататло, полагаю, о воссоздании магнитного поля можно было б вообще первое время не заботиться — даже без него атмосфера сколь-нибудь заметно поредела б не раньше, чем через 1000 лет. Или я ошибаюсь?
Конечно, если рассматривать чисто теоретически, то вполне логично было б искусственным магнитным полем вновь разогреть недра марса, чтоб вулканы восполнили атмосферу. Но сколько на это надо энергии? По мне очевидно, что это количество далеко за пределами нынешних технологий.
Местами есть преувеличения, например, на счёт загрузки телефона за 1 секунду. Я вообще не знаю ни одной GUI ОСи, загружающейся за 1 секунду, а CLI и псевдографика по мне слишком большая жертва ради быстродйствия. Да и GUI бывает разным — OpenBox загружается менее 5 секунд, KDE — всё ж подольше, и я без крайней необходимости обычно выбираю более совершенный GUI в KDE. С играми вообще особая история, специализированные процессоры, в т. ч. GPU, всегда эффективнее, но для прочих целей специализированные процессоры на пользовательских компах вряд ли приживутся. В Windows, впрочем, есть проблема стандартизации — скажем, WPF криво работает с видеобфером, а особой альтернативы использования GPU вне игр не прижилось, не будет ж каждй писать свою прослойку, а GDI для графики использует CPU. Про Windows 95 вообще в 30 Мб отдельная история, Windows так и тянет тяжёлое наследие оптимизации с разделяемыми DLL и т. п., в итоге для их обновления теперь пришлось использовать транзакции, а в этом случае 30 минутам на обновление удивляться не стоит. Автор знает, сколько занимает закрытие банковского дня? А знает почему? Вот они транзакции. Хотя, если перейти к теме приложений, кривое использование ORM порой и впрямь создаёт транзакции почём зря. А всякие Docker'ы и прочие Kubernetes — это решения для создания массового создания крупных систем, что раньше не применялись.
Последнее я б воспринял очень насторожено. Во-первых, прекрасно знаю качество этих автоматических алгоритмов, не думаю, что появится столь значительное исключение. Одно дело — отслеживание, а решения принимают люди, другое — полная автоматизация в таких сферах. Во-вторых, замена людей роботами в силовых ведомствах опасна вообще, ещё больше — в военных целях, тогда роботы могут выйти из-под контроля и фантастические сюжеты о восстании роботов могут стать реальностью.
Кстати, typealais я нередко пользуюсь, особенно для внутренних типов какого-то стороннего модуля, чтоб, если его вдруг понадобится заменить, то было проще — где он используется, остаётся прежний typealais, меняется только его обхявление.
По моему впечатлению у D достоинств много, впрочем, недостатки узнаются в процессе использования, а с D мне это не доводилось — мало под него toolkit'ов всяких, хоть UI, хоть ORM, и ещё много чего. А вот если говорить о языках программирования, что я знаю с разных сторон, например, Swift, то именно чего-то подобного мне часто не хватает. Я конечно могу влепить что-то вроде
typealais Email = Stringно тогда, если объявит
var email: Email;то никто не помещает этому свойству присвоить переменную типа
String, даже если этоsomeUri.absoluteString. Наследование в этом случае не то, ибо оно, как минимум, невозможно для структур, хотя полиморфизм для этой цели вовсе не нужен.И как этот Realm? Мои впечатления от него ужасные, в итоге заменил на CoreData — с ним проблем меньше. Самая главная проблема с Realm у меня — потоки, решения я так и не нашёл, пришлось "менять коней на переправе". Если обращение к базе данных происходит из разных потоков — именно потоков, а не
DispatchQueue— выдаёт ошибку. Решения так и не нашёл, смотрел в исходники, а там всё проверяется в классе на C++. Понятно — это даёт межплатформенность, но работать с ним на Swift становится почти невозможно. Мало того, что единственный вариант — создавать свой STA через классThread, ибоDispatchQueue, даже если serial, может обрабатывать в разных потоках, ибо кто нынче так часто работает именно на уровне потоков в эпоху многоядерных процессоров, когда пришлось б оптимизировать под каждый процессор отдельно; так ещё и никаким способом не удаётся вообще не нагружать процессор, т. е. по факту избежать разряда аккумулятора. Я некогда в итоге плюнул на этот Realm и решил использовать CoreData.Интересно даже, кому и как удалось решить эту проблему с Realm.
Впрочем, если сложно что-то придумать с оболочкой реактора, чтоб та не попадала в виде отдельных ядер в сам реактор, то, полагаю, это тоже мешает увеличить время непрерывной работы реактора.
Кстати, о метиловом спирте — что-то про топливные элементы давно не слышно. Всё как-то пытаются совершенствовать аккумуляторы, но что-то мне кажется, что они всё равно не смогут химическое топливо в ближайшие десятки лет.
Хотя, дело за технологиями, может, к примеру, придумают нанороботов, которые это смогут. Скажем, покроют поверхность алмазами. Или графеном, не знаю на счёт последнего, какая у него температура горения, но алмазы вроде как при 500° C не горят. Ну что делать с серой, тоже что-нибудь придумать. Задача посложнее — как сделать, чтоб вулканы вскоре не вернули status quo. Да и медленное вращение этому может поспособствовать.
Вот только интересно — протонам в приципе есть на что распадаться, но они не распадаются. В чём их уникальность?
Для сравнения, если появятся технологии, как утилизировать серу и углерод на венере, чтоб из серной кислоты получилась вода, а из углекислого газа — кислород, и даже если от этого в условиях атмосферы почти из одного кислорода на вершинах венерианских гор температура снизится, скажем, до +50° C, это всё равно не позволит опуститься ниже уровня нынешних облаков без сканафдра — давление даже в 10 атмосфер из чистого кислорода моментально вызовет ожог лёгких.
Так что параметры можно и варьировать, но «адаптивно».
Я не о восстановлении. Если ничего не путаю, в MSI оно вообще отдельно реализуется и опыт показывает, что его полноценной реализацией обычно никто не заморачивается. Но есть такие специфические двоичные файлы, как system.dat и user.dat. И Windows построен так, что информация о DLL должна быть записана ещё и в них. Если запись в них осталась, а файл удалён — потом все использующие приложения будут падать, поэтому нужно обеспечивать атомарность таких действий с учётом того, что электричество могут отключить в любой момент.
Я вообще не об этом. В те годы применялись ERP? Не в теории, а на практике? Реально внедрённых их во всём мире было больше, чем пальцев на одной руке?
Кстати, запустить сам процесс, насколько я слышал, можно достаточно безопасным способом — нужно синтезировать соединение фтора и серы — наиболее сильный парниковый газ, а дальше цепная реакция. Но толку, если согласно последним данным атмосфера восполнится лишь чуть-чуть.
Если б замёрзшей воды и углекислого газа хвататло, полагаю, о воссоздании магнитного поля можно было б вообще первое время не заботиться — даже без него атмосфера сколь-нибудь заметно поредела б не раньше, чем через 1000 лет. Или я ошибаюсь?
Конечно, если рассматривать чисто теоретически, то вполне логично было б искусственным магнитным полем вновь разогреть недра марса, чтоб вулканы восполнили атмосферу. Но сколько на это надо энергии? По мне очевидно, что это количество далеко за пределами нынешних технологий.
Последнее я б воспринял очень насторожено. Во-первых, прекрасно знаю качество этих автоматических алгоритмов, не думаю, что появится столь значительное исключение. Одно дело — отслеживание, а решения принимают люди, другое — полная автоматизация в таких сферах. Во-вторых, замена людей роботами в силовых ведомствах опасна вообще, ещё больше — в военных целях, тогда роботы могут выйти из-под контроля и фантастические сюжеты о восстании роботов могут стать реальностью.