Вот интересный вопрос — а где простой «продвинутый юзер» может применить их в быту (и тем более в смартфоне)? Кроме распознавания капч, ничего в голову не приходит. Для самодельного машинного перевода все-таки знаний простого юзера будет недостаточно. А что еще?
Ладно бы еще была инфраструктура автоматического поиска сложноформализуемой информации — т.е. я даю нейросети подборку картинок и говорю «найди мне все похожие в инете», и оставляю компьютер на ночь — ну так ведь тут именно инфраструктура нужна. И картинки — самое примитивное (с чем современные нейросети вероятно справятся), а если нужны более сложные задачи — поиск и подборка текстовой информации на определенную тему?
Может быть, откроют новые физические принципы передачи информации. Как минимум, у нас есть нейтрино — пока их крайне сложно излучать (нужны ускорители) и еще сложнее принимать. Но кто знает, может удастся создать какой-нибудь метаматериал, с помощью которого удастся на порядки сократить размеры оборудования…
Еще крайне привлекательно было бы использовать квантовую запутанность. Нет, не для сверхсветовой передачи — для обычной, но такой, чтобы вообще не нужен был посредник (фотоны и прочее). Т.е. «дальнодействие». Но с запутанностью все пока запутано — есть мнение что это просто «правый и левый ботинки» и никакая передача информации этим способом невозможна вообще. Хотя может быть, удастся сделать что-то с помощью слабых квантовых измерений
Еще есть гравитация. Пока совсем малоизученная, принимающих устройств всего несколько штук в мире, и все они длиной несколько километров. Способы компактификации пока вообще не просматриваются, хотя было бы заманчиво придумать метаматериал, собранный буквально из отдельных атомов… но тут практически 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 встроенный. Все что нужно — это некая микросхема физического уровня, и порт наружу. Поэтому я и удивился, что хакерский девайс, а самого основного порта нет:)
Кстати, все это очень созвучно с одной моей статьей-фантазией Мечты о Хакерфоне (и Хакерпаде)
Писалась еще для Гиктаймс, я тогда решил помечтать об идеальном хакерском девайсе.
Ладно бы еще была инфраструктура автоматического поиска сложноформализуемой информации — т.е. я даю нейросети подборку картинок и говорю «найди мне все похожие в инете», и оставляю компьютер на ночь — ну так ведь тут именно инфраструктура нужна. И картинки — самое примитивное (с чем современные нейросети вероятно справятся), а если нужны более сложные задачи — поиск и подборка текстовой информации на определенную тему?
Еще крайне привлекательно было бы использовать квантовую запутанность. Нет, не для сверхсветовой передачи — для обычной, но такой, чтобы вообще не нужен был посредник (фотоны и прочее). Т.е. «дальнодействие». Но с запутанностью все пока запутано — есть мнение что это просто «правый и левый ботинки» и никакая передача информации этим способом невозможна вообще. Хотя может быть, удастся сделать что-то с помощью слабых квантовых измерений
Еще есть гравитация. Пока совсем малоизученная, принимающих устройств всего несколько штук в мире, и все они длиной несколько километров. Способы компактификации пока вообще не просматриваются, хотя было бы заманчиво придумать метаматериал, собранный буквально из отдельных атомов… но тут практически 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 там был бы нужен. Но это уже было бы другое устройство и другая история:)
Писалась еще для Гиктаймс, я тогда решил помечтать об идеальном хакерском девайсе.