и чем этот "персональный сервер" принципиально отличается от имеющихся на рынке consumer NAS коих миллион?

удобством использования, поддержка всех OS, интерфейс везде одинаковый, масштабируемость, QubeOS как GCP (Google Cloud Platform) - свободно масштабируется, причём довольно просто, даже не-IT'шник справится, NAS нихера не масштарибуется ну и МНОГО много много различий которые на сайте хорошо описаны.. а так вот ещё есть детальное сравнение:

я вообще хочу софтину, которая хранит файлы и я не хочу думать о том, где и как она это делает, просто хочу чтоб 1) у меня всегда был к ним доступ; 2) данные и метаданные были защищены от несанкционированного доступа; 3) все это прозрачно монтировалось как файловая система и работало с приемлемой скоростью (какие-нибудь локальные кеши). даже придумывал архитектуру где данные делятся на чанки, криптуются и с избыточностью раскидываются по "бекэндам" в качестве которых может выступать все что угодно, от физических локальных дисков, через всякие гуглодрайвы, яндексдиски и телеграмы, до бесплатных файлопомоек уровня ргхоста, картинкохостингов и QR-кодов расклеенных на деревьях в лесу (доступ посредством коптера с камерой). за счет минимальных требований к бэкендам (они должны уметь просто хранить кусок данных и отдать его по какому-то идентификатору) можно использовать все что угодно, за счет избыточности - не страшно, если часть из этих говнохостингов умрет или коптер въебется в дерево.

я вообще хочу софтину, которая хранит файлы и я не хочу думать о том, где и как она это делает, просто хочу чтоб 1) у меня всегда был к ним доступ; 2) данные и метаданные были защищены от несанкционированного доступа; 3) все это прозрачно монтировалось как файловая система и работало с приемлемой скоростью (какие-нибудь локальные кеши). даже придумывал архитектуру где данные делятся на чанки, криптуются и с избыточностью раскидываются по "бекэндам" в качестве которых может выступать все что угодно, от физических локальных дисков, через всякие гуглодрайвы, яндексдиски и телеграмы, до бесплатных файлопомоек уровня ргхоста, картинкохостингов и QR-кодов расклеенных на деревьях в лесу (доступ посредством коптера с камерой). за счет минимальных требований к бэкендам (они должны уметь просто хранить кусок данных и отдать его по какому-то идентификатору) можно использовать все что угодно, за счет избыточности - не страшно, если часть из этих говнохостингов умрет или коптер въебется в дерево.

прибизительно к этому мы и стремимся, создать решение которое.. "ну просто работает")) но облака это опасно, и мы писали об этом на сайте

Ребят, можно вас спросить? Вы ж большинство крутые профи. Когда код дебажится в gogland, то получается так, что пути до файлов "ломаются". Так как в коде явно указано, что файл лежит тут же, в папке с исполняемым файлом. Если бы дебаггер gogland мог компилировать файл не во временной папке своей, а в той, откуда берет запускаемый файл для компиляции, то этой проблемы бы не было. Единственное решение, которое я вижу - менять все ути на полные. Сейчас при дебаге в gogland пытается найти рядом лежащие файлы во временной папке, куда компилируется во время дебага, собственно, тут: open /private/var/folders/vq/lhl73jyx2t3g83p63q4j9qhc0000gn/T/file.txt: no such file or directory[] Какой вариант решения проблемы есть? Кроме как перед тем, как кинуть в продакшен код, то в коде все пути поменять?

прибизительно к этому мы и стремимся, создать решение которое.. "ну просто работает")) но облака это опасно, и мы писали об этом на сайте

облака это опасно если держать все яйца в одной корзине и не криптовать. если одна из копий умрет - не страшно, есть другие. это можно задетектить и скопировать в другое место.

облака это опасно если держать все яйца в одной корзине и не криптовать. если одна из копий умрет - не страшно, есть другие. это можно задетектить и скопировать в другое место.

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

Ребят, можно вас спросить? Вы ж большинство крутые профи. Когда код дебажится в gogland, то получается так, что пути до файлов "ломаются". Так как в коде явно указано, что файл лежит тут же, в папке с исполняемым файлом. Если бы дебаггер gogland мог компилировать файл не во временной папке своей, а в той, откуда берет запускаемый файл для компиляции, то этой проблемы бы не было. Единственное решение, которое я вижу - менять все ути на полные. Сейчас при дебаге в gogland пытается найти рядом лежащие файлы во временной папке, куда компилируется во время дебага, собственно, тут: open /private/var/folders/vq/lhl73jyx2t3g83p63q4j9qhc0000gn/T/file.txt: no such file or directory[] Какой вариант решения проблемы есть? Кроме как перед тем, как кинуть в продакшен код, то в коде все пути поменять?

