Есть Magic Wormhole - может "пробивать тоннель" между двумя клиентами за NAT-ом. Сервер использует для инициации, а затем уже прямая передача без использования сервера. Думал вы что-то подобное сделали.
Rust без сборщика мусора - это совсем другой уровень, как-то проводить параллели к Go - не совсем корректно.
Kotlin же вполне может использоваться полноценно и на серверной стороне, так что он самодостаточен, в отличии от Dart (который на сервере хотя и в теории можно, на практике не особо).
тоже самое что и flutter несколько лет назад, смешно даже
Но сам язык Kotlin, конечно, более продвинутый чем Dart. Хотя в Dart есть полезнейшая парадигма const-классов, которая активно используется для оптимизаций - пока в Kotlin такого не добавили.
Тут, получается, для iOS и десктопа - используется рендер через Skiko (обертка над Skia)? Т.е. то же самое что и Flutter, по сути - та же идея и подход.
Дык... Сейчас уже и для C++ есть менеджеры пакетов, хотя это, пожалуй, один из классических. Вы лучше скажите какие ЯП или платформы не имеют данной проблемы.
Вы смотрите уже по факту. А кто кукловодил и устанавливал правила, чтобы элементарное действие было чрезвычайно усложнено? Они самые - корпорации. Все вынуждены играть по их правилам.
Золотая жила иссякла. Наварились лучше всех продавцы лопат.
Сказать что иссякла - нельзя. Еще очень много задач, которые предстоит решить именно с помощью IT. До "вкалывают роботы - счастлив человек" - еще очень далеко и большая часть задач - именно по теме IT.
Но вот что поставили в стойло с помощью отработанных приемов - это да, согласен.
IT еще несколько лет назад казалось устойчивым к закабалению - в случае чего - можно было сделать свою мелкую прогу (Shareware или даже несколько для маркета) - и послать компании с их дурью.
Но, похоже, постепенно нашли как обуздать и эту "дикую лошадь" - применяя десятилетиями (а может и сотнями лет) отработанные приемы.
Один из приемов -принцип разделяй и властвуй.
Разделять начали на уровне технологий - один человек уже не может качественно выполнять все этапы работ. Отдельно DevOPS, отдельно фронт, отдельно бек, отдельно моб., отдельно тестирование, отдельно безопасность и т.д. Причем похоже что эти усложнения и слои добавили без особой практической нужды, как бы искусственно разделили.
Далее, когда разделение создано, усложнение добавлено - мелкие компании тупо не могут конкурировать. Они пытаются играть по правилам, которые установили корпорации (использовать их новомодные языки, платформы и т.д.) - и не выдерживают. Оно все требует слишком больших затрат даже для тривиального функционала.
В итоге тянуть это все могут только крупнейшие игроки - и все работники вынуждены хотеть туда. А там жесткая конкуренция для работников и идти, по сути, некуда. Свой проект уже не вывезешь - слишком замотаешься с этими фреймворками на всех уровнях, так что до релиза с большой вероятностью не дойдешь - и даже если дойдешь - то не вывезешь другие этапы - рекламу, привлечение пользователей и прочее это вот все.
В общем, совмещать отдых с работой - ни отдыха ни работы :) Лучше стандартная схема - отработал, взял отпуск - отдохнул с верой в тропическую сказку. Но без ноутбука, созвонов, авралов и пр.
Я тоже так по молодости пробовал - думал в раю так сказать будет лучше работаться. Фига. Рай постепенно становится адом.
Ну а удаленка или нет - это уже с пляжем не связано. Против удаленки ничего не имею, хотя я бы, возможно, и предпочел отдельный офис для разделения пространства - но пока нет такой возможности по семейным причинам. Плюс в том что работа меня не напрягает и я делаю ее без напряга, по этому особых проблем нет. Кого напрягает - точно лучше дома не заниматься, хотя бы в библиотеку ходить, если нет офиса.
Если есть синхронизация или бэкапы значит ни в какой микросхеме он точно не лежит
Вроде пишут что первая микросхема может передать свой публичный ключ второй микросхеме. И тогда вторая микросхема шифрует публичным ключом свои данные и передает первой - первая расшифровывает внутри себя самой. Т.о. для внешнего мира ключи не доступны. Остается только вопрос - как пользователю понять какая из микросхем делает запрос - его личная или кул-хацкера.
Так основная фишка ж в том что ключ из микросхемы невозможно достать никаким образом - ЭЦП производит сама микросхема без отдачи ключа во внешний мир из своей памяти. Это не плохо, но при синхронизации ключей все-таки есть способ импорта, пусть и зашифрованых данных.
Не удобно. Я просто хочу сделать бекап всего. По одному, во-первых, долго, во-вторых - вдруг забуду какой ключ перенести и потеряю доступ. Нужно все разом. И чтобы было прозрачно, чтобы все ключи я видел.
Что есть открытость при передаче через сторонний сервер?
Копия ключей, передача ключа на другое устройство - это то, чем пользователь должен уметь управлять. Могу ли я передать свои ключи с Android-телефона на iOS-телефон? Есть ли открытый протокол для этого? Или навечное привязывание к вендору?
Есть Magic Wormhole - может "пробивать тоннель" между двумя клиентами за NAT-ом. Сервер использует для инициации, а затем уже прямая передача без использования сервера. Думал вы что-то подобное сделали.
А чем плох Kotlin для бека? Вы не его используете?
Rust без сборщика мусора - это совсем другой уровень, как-то проводить параллели к Go - не совсем корректно.
Kotlin же вполне может использоваться полноценно и на серверной стороне, так что он самодостаточен, в отличии от Dart (который на сервере хотя и в теории можно, на практике не особо).
Так что скорее Kotlin+Kotlin vs Dart+Go.
А вы в курсе что Compose использует Skiko (обертка над Skia) -рендер а не нейтивные элементы?
Но сам язык Kotlin, конечно, более продвинутый чем Dart. Хотя в Dart есть полезнейшая парадигма const-классов, которая активно используется для оптимизаций - пока в Kotlin такого не добавили.
Тут, получается, для iOS и десктопа - используется рендер через Skiko (обертка над Skia)? Т.е. то же самое что и Flutter, по сути - та же идея и подход.
Разница только в языке, получается.
Дык... Сейчас уже и для C++ есть менеджеры пакетов, хотя это, пожалуй, один из классических. Вы лучше скажите какие ЯП или платформы не имеют данной проблемы.
Вы смотрите уже по факту. А кто кукловодил и устанавливал правила, чтобы элементарное действие было чрезвычайно усложнено? Они самые - корпорации. Все вынуждены играть по их правилам.
Сказать что иссякла - нельзя. Еще очень много задач, которые предстоит решить именно с помощью IT. До "вкалывают роботы - счастлив человек" - еще очень далеко и большая часть задач - именно по теме IT.
Но вот что поставили в стойло с помощью отработанных приемов - это да, согласен.
IT еще несколько лет назад казалось устойчивым к закабалению - в случае чего - можно было сделать свою мелкую прогу (Shareware или даже несколько для маркета) - и послать компании с их дурью.
Но, похоже, постепенно нашли как обуздать и эту "дикую лошадь" - применяя десятилетиями (а может и сотнями лет) отработанные приемы.
Один из приемов -принцип разделяй и властвуй.
Разделять начали на уровне технологий - один человек уже не может качественно выполнять все этапы работ. Отдельно DevOPS, отдельно фронт, отдельно бек, отдельно моб., отдельно тестирование, отдельно безопасность и т.д. Причем похоже что эти усложнения и слои добавили без особой практической нужды, как бы искусственно разделили.
Далее, когда разделение создано, усложнение добавлено - мелкие компании тупо не могут конкурировать. Они пытаются играть по правилам, которые установили корпорации (использовать их новомодные языки, платформы и т.д.) - и не выдерживают. Оно все требует слишком больших затрат даже для тривиального функционала.
В итоге тянуть это все могут только крупнейшие игроки - и все работники вынуждены хотеть туда. А там жесткая конкуренция для работников и идти, по сути, некуда. Свой проект уже не вывезешь - слишком замотаешься с этими фреймворками на всех уровнях, так что до релиза с большой вероятностью не дойдешь - и даже если дойдешь - то не вывезешь другие этапы - рекламу, привлечение пользователей и прочее это вот все.
👍 - это ключевой вопрос.
В общем, совмещать отдых с работой - ни отдыха ни работы :) Лучше стандартная схема - отработал, взял отпуск - отдохнул с верой в тропическую сказку. Но без ноутбука, созвонов, авралов и пр.
Я тоже так по молодости пробовал - думал в раю так сказать будет лучше работаться. Фига. Рай постепенно становится адом.
Ну а удаленка или нет - это уже с пляжем не связано. Против удаленки ничего не имею, хотя я бы, возможно, и предпочел отдельный офис для разделения пространства - но пока нет такой возможности по семейным причинам. Плюс в том что работа меня не напрягает и я делаю ее без напряга, по этому особых проблем нет. Кого напрягает - точно лучше дома не заниматься, хотя бы в библиотеку ходить, если нет офиса.
Нужно делать модель демонстрационную.
Думаю что именно для этого все и делается.
Вроде пишут что первая микросхема может передать свой публичный ключ второй микросхеме. И тогда вторая микросхема шифрует публичным ключом свои данные и передает первой - первая расшифровывает внутри себя самой. Т.о. для внешнего мира ключи не доступны. Остается только вопрос - как пользователю понять какая из микросхем делает запрос - его личная или кул-хацкера.
Так основная фишка ж в том что ключ из микросхемы невозможно достать никаким образом - ЭЦП производит сама микросхема без отдачи ключа во внешний мир из своей памяти. Это не плохо, но при синхронизации ключей все-таки есть способ импорта, пусть и зашифрованых данных.
Не удобно. Я просто хочу сделать бекап всего. По одному, во-первых, долго, во-вторых - вдруг забуду какой ключ перенести и потеряю доступ. Нужно все разом. И чтобы было прозрачно, чтобы все ключи я видел.
Не знаю, я прочитал статью, понравилась, плюсанул. Что до оформления кода - то да, не удобно в таком виде.
Для каждого сервиса нужно процедуру повторить? Работает ли это реально или только ваше видение как должно быть?
Копия ключей, передача ключа на другое устройство - это то, чем пользователь должен уметь управлять. Могу ли я передать свои ключи с Android-телефона на iOS-телефон? Есть ли открытый протокол для этого? Или навечное привязывание к вендору?