Вам объяснить, что такое "однонаправленная синхронизация"?
Да если нетрудно, потому как я слабо представляю какое это имеет отношение к прямой передаче разнородных файлов.
Но если зайти немного дальше - я не вижу никакого смысла в синхронизации файлов как таковой. Зачем? Для чего вам иметь два одинаковых файла на разных компьютерах?
К бекапам это имеет очень слабое отношение если что.
Опять-же SyncThing и подобные тулзы, способные работать без сервера
Нет, не могут. Даже если обратное написано на сайте и в документации, даже если это работает лично у вас - в общем случае это не работает.
Ссылку на файл
Есть существенная разница между передачей деталей передаваемого файла каждый раз и настройки подключения один раз, не находите?
Но я честно говоря так и не понял ваших претензий: не попробовав наш проект в работе, вы сразу решили обвинить нас во всех смертных грехах и поучить жизни?
Или вы представитель компании, стоящей за разработкой SyncThing?
Вам точно нужно объяснять разницу между синхронизацией и просто передачей?
надо получить доступ к своим файлам откуда угодно и без стороннего софта
Раз за вас и вашу разработку, но это не та задача, которую решает наша Телепорта.
У нас нет задачи «получить доступ к своим файлам откуда угодно», у нас есть задача передать эти файлы, находясь в этом вашем «откуда угодно» на другой компьютер, который обычно находится в теплом офисе.
Потому что а) то что "давно есть и все привыкли" очень сильно сбоит и все хреновей работает б) времена меняются и требуют новых подходов - этого достаточно?
Видите ли, жареному мясу и лепешкам тоже «сто лет в обед» но стоило положить одно внутрь другого и получилась шаурма — очень известное блюдо. А кто‑то разрезал лепешку на две части и положил внутрь мясо в виде котлеты — появился бургер, тоже отдельное и очень известное блюдо.
Подходить к софту, который реализует известный пользовательский функционал с позиции «уже давно есть» все же неправильно, не находите?
Сделать такой софт даже имея бюджет вряд-ли получится, потому что пилили его многие и многие годы куча талантливых ребят, которые опирались на мнение своих покупателей.
Практически дословно:
1) "все есть и ничего не надо" 2) хочу "как Microsoft" только с перламутровыми пуговицами 3) "куда ты лезешь уже все поделено"
Ну да, вы типичный специалист, поздравляю.
Хорошая сторона заключается в том что у вас есть работа, связанная с вашей узкой нишей, плохая - решение о финансировании разработки принимаете не вы. Поэтому дискутировать с вами на тему "cделать такой софт даже имея бюджет" просто бессмысленно. Скорее всего как узкий специалист вы даже инструмент себе не выбирали, как это часто бывает например со звукооператорами или видеомонтажерами.
Забыл сразу добавить, что у отечественных специалистов, учившихся на ворованном фотошопе и 3DMax в головах очень большой разрыв между тем что они считают хорошим софтом, пониманием сколько стоит разработка и доступным бюджетом.
Поэтому все что можно продать типичному специалисту, работающему с платным но ворованным софтом на $2k за рабочей станцией на $5k это несчастный плагин за 50 баксов.
А на мощных одноплатниках и так, я думаю, обычный Ruby можно запустить. Получается очень нишевая вещь какая-то.
И да и нет. Мощные одноплатники имеют тенденцию перегреваться, что (помимо цены) несколько ограничивает их применение.
Хотя честно говоря тут сложно судить — реалии постоянно меняются, у меня на столе например стоит очень компактный NAS, внутри которого работает полноценный Linux а веб‑интерфейс крутится на полноценном Python.
Generally Ethernet is not built into microcontrollers. First you need a jack which can convert Ethernet signals into signals read by a microcontroller (this is generally called 'magnetics'). Then you need a TCP/IP stack, and then on top of that you need DHCP, DNS and whatever other protocols you want to use. So the actual microcontroller you use doesn't matter a whole lot. If you get something very powerful like an ARM with Linux running on it, then developing for it would be very simple, almost the same as writing a network application running on a desktop PC running Linux. Or you could go with something less powerful & cheaper like an AVR or PIC.
Но там же чуть ниже:
Lots of the TI Luminary microcontrollers (ARM Cortex-M3) have an onboard ethernet MAC. It needs an external crystal and ethernet PHY (connector + magnetics).
Стартовая модель включает 8 ГБ оперативной памяти и 64 ГБ внутренней памяти.
Так что думаю все несколько проще стало.
на бинарник веб-сервера
Дело в том что это не просто веб-сервер, а целый фреймворк: REST, JSON, авторизация и так далее и тому подобное.
Но главное тут в другом: встраиваемый MRuby дает отделение прикладной логики от системной части, т.е. можно реализовать отдачу html и обработку параметров на скриптах, которые при ошибке не уронят все приложение целиком, а системную часть оставить на Си.
Shortly after Borland ended the development of OWL, maintenance was taken over by a group of users led by Yura Bidus. This effort evolved into the OWLNext[1]open-source project currently hosted at the SourceForge site. OWLNext is a modern update and extension of OWL with support for the latest Windows versions and modern C++ compilers from Microsoft and Embarcadero.
Удивительные вещи творятся:
32-bit and 64-bit targets for Windows XP/Vista/7/8/10/11.
В который раз убеждаюсь что софт это в первую очередь идея, а идею хрен убьешь.
Поскольку так получилось, что в TCL/TK я тоже немногопонимаю, добавлю что:
1) Tk и Perl связаны очень долгой историей, поскольку Perl второй после Tcl язык где Tk всегда активно использовался. Для примера отрывок из статьи 2001го года:
An important advantage of using the pTk (Perl/Tk) combination is that you can write truly portable cross-platform GUI applications– applications that will work similarly across Win32, Macintosh, Linux, and even the AS/400!
2) Ставить из СPAN этот поддерживающий пакет — идея не очень если нужна портабельность. Надо ставить все же системный пакет (p5-Tk для FreeBSD), чтобы не было конфликта версий с Tk. Вся связка Perl + Tk + p5-Tk ввиду историчности и популярности присутствует в виде готовых пакетов наверное в любой ОС и дистрибутиве.
Поскольку я немного понимаю в старых системах, замечу что история с NexT и GNUstep — отличается. Отличается в первую очередь тем, что существенная часть кодовой базы и оригинальных концептов пробралась в настоящее без существенных изменений.
Xerox все же была исследовательской системой, купить и использовать которую дома или на работе обычному человеку было мало реально. А рабочие станции NeXT с самого начала были коммерческим продуктом, они продавались и использовались.
Самым известным фактом использования NeXT для разработки является создание Doom:
At the time of Doom's production, id Software was using a NeXTcube for its graphic engine development, so the NeXTSTEP version of Doom actually existed before the MS-DOS version and carries the name NeXTDoom. The application is sluggish on anything other than an Motorola 68040-based NeXTstation or NeXTcube (the more memory, the better), and has no sound support (DMX was not supported on NeXTSTEP). With OPENSTEP on the most recent i386 hardware, it runs smoothly under all conditions up to screen sizes of 400%. The released version is labeled v1.2, with programming credited to John Carmack, John Romero, and Dave Taylor.
Замечательный вопрос для человека с таким-то ником )
Постараюсь ответить максимально четко: чем меньше файлов с исходным кодом в проекте — тем меньше проблем. Для всех и вне зависимости от языка разработки.
Меньше рисков что-то потерять при коммите, меньше нерешаемых конфликтов при сведении изменений от нескольких разработчиков.
Сильно проще провести ревью коммита с парой файлов но сотней правок, нежели с сотней файлов но по паре правок в каждом.
Чем меньше исходных файлов — тем проще и быстрее идет сборка, поскольку на каждый исходный файл генерируется минимум один.class файл (для Java).
Проще даже среде разработки и поисковому индексатору, поскольку каждый отдельный файл с исходником необходимо мониторить на внешние изменения, что нагружает и диск и ОС.
Потому что до такого уровня безумия я еще не дошел, в современных браузерах есть встроенный парсер JSON, так что как минимум половина работы с форматом (клиентская часть) исчезает.
Вообще-то помимо инсталлятора создается еще и сам запускаемый рантайм (сюрприз) путем нарезания JRE, вот пример под мак (обратите внимание на каталог runtime).
~3мб достигается если выкинуть практически все модули, особенно модуль java.desktop (он самый большой).
Но скажу сразу, что для более-менее крупных приложений такое урезание невозможно, поскольку в модуль java.desktop запихана часть javax.el (Expression Language) и потому никакие Tomcat/Jetty на таком обрезанном рантайме не заработают.
Поэтому если вам действительно надо генерировать бинарник из настоящего Java-приложения, то стоит использовать GraalVM, который действительно его создает и честно падает с "page fault" при ошибках.
Да если нетрудно, потому как я слабо представляю какое это имеет отношение к прямой передаче разнородных файлов.
Но если зайти немного дальше - я не вижу никакого смысла в синхронизации файлов как таковой. Зачем? Для чего вам иметь два одинаковых файла на разных компьютерах?
К бекапам это имеет очень слабое отношение если что.
Нет, не могут. Даже если обратное написано на сайте и в документации, даже если это работает лично у вас - в общем случае это не работает.
Есть существенная разница между передачей деталей передаваемого файла каждый раз и настройки подключения один раз, не находите?
Но я честно говоря так и не понял ваших претензий: не попробовав наш проект в работе, вы сразу решили обвинить нас во всех смертных грехах и поучить жизни?
Или вы представитель компании, стоящей за разработкой SyncThing?
В чем смысл такого негатива?
Вам точно нужно объяснять разницу между синхронизацией и просто передачей?
Раз за вас и вашу разработку, но это не та задача, которую решает наша Телепорта.
У нас нет задачи «получить доступ к своим файлам откуда угодно», у нас есть задача передать эти файлы, находясь в этом вашем «откуда угодно» на другой компьютер, который обычно находится в теплом офисе.
Это совершенно другое действие.
Скажите а вы сами всем приведенным софтом пользуетесь? Или просто нашли в поисковике?
Потому что а) то что "давно есть и все привыкли" очень сильно сбоит и все хреновей работает б) времена меняются и требуют новых подходов - этого достаточно?
Видите ли, жареному мясу и лепешкам тоже «сто лет в обед» но стоило положить одно внутрь другого и получилась шаурма — очень известное блюдо. А кто‑то разрезал лепешку на две части и положил внутрь мясо в виде котлеты — появился бургер, тоже отдельное и очень известное блюдо.
Подходить к софту, который реализует известный пользовательский функционал с позиции «уже давно есть» все же неправильно, не находите?
Практически дословно:
1) "все есть и ничего не надо" 2) хочу "как Microsoft" только с перламутровыми пуговицами 3) "куда ты лезешь уже все поделено"
Ну да, вы типичный специалист, поздравляю.
Хорошая сторона заключается в том что у вас есть работа, связанная с вашей узкой нишей, плохая - решение о финансировании разработки принимаете не вы. Поэтому дискутировать с вами на тему "cделать такой софт даже имея бюджет" просто бессмысленно. Скорее всего как узкий специалист вы даже инструмент себе не выбирали, как это часто бывает например со звукооператорами или видеомонтажерами.
Забыл сразу добавить, что у отечественных специалистов, учившихся на ворованном фотошопе и 3DMax в головах очень большой разрыв между тем что они считают хорошим софтом, пониманием сколько стоит разработка и доступным бюджетом.
Поэтому все что можно продать типичному специалисту, работающему с платным но ворованным софтом на $2k за рабочей станцией на $5k это несчастный плагин за 50 баксов.
И да и нет. Мощные одноплатники имеют тенденцию перегреваться, что (помимо цены) несколько ограничивает их применение.
Хотя честно говоря тут сложно судить — реалии постоянно меняются, у меня на столе например стоит очень компактный NAS, внутри которого работает полноценный Linux а веб‑интерфейс крутится на полноценном Python.
По идее да:
Но там же чуть ниже:
И как быть?
Вообще речь про embedded разработку, что на сегодняшний день либо arduno/pi либо промавтоматика со своими законами и АСУ.
По крайней мере так обстоят дела в тех проектах к которым я имел или имею отношение - если даже в самокаты сейчас arduno ставят, чтож теперь сделаешь.
Ну даже не знаю, из соседней статьи:
Так что думаю все несколько проще стало.
Дело в том что это не просто веб-сервер, а целый фреймворк: REST, JSON, авторизация и так далее и тому подобное.
Но главное тут в другом: встраиваемый MRuby дает отделение прикладной логики от системной части, т.е. можно реализовать отдачу html и обработку параметров на скриптах, которые при ошибке не уронят все приложение целиком, а системную часть оставить на Си.
Самое крутое что я смог реализовать на перле это вот, врядли получится выше прыгнуть - все же очень старая технология.
Терзают смутные сомнения, что поддержки Wayland все же ожидать не стоит )
Когда там релиз 10й версии? Чего-то затягивать начали с новыми выпусками, из года в год все длиннее релизный цикл.
Что характерно не похоронили до сих пор:
Удивительные вещи творятся:
В который раз убеждаюсь что софт это в первую очередь идея, а идею хрен убьешь.
Поскольку так получилось, что в TCL/TK я тоже немного понимаю, добавлю что:
1) Tk и Perl связаны очень долгой историей, поскольку Perl второй после Tcl язык где Tk всегда активно использовался. Для примера отрывок из статьи 2001го года:
2) Ставить из СPAN этот поддерживающий пакет — идея не очень если нужна портабельность. Надо ставить все же системный пакет (p5-Tk для FreeBSD), чтобы не было конфликта версий с Tk. Вся связка Perl + Tk + p5-Tk ввиду историчности и популярности присутствует в виде готовых пакетов наверное в любой ОС и дистрибутиве.
Да, .Xresources до сих пор используется в современном Xorg а xsetroot все также позволяет установить обои.
Поскольку я немного понимаю в старых системах, замечу что история с NexT и GNUstep — отличается. Отличается в первую очередь тем, что существенная часть кодовой базы и оригинальных концептов пробралась в настоящее без существенных изменений.
Xerox все же была исследовательской системой, купить и использовать которую дома или на работе обычному человеку было мало реально. А рабочие станции NeXT с самого начала были коммерческим продуктом, они продавались и использовались.
Самым известным фактом использования NeXT для разработки является создание Doom:
Замечательный вопрос для человека с таким-то ником )
Постараюсь ответить максимально четко: чем меньше файлов с исходным кодом в проекте — тем меньше проблем. Для всех и вне зависимости от языка разработки.
Меньше рисков что-то потерять при коммите, меньше нерешаемых конфликтов при сведении изменений от нескольких разработчиков.
Сильно проще провести ревью коммита с парой файлов но сотней правок, нежели с сотней файлов но по паре правок в каждом.
Чем меньше исходных файлов — тем проще и быстрее идет сборка, поскольку на каждый исходный файл генерируется минимум один.class файл (для Java).
Проще даже среде разработки и поисковому индексатору, поскольку каждый отдельный файл с исходником необходимо мониторить на внешние изменения, что нагружает и диск и ОС.
Потому что
до такого уровня безумия я еще не дошел, в современных браузерах есть встроенный парсер JSON, так что как минимум половина работы с форматом (клиентская часть) исчезает.Да понятно давно что я ничего не знаю и понимаю, не утруждайте себя моей повторной оценкой, а то еще надорветесь.
Но думаю вам ваших лет опыта все же хватит, чтобы посмотреть на вещи чуть дальше терминов.
Вообще-то помимо инсталлятора создается еще и сам запускаемый рантайм (сюрприз) путем нарезания JRE, вот пример под мак (обратите внимание на каталог runtime).
За создание этого рантайма отвечает другая утилита jlink, которую jpackage вызывает при работе.
~3мб достигается если выкинуть практически все модули, особенно модуль
java.desktop (он самый большой).Но скажу сразу, что для более-менее крупных приложений такое урезание невозможно, поскольку в модуль java.desktop запихана часть javax.el (Expression Language) и потому никакие Tomcat/Jetty на таком обрезанном рантайме не заработают.
Поэтому если вам действительно надо генерировать бинарник из настоящего Java-приложения, то стоит использовать GraalVM, который действительно его создает и честно падает с "page fault" при ошибках.