думаю большие вопросы лучше на форуме задавать

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

Не понял

Не понял

что именно?

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

моя идея в том, чтоб на основе кучи ненадежных хранилищ сделать одно надежное. что такое "свое облако" я вообще не очень понимаю. вот у меня есть файлопомойка где я музыку храню и монтирую ее по WebDAV и NFS - это свое облако или нет?

моя идея в том, чтоб на основе кучи ненадежных хранилищ сделать одно надежное. что такое "свое облако" я вообще не очень понимаю. вот у меня есть файлопомойка где я музыку храню и монтирую ее по WebDAV и NFS - это свое облако или нет?

смотря каким языком говорить, если чисто техническим то конечно-же нет, не облако, ибо облако подразумевает distributed network если говорить языком маркетинга, то, если NAS по интернету доступен, то да, "своё облако"

дело в том, что Dropbox или какой-нить Google Drive это чужая вещь, мы их никак не контролируем, сегодня условия одни, завтра другие, а файлы уже там.. если ломанут, то ломанут всех сразу. Шифровать файлы постоянно туда сюда - гемор, ни один обычный пользователь этим заниматься не хочет. думаю я довольно хорошо описал облака в документах которые скинул выше.. когда мне нужно именно СВОЁ облако, которое подчиняется именно мне... вот тут пока нет достойной альтернативы, поэтому мы над этим и работаем

можно просто взять пару виртуалок на AWS и установить на них QubeOS, и уаля, облако которое работает только на тебя, полностью зашифрованное, с поддержкой и интерфейсом на всех системах Windows, Linux, IOS, Mac, Android

а те кто не шарит просто коробочку купит и дома поставит

А owncloud???

а те кто не шарит просто коробочку купит и дома поставит

те, кто не шарит, как раз будет продолжать дропбоксом пользоваться. еще и заплатят за терабайт

что именно?

Прости. Перечитал и понял

На самом деле обычному пользователю надо просто обновлять ос во время. Для бизнесов всяких актуально более менее. Но они как раз могут себе хранилище своё позволить

А owncloud???

говнище полное, простенький PHP скрипт поверх SQL, 1. расширяется ужасно тяжко, нужно самому каждую компоненту масштабировать (fs, database, load-balancing etc.) 2. mobile support?! приложение везде разное, разный функционал на разны платформах 3. это не OS, это хранилище, QubeOS же на подобе GCP (Google Cloud Platform) дай простому обывателю, среднестатистическому пользователю интернета OwnCloud - он нихера его не настроит самостоятельно.. про шифрование я вообще молчу косяков там на самом деле ещё больше, но я кратко описал главное

вот и мы, сейчас работаем над открытой Бетой, после неё намерены профинансироваться засчёт внешних инвестиций

Даже я с 10 годами админства + 10 годами юзерского общения с компом owncloud осилил с трудом и снес через неделю

Даже я с 10 годами админства + 10 годами юзерского общения с компом owncloud осилил с трудом и снес через неделю

а мы говорим о людях знания IT которых заканчиваются на установке Android проложений через Play Store.... но... вы не поверите.... даже они хотят безопасное, собственное хранилище))

А какой у вас интерфейс доступа?

А какой у вас интерфейс доступа?

не совсем понял вопрос, ты имеешь ввиду как пользователь интерагирует с OS? или ты про протоколы?

Ну вот да. Допустим я взял 10 виртуалок в амазоне и поставил кубеос. Как залить и слить архив хоумвидео?

Ну вот да. Допустим я взял 10 виртуалок в амазоне и поставил кубеос. Как залить и слить архив хоумвидео?

легче всего просто через приложение, ставишь клиент на Windows / Android / IOS / Linux / Mac и через GUI загружаешь))

А у него внутри что?

архитектура похожа на гугловский ChromeOS, но там Chrome в качестве клиента, а у нас это наш клиент))

не совсем понял вопрос, ты имеешь ввиду как пользователь интерагирует с OS? или ты про протоколы?

"деградирует"

В плане протокола до сервера

протокол между сервером и клиентом пропритарный на основе WSS (WebSocketSecure / TLS)

Прям проприетарный или просто свой собственный?

QubeOS - open source, в Community Edition всё бесплатно и открыто

свой собственный протокол (async RPC)

Ну телеграм клиент опенсорсный в плане клиентов при этом протокол проприетарный

нет, протокол совершенно открытый, просто свой

Заебись

дело в том, что Dropbox или какой-нить Google Drive это чужая вещь, мы их никак не контролируем, сегодня условия одни, завтра другие, а файлы уже там.. если ломанут, то ломанут всех сразу. Шифровать файлы постоянно туда сюда - гемор, ни один обычный пользователь этим заниматься не хочет. думаю я довольно хорошо описал облака в документах которые скинул выше.. когда мне нужно именно СВОЁ облако, которое подчиняется именно мне... вот тут пока нет достойной альтернативы, поэтому мы над этим и работаем

> Шифровать файлы постоянно туда сюда - гемор, ни один обычный пользователь этим заниматься не хочет. согласен, но пользователь и не должен этим заниматься, конечно. ничто не мешает это делать прозрачно, пользователю достаточно знать что его данные в открытом виде видит только он, криптуются они вот этим ключом, и если его проебать - концы. сделать так чтоб ключ было сложно проебать - интересная проблема, но мне неинтересно ее решение, меня устроит если это будет просто файлик который можно положить на флешку/специализированный криптосторадж и замуровать в стену. level2 моей идеи - публичные, хм, каталоги (допустим, я хочу расшарить всем (либо какой-то группе людей) часть своей файлопомойки размазанной по всему интернету), и вот тут уже надо основательно думать над криптой.

> Шифровать файлы постоянно туда сюда - гемор, ни один обычный пользователь этим заниматься не хочет. согласен, но пользователь и не должен этим заниматься, конечно. ничто не мешает это делать прозрачно, пользователю достаточно знать что его данные в открытом виде видит только он, криптуются они вот этим ключом, и если его проебать - концы. сделать так чтоб ключ было сложно проебать - интересная проблема, но мне неинтересно ее решение, меня устроит если это будет просто файлик который можно положить на флешку/специализированный криптосторадж и замуровать в стену. level2 моей идеи - публичные, хм, каталоги (допустим, я хочу расшарить всем (либо какой-то группе людей) часть своей файлопомойки размазанной по всему интернету), и вот тут уже надо основательно думать над криптой.

наша файловая система в QubeOS именно под это и отточена, она позволяет делиться файлами но сама по себе она полностью зашифрована, досгитается это путём миксинга синхронного и асинхронного шифрования по типу TLS

наша файловая система в QubeOS именно под это и отточена, она позволяет делиться файлами но сама по себе она полностью зашифрована, досгитается это путём миксинга синхронного и асинхронного шифрования по типу TLS

вы кстати в курсе что qubeos совершенно отвратно гуглится, потому что есть гораздо более известная qubes os? :]

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

Качать уже можно? Интеграция с лдпом есть?

вы кстати в курсе что qubeos совершенно отвратно гуглится, потому что есть гораздо более известная qubes os? :]

да, мне говорят это буквально 2 раза в день)))) QubesOS.. QubeOS... скажу так: у нас ещё есть время на ребрендинг если мы посчитаем нужным его провести ?

Качать уже можно? Интеграция с лдпом есть?

качать будет можно открытыю бету которую мы собираемся вскором выпустить

конкретных дат сейчас стараюсь не давать, но для новостей можно в нашу пока ещё маленькую группу добавиться https://t.me/qbeon_chat

наша файловая система в QubeOS именно под это и отточена, она позволяет делиться файлами но сама по себе она полностью зашифрована, досгитается это путём миксинга синхронного и асинхронного шифрования по типу TLS

Все зашифровано, но можно делится файлами. А где ключи шифрования хранятся?

Все зашифровано, но можно делится файлами. А где ключи шифрования хранятся?

там-же, просто они асинхронно зашифрованы

файлы шифуются симметрично в AES, ключи шифруются асимметрично в ECC ECDH просто ловкость рук и накого мошенничества))

файлы шифуются симметрично в AES, ключи шифруются асимметрично в ECC ECDH просто ловкость рук и накого мошенничества))

наверное, симметрично, а не синхронно

наверное, симметрично, а не синхронно

да, скорее так правильнее, я просто из англоязычной среды, спасибо за поправку!

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

файлы шифуются симметрично в AES, ключи шифруются асимметрично в ECC ECDH просто ловкость рук и накого мошенничества))

Это понятно. Но я веду к тому, что когда шарим файлы, то постороннему человеку не нужно никакие пароли вводить и т. д.? То есть с одной стороны вроде и зашифровано, но с другой - все равно файлы доступны.

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

прослойки быть недолжно, поскольку это программная логика которая не спасёт от физического изьятия диска и ручного чтения. пользователи делятся файлами делясь в недрах файловой системы ключами ассиметрично, так-же как TLS осуществляет обмен ключей, приблизительно похоже на GPG/PGP

прослойки быть недолжно, поскольку это программная логика которая не спасёт от физического изьятия диска и ручного чтения. пользователи делятся файлами делясь в недрах файловой системы ключами ассиметрично, так-же как TLS осуществляет обмен ключей, приблизительно похоже на GPG/PGP

внутри системы все понятно. а как выложить в публичный доступ файл который лежит на диске в криптованном виде, чтоб человек кликнул ссылку и посмотрел фотку, не вводя никаких паролей?

Это понятно. Но я веду к тому, что когда шарим файлы, то постороннему человеку не нужно никакие пароли вводить и т. д.? То есть с одной стороны вроде и зашифровано, но с другой - все равно файлы доступны.

это кстати один из большущих недостатков традиционных NAS, они до сих пор делятся с помощью "shared folders", т.е. если зашифровать диск, то эта "поделенная папка" должна обладать паролем, который нужно вручную передавать и вводить думаю во времена Dropbox'a люди понимают насколько это устарело

от физического изъятия диска спасает даже банальный LUKS, это вообще не проблема.

ну и вообще, https://imgs.xkcd.com/comics/security.png

(поэтому хорошая криптосистема должна обладать deniability)

внутри системы все понятно. а как выложить в публичный доступ файл который лежит на диске в криптованном виде, чтоб человек кликнул ссылку и посмотрел фотку, не вводя никаких паролей?

либо создаёшь копию которая в принципе на диске не шифруется (зачем шифровать если и так публичная ссылка) либо создаёшь "публичного пользователя", который требует один раз ввести пароль учётки а потом просматривать публичный контент либо просто некий пароль в саму ссылку, таким образом только тот кто ссылкой обладает - открывает, но это какой-то бред если меня спросите

думаю вариант А) самый логичный, зачем шифровать если контент публичный?!

Лол

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

Коротче, нечего гадать. Лучше подождать релиз.

ERROR: S client not available

работаем)

Qubeos - An open-source shell for FreeDOS written in QBasic. P

Название очень печальное

да ладно, хуже pidora ничего нет

кхм. как-то сейчас двусмысленно прозвучало.

да ладно, хуже pidora ничего нет

Ахуенное название. Запоминается, легко гуглится.

вообще, может у меня гугл натренирован, конечно, но по первой ссылке реально дистриб для raspberry pi. всё как надо

я вообще хочу софтину, которая хранит файлы и я не хочу думать о том, где и как она это делает, просто хочу чтоб 1) у меня всегда был к ним доступ; 2) данные и метаданные были защищены от несанкционированного доступа; 3) все это прозрачно монтировалось как файловая система и работало с приемлемой скоростью (какие-нибудь локальные кеши). даже придумывал архитектуру где данные делятся на чанки, криптуются и с избыточностью раскидываются по "бекэндам" в качестве которых может выступать все что угодно, от физических локальных дисков, через всякие гуглодрайвы, яндексдиски и телеграмы, до бесплатных файлопомоек уровня ргхоста, картинкохостингов и QR-кодов расклеенных на деревьях в лесу (доступ посредством коптера с камерой). за счет минимальных требований к бэкендам (они должны уметь просто хранить кусок данных и отдать его по какому-то идентификатору) можно использовать все что угодно, за счет избыточности - не страшно, если часть из этих говнохостингов умрет или коптер въебется в дерево.

Читаю и понимаю, что пытался реализовать тоже самое. ? Подобная мысль видимо приходит очень многим. Странно, что она до сих пор не вылилась во что-то популярное.

Потому что там дохера ньюансов и проблем

Это да.

Я сомневаюсь, что такие мечты в принципе реализуемы

Что в духе сап теоремы

реализуемы. ибо в вебе консистентность мало где востребована. так что реализуют доступность.

Ну так во-первых речь не о вебе, а во-вторых я сказал не "из-за сап теоремы", а "что-то в духе сап теоремы"

Или треугольника цена-скорость-качество

да ладно, хуже pidora ничего нет

?

Вообще, да. Не очень понятно как реализовывать доступность огромного количества данных, когда произошло разделение сети , а ты остался вдвоём с одним каким-то сервером... Да и конситентность тоже не ясно как реализовывать, когда тысячи серверов и их состав постоянно меняется...

вот ссылочка в тему https://arxiv.org/pdf/1509.05393v2.pdf .

Блин, меня только одного воротит от JS?

Блин, меня только одного воротит от JS?

нет, всех нормальных людей тоже

Блин, меня только одного воротит от JS?

Если отмазаться TS, то норм же

Блин, меня только одного воротит от JS?

Не сможешь в Go без JS

не в Go, а в web

да и то только во frontend чаще всего

От го воротит больше чем от es6, что ж поделать ??

es6 няшный

просто танцору как говорится )

Ну вообще да, от ес6 не воротит

Внезапно