Децентрализванная связь между мобильными устройствами это на самом деле очень прогрессивная идея. Особенно будет популярна среди подростков. Но вот выстрелит ли? Ведь для того чтобы это работало, нужна некая критическая масса пользователей. Тогда поверх сетевого уровня можно будет вешать различные децентрализованные приложения, и не только файлообмен. Игры, знакомства, мессенджеры, локальная «рация»… Это все давно напрашивалось, надеюсь что-то получится.
Кстати, а Wi-Fi Direct (да и вообще Wi-Fi на современных смартфонах) позволяет держать связь сразу с несколькими устройствами? Для этой технологии было бы очень кстати.
Вот интересный вопрос — а где простой «продвинутый юзер» может применить их в быту (и тем более в смартфоне)? Кроме распознавания капч, ничего в голову не приходит. Для самодельного машинного перевода все-таки знаний простого юзера будет недостаточно. А что еще?
Ладно бы еще была инфраструктура автоматического поиска сложноформализуемой информации — т.е. я даю нейросети подборку картинок и говорю «найди мне все похожие в инете», и оставляю компьютер на ночь — ну так ведь тут именно инфраструктура нужна. И картинки — самое примитивное (с чем современные нейросети вероятно справятся), а если нужны более сложные задачи — поиск и подборка текстовой информации на определенную тему?
Может быть, откроют новые физические принципы передачи информации. Как минимум, у нас есть нейтрино — пока их крайне сложно излучать (нужны ускорители) и еще сложнее принимать. Но кто знает, может удастся создать какой-нибудь метаматериал, с помощью которого удастся на порядки сократить размеры оборудования…
Еще крайне привлекательно было бы использовать квантовую запутанность. Нет, не для сверхсветовой передачи — для обычной, но такой, чтобы вообще не нужен был посредник (фотоны и прочее). Т.е. «дальнодействие». Но с запутанностью все пока запутано — есть мнение что это просто «правый и левый ботинки» и никакая передача информации этим способом невозможна вообще. Хотя может быть, удастся сделать что-то с помощью слабых квантовых измерений
Еще есть гравитация. Пока совсем малоизученная, принимающих устройств всего несколько штук в мире, и все они длиной несколько километров. Способы компактификации пока вообще не просматриваются, хотя было бы заманчиво придумать метаматериал, собранный буквально из отдельных атомов… но тут практически 100% нет. Привычная нам материя слишком груба для этих целей.
Зачем для этого создавать ОС? Вполне достаточно существующих. Все что нужно — специальное клиентское приложение, которое будет сидеть в фоне и обслуживать сеть. Но такое и сейчас в том или ином виде есть (i2p например).
Также, нужно понимать, что для истинно децентрализованной сети нужно чтобы пользователь согласился хранить как минимум терабайты данных, и предоставил свой канал доступа в интернет для целей сети. Информация в такой сети будет дублироваться даже не в тысячекратных объемах — в миллионнных или даже больше.
И предоставить пользователю «распоряжаться своей информацией» точно не получится — скорее наоборот, вместо предоставления информации в единоличное распоряжение корпорации (гуглу, фейсбуку и т.д.) пользователь предоставит ее миллионам других пользователей для распределенного хранения. Удалить что-либо из такой сети будет невозможно в принципе.
Лично меня это вполне устраивает — сеть это по определению публичное место, куда не стоит выкладывать что-то слишком персональное; а свойство информации копироваться — фундаментальное, и никакими законами это не ограничить. Но вот всех ли это устроит также как меня?
Было бы интересно узнать про современное состояние сети, интеграцию с интернетом (ну логично же сейчас пользоваться именно интернетом как транспортным уровнем, а не телефонными линиями… или нет?), современное программное обеспечение, взаимосвязь с современным p2p даркнетом- i2p, retroshare и т.д. (если таковая имеется).
После МРТ я себя прекрасно чувствовал. Там единственная проблема — нужно долго лежать совершенно неподвижно (это разумеется требует некоторого напряжения и может в конечном итоге ухудшить самочувствие), ну и звуки уж очень специфические, кому-то вполне могут давить на нервы.
Когда я учился (начало 2000-х), у нас пару лекций по социологии вел (замещал основного лектора, который заболел) какой-то дедок, который толкал нам под видом социологии что-то из КОБ («концепции общественной безопасности»). Ну предмет непрофильный, экзаменов мы по этому бреду к счастью не сдавали. Что интересно, этот дед пытался еще и заработать на этом, продавая дискеты с материалами.
Так что это реально, тем более сейчас. Многие преподы вообще достаточно вольно относятся к тому, что они говорят на лекциях, и всякого рода отсебятину, а то и псевдонауку, регулярно вещают.
А есть еще «объектно-ориентированный» (или «модульный»?) подход, когда просто берется готовая и многократно проверенная реализация сортировки из библиотеки:)
На самом деле я не против функциональных подходов, более того — те же лямбда-функции для меня были одной из самых ожидаемых фич С++. Функции как объекты первого класса это очень круто и удобно.
Но вот жертвовать производительностью и пересоздавать массивы каждый раз… ну не знаю, я на такое не готов.
Для реализации этой идеи напрашивается e-ink экран, встроенный в карточку.
Вместо usb сделать питание по nfc, правда очень не уверен в том, что его будет достаточно для обновления e-ink… но помечтать можно (в конце концов мощность nfc можно увеличить).
Ну и кстати, в рамках nfc вполне можно представить расширения mass storage class и virtual com port. Будут бесконтактные флэшки:)
UPD: не знаю чего вас минусуют, идея-то в целом неплохая, хотя конечно все аспекты не раскрыты.
Мне кажется, что они как всегда решили варить лягушку медленно, и во время первых «учений» ничего серьезного не предпринимали. В том числе и для того, чтобы приучить общественность к этому явлению. Т.е. это по сути «учения» ознакомительные.
Постепенно будут наращивать масштаб и серьезность, возможно через пару лет доберутся и до собственно полномасштабного отключения рунета.
Кстати, а есть сейчас инструменты более легковесные, чем мощные профессиональные декомпиляторы? Например типа утилиты hiew, только в современном интерфейсе.
Что-то типа шестнадцатеричного редактора, совмещенного с ассемблером/дизассемблером, работающим «на лету». Т.е. скажем окно разделено на две части, вводишь несколько hex-кодов в область слева — тут же получаешь дизассемблированный код справа, вводишь ассемблерный код — тут же налету он компилируется в hex-код.
Вот это все интересует для основных архитектур, не только x86, x86-64, но и ARM, MIPS, IA-64 и т.д.
Я думал об этом. Все достаточно просто решается.
Во-первых, в файле проекта просто может быть указано что файл генерируемый — соответствующим атрибутом и даже можно указать номер прохода и прочую метаинформацию.
Во-вторых, в файле проекта не обязательно указывать конкретные файлы. Можно придумать указание папки с файлами — и тогда все файлы в указанной папке будут включаться в проект.
Вариантов много. Главное — чтобы был древовидный структурированный декларативный формат, а не скрипт. Скрипты — это частный случай кодогенерации и в особых случаях должны указываться отдельно. Наверное и в IDE такие файлы должны отображаться особым образом.
Я бы предпочел чтобы были не make и не bash-скрипты, а декларативный файл проекта, формат которого является частью стандарта языка программирования. Причем формат должен быть по возможности простым, прозрачным и человекочитаемым.
Почему? Потому что проект нужен не только для сборки, но и например для загрузки в среду разработки. Хорошо когда все эти функции совмещены в одном файле и не нужны никакие промежуточные генерации. Не говоря уже о такой странной вещи, как «конфигурирование» (cmake и прочие), которое само по себе является грандиозным костылем у языка с полным отсутствием модульности. Модульность — это ведь не только замена древних инклудов, но и интеграция модулей-библиотек в среду/окружение разработки.
make слишком низкоуровневый, слишком явно заточенный под сборку, и в нем слишком много от скриптов. А в идеале это должен быть просто список файлов исходников (возможно с какими-то атрибутами) и информация о проекте в целом. Формат vcxproj например немного ближе к идеалу, но он очень перегружен и в нем слишком много костылей и Microsoft-специфичных вещей.
Провод от наушников в качестве антенны непрокатит? Для дешевых FM-приемников, встроенных в телефоны, такое используется. Ну и дополнительная маскировка — это типа плеер такой:)
Просто у данного устройства клавиатуры как таковой нет и экранчик маловат. Т.е. в роли терминала использовать проблематично. А для проведения стандартных атак — ну я слабо представляю себе стандартные атаки по com-порту, обычно это действительно нечто очень специфическое типа отладочной инфы. Ну не телнет же в 21 веке ломать:)
С другой стороны, если бы было подобное устройство в форм-факторе ноутбука — то да, однозначно uart там был бы нужен. Но это уже было бы другое устройство и другая история:)
Я никогда не работал с Raspberry Pi, но по работе занимаюсь в том числе программированием для микроконтроллеров ARM (вот таких например) — так обычно там Ethernet встроенный. Все что нужно — это некая микросхема физического уровня, и порт наружу. Поэтому я и удивился, что хакерский девайс, а самого основного порта нет:)
Кстати, а Wi-Fi Direct (да и вообще Wi-Fi на современных смартфонах) позволяет держать связь сразу с несколькими устройствами? Для этой технологии было бы очень кстати.
Ладно бы еще была инфраструктура автоматического поиска сложноформализуемой информации — т.е. я даю нейросети подборку картинок и говорю «найди мне все похожие в инете», и оставляю компьютер на ночь — ну так ведь тут именно инфраструктура нужна. И картинки — самое примитивное (с чем современные нейросети вероятно справятся), а если нужны более сложные задачи — поиск и подборка текстовой информации на определенную тему?
Еще крайне привлекательно было бы использовать квантовую запутанность. Нет, не для сверхсветовой передачи — для обычной, но такой, чтобы вообще не нужен был посредник (фотоны и прочее). Т.е. «дальнодействие». Но с запутанностью все пока запутано — есть мнение что это просто «правый и левый ботинки» и никакая передача информации этим способом невозможна вообще. Хотя может быть, удастся сделать что-то с помощью слабых квантовых измерений
Еще есть гравитация. Пока совсем малоизученная, принимающих устройств всего несколько штук в мире, и все они длиной несколько километров. Способы компактификации пока вообще не просматриваются, хотя было бы заманчиво придумать метаматериал, собранный буквально из отдельных атомов… но тут практически 100% нет. Привычная нам материя слишком груба для этих целей.
Также, нужно понимать, что для истинно децентрализованной сети нужно чтобы пользователь согласился хранить как минимум терабайты данных, и предоставил свой канал доступа в интернет для целей сети. Информация в такой сети будет дублироваться даже не в тысячекратных объемах — в миллионнных или даже больше.
И предоставить пользователю «распоряжаться своей информацией» точно не получится — скорее наоборот, вместо предоставления информации в единоличное распоряжение корпорации (гуглу, фейсбуку и т.д.) пользователь предоставит ее миллионам других пользователей для распределенного хранения. Удалить что-либо из такой сети будет невозможно в принципе.
Лично меня это вполне устраивает — сеть это по определению публичное место, куда не стоит выкладывать что-то слишком персональное; а свойство информации копироваться — фундаментальное, и никакими законами это не ограничить. Но вот всех ли это устроит также как меня?
Так что это реально, тем более сейчас. Многие преподы вообще достаточно вольно относятся к тому, что они говорят на лекциях, и всякого рода отсебятину, а то и псевдонауку, регулярно вещают.
На самом деле я не против функциональных подходов, более того — те же лямбда-функции для меня были одной из самых ожидаемых фич С++. Функции как объекты первого класса это очень круто и удобно.
Но вот жертвовать производительностью и пересоздавать массивы каждый раз… ну не знаю, я на такое не готов.
Вместо usb сделать питание по nfc, правда очень не уверен в том, что его будет достаточно для обновления e-ink… но помечтать можно (в конце концов мощность nfc можно увеличить).
Ну и кстати, в рамках nfc вполне можно представить расширения mass storage class и virtual com port. Будут бесконтактные флэшки:)
UPD: не знаю чего вас минусуют, идея-то в целом неплохая, хотя конечно все аспекты не раскрыты.
Постепенно будут наращивать масштаб и серьезность, возможно через пару лет доберутся и до собственно полномасштабного отключения рунета.
Что-то типа шестнадцатеричного редактора, совмещенного с ассемблером/дизассемблером, работающим «на лету». Т.е. скажем окно разделено на две части, вводишь несколько hex-кодов в область слева — тут же получаешь дизассемблированный код справа, вводишь ассемблерный код — тут же налету он компилируется в hex-код.
Вот это все интересует для основных архитектур, не только x86, x86-64, но и ARM, MIPS, IA-64 и т.д.
А конструктор класса A с параметром типа int определен???
В общем, после первого же вопроса проходить тест желание отпало:)
Во-первых, в файле проекта просто может быть указано что файл генерируемый — соответствующим атрибутом и даже можно указать номер прохода и прочую метаинформацию.
Во-вторых, в файле проекта не обязательно указывать конкретные файлы. Можно придумать указание папки с файлами — и тогда все файлы в указанной папке будут включаться в проект.
Вариантов много. Главное — чтобы был древовидный структурированный декларативный формат, а не скрипт. Скрипты — это частный случай кодогенерации и в особых случаях должны указываться отдельно. Наверное и в IDE такие файлы должны отображаться особым образом.
Почему? Потому что проект нужен не только для сборки, но и например для загрузки в среду разработки. Хорошо когда все эти функции совмещены в одном файле и не нужны никакие промежуточные генерации. Не говоря уже о такой странной вещи, как «конфигурирование» (cmake и прочие), которое само по себе является грандиозным костылем у языка с полным отсутствием модульности. Модульность — это ведь не только замена древних инклудов, но и интеграция модулей-библиотек в среду/окружение разработки.
make слишком низкоуровневый, слишком явно заточенный под сборку, и в нем слишком много от скриптов. А в идеале это должен быть просто список файлов исходников (возможно с какими-то атрибутами) и информация о проекте в целом. Формат vcxproj например немного ближе к идеалу, но он очень перегружен и в нем слишком много костылей и Microsoft-специфичных вещей.
С другой стороны, если бы было подобное устройство в форм-факторе ноутбука — то да, однозначно uart там был бы нужен. Но это уже было бы другое устройство и другая история:)