<< предыдущие (до 2019-01-19_02-37-53) | следующие (c 2024-09-21_14-05-22) >> на этом всё пока |
2018/11/20 - Wanted! (счетчик: 8)
Но пока попробую имеющееся запустить :). У меня пара телевизоров сейчас на столе, а спекки как раз под ТВ развёртку заточен.
2021/04/06 - Где MTA, там и MDA.. (счетчик: 20)
Еще есть ciderwebmail
А если нет аллергии на php как у меня, то roundcube.
Mailpile - на питоне, но вот он у меня не взлетел, хотя выглядит любопытно. Выругался на несколько пакетов, которые не смог подтянуть. Доберутся руки - попробую разобраться.
Roundcube смотрел несколько лет назад, но что-то тогда не срослось с ним, выбрал squirrelmail вместо в тот раз.
2021/04/30 - Хорошо, когда мир информационно связен. (счетчик: 7)
Многие почему-то неодооцеинвают того, что невозможность зайти и произвести необходимые операции часто не менее серьезная угроза, чем возможность что кто-то войдет и выполнит несанкционированные.
В любом случае 2FA без резервного способа авторизации — зло.
2021/06/15 - Пщ! (счетчик: 0)
А у меня тут проблема - надо включать в состав продукта софт, написанный на этом языке.
Нормально запакетировать все требуемые библиотеки - нельзя. Приходится по ходу сборки из интернета тащить.
Использовать компилятор который в составе дистрибутива - нельзя, эта версия языка уже не поддерживается сообществом (знаем мы что там за сообщество на букву G). Ну и на "Эльбрус" не портировано.
А вот на чём написать софт, который будет уметь:
общаться по сети (клиент-сервер, TCP/UDP),
общаться по последовательным портам (RS разнообразные),
общаться с БД (sqlite, mysql, MS SQL DE, PostgreSQL)
записывать/воспроизводить звук через звуковухи компа,
компилировался в исполняемый бинарник без зависимостей...
в идеале - кроссплатформенный...
Можешь посоветовать?
Это я всё про умный дом думаю. :)
Не нужно это программе-домохозяйке. это программе-шлюхе нужно, которая ходит по рукам, в смысле по компам.
Вообще, программу, которая общается по сети и работает со звуковыми и последовательными устройствами, можно писать на чем угодно, так как все необходиммые для этого средства встроены в ядро операционной системы, и в языке нужен только доступ к системным вызовам read и write. (ну там еще по мелочи open, ioctl, socket,bind).
Но наличие условия "компилируемость" свидетелствует о том, что имеется некорректно поставленная задача. Возможно, на самом деле нужно "чтобы оно раотало на слабеньких микроконтроллерах" А значит мы упираемся в переносимость и новомодные языки пролетают со свистом.
А вообще я б эту задачу на питоне решал. Потому что компилируемость - это недостаток. Иногда простительный (если процессорной мощности не хватает). Но на таких языкак как perl и python всегда можно спрятать критичные по производительности куски в компилируемые модули. а основную логику. где торопиться некуда писать на удобном языке.
То же самое с внешними зависимостями - нахрена бояться внешних зависимотей, если тебе программу надо использовать, а не продавать?
Если продавть, и надо ее выпускать под 30 операционных систем. у каждой из которых своя политика по части зависимостей, тогда понятно почему хочется единого бинарника. И то наша практика показывает, что делать переносимые распространяемые приложения на питоне можно. И зачастую это менее трудоемко, чем то же самое в виде компилируемых бинарников.
Но если это грубо говоря мозги твоего дома, то гибкость, которую обеспечит конструктор лего из готовых компонент, связанных скриптовым клеем дает больше преимуществ.
Но если уж очень хочется быть на острие прогресса, то не Go, а Rust.
Потому и хочется бинарник, 1 шт. Скинул, написал конфиг, запустил и забыл. Да и бэкапить удобнее. :)
А кроссплатформенность - потому что мне под виндой комфортнее работать, а жить оно будет под линуксом. :)
Не то, чтоб хочется на острие быть... Но на дельфях кроссплатформенный сервис не сделать. :) Так что придётся что-либо новое осваивать. Потому и думаю, что оптимальнее под такую задачу.
Это я в Debian за четверть века привык доверять и пакетному менеджеру и мейнтейнерам пакетов дистрибутива.
И то если вижу софт, который тянет сотню-другую пакетов по зависимостям, стараюсь поискать альтернативу.
А что касается того, можно ли писать кроссплатформные проекты на Паскале - да, можно. Существует Free Pascal, который, конечно не совсем дельфи, но большую часть дельфячего синтаксиса поддерживает. VCL там по-моему сильно неполноценная, но для умного дома ее и не надо.
Опять же, не обязательно учить что-нибудь новое, можно учить нифига не забытое старое. Например С без крестов.
Вообще на мой взгляд, в хорошем сложном проекте надо задействовать не меньше десятка языков разного уровня абстракции. Что-то на C, что-то может даже на ассемблере, что-то на более высокоуровневых компилируемых языках, что-то на скриптовых - perl,python, tcl, ruby, а то и php, если аллергии на него нет. Ну и shell с make, куда же без них.
У меня, как правило еще awk и sed попадаются в качестве экстендеров шелла.
Но вот чего не стоит делать, так это тащить в умный дом что-то на базе интелоподобных процессоров. aarch64 - наше всё. Машинки класса PI с названиями разных ягод сейчас бывают от 5 до ста долларов в зависимости от потребной мощности уровень лоу-энд писюков перекрывают с запасом.
Угу, знаю про него, и даже что-то пробовал. Но вот чего нового иногда есть смысл осваивать, а то мозг костенеет.
>Опять же, не обязательно учить что-нибудь новое, можно учить нифига не забытое старое. Например С без крестов.
Про "чистый" C думал как раз. Так-то C-подобное и ассемблер я только на микроконтроллерах использую пока. Но вот вопрос, насколько удобно на чистом C работать с БД?
>Вообще на мой взгляд, в хорошем сложном проекте надо задействовать не меньше десятка языков разного уровня абстракции. Что-то на C, что-то может даже на ассемблере, что-то на более высокоуровневых компилируемых языках, что-то на скриптовых - perl,python, tcl, ruby, а то и php, если аллергии на него нет. Ну и shell с make, куда же без них
Вот сейчас стало страшновато. Я ж не настоящий программист. :)
>Машинки класса PI с названиями разных ягод сейчас бывают
Всё так. У них только один минус -- грузятся с MicroSD, в массе своей. Ну а дальше - уже вопрос архитектуры всей системы. Зачастую и они не нужны, всякие STM32 и ESP32 справляются с запасом, а иногда вообще безмозглые девайсы по жёстко прошитому алгоритму задачу решают (к примеру, включить свет по звуку, если темно, и погасить если тишина достаточно длится или светло стало).
У меня сейчас домашний сервер заодно заведует "умным домом" на базе Home Assistant, в дополнение к остальному. Пристроил, чтоб понять глобальное ТЗ для своего.
2021/06/29 - И снова на арене Фрэнк, который козёл. (счетчик: 0)
Но обработать исключение вовремя и навесить на него необходимую информацию - это выше сил индус-триальных программистов.
Особеннно смешно (вернее грустно) это выглядт в бразуере, где есть нас странице ошибки кнопоска "подробности". Вот думаешь, сейчас зайдешь, а тебе вывалят кучу технической информации - что сказад DNS-резолвер, с каким кодом завершился системный вызов connect, есть ли пинг до 8.8.8.8, а до дефолт гейтвея. Так нет же - ведет эта ссылка на страницу FAQ для чайников. Хотя собрать всю эту информацию из системы для браузера никаких проблем.
Или ошибка банкомата "вы, наверное, ввели неправильную сумму" когда ты сумму совсем не вводил, а выбрал из меню предопределенную. Нет бы честно сказать "деньги кончились". (а лучше еще - где кончились - на счету или в ящике этой железяки).
2021/06/30_1 - Фрэнк - козёл-подозревака (счетчик: 0)
2021/08/14 - О пользе современных технологий (счетчик: 0)
А какое для этого железо используется, что смотреть?
И насколько нормально для кино?
И на каком расстоянии от роутера работает?
Можешь сетап описать?
Заранее спасибо!
В ТВ -- штатная поддержка Miracast/Chromecast от производителя ТВ (в данном случае Sony, ТВ -- не на Android).
На источниках (планшете/ноуте) -- средствами ОС (Android/Win10 соответственно). Беспроводная проекция/подключение к беспроводному монитору.
Роутер -- лень смотреть, какая-то железка от ростелекома.
Расстояние ТВ/роутер -- всё в пределах одной комнаты.
Лаги иногда случаются, но переконнект лечит. В остальном норм.
2021/10/15_1 - "Пастернака не читал, но осуждаю" (счетчик: 0)
Первая вкладывает деньги в улучшение продаваемого продукта
Вторая - в его рекламу.
2021/10/28 - Домашне-серверное (счетчик: 0)
В постгресе при заливке больших объемов данных имеет смысл делать коммит примерно рад в 10000 записей. С одной стороны и WAL не пухнет, транзакции вменяемого размера получаются, с другой - не тратится время на коммит после каждой записи. А то он при коммите пытается добиться того, чтобы данные легли на диск пробившись через все кэши, А это медленно.
Речь о SimpleOPDS: http://www.sopds.ru/
2022/02/24 - @#$%^% (счетчик: 0)
Либо логин/пароль локальные.
Видимо, пора на федиверсовский движок переходить полностью. Но пока не готов.
2022/05/11 - Google — такой Google.. (счетчик: 0)
Ну и вообще все что только возможно на телефон я ставлю с FDroid, даже если оно там немножко хуже, чем аналоги на Google Play. Потому что зато надежно. Исключение только для приложений банков и яндекса, для которых не было пока альтератнивных каналов распространения кроме гугля.
2022/11/17 - Граждане сисадмины, сами мы не местныя... Хелп, плз? (счетчик: 0)
Если точно сама, то тут уже на нее глядеть надо.
Если веб-сервис, то первое подозрение: при подключении програмки по АПИ он прописывает для нее правила "откуда принимать, куда посылать". И если эти таблицы сбросились на какой-то предыдущий дефаулт, то.
2024/05/15 - :) lytdybr (счетчик: 0)
Выглядит инструмент довольно надёжным, надо сказать.
2024/09/20 - Мельница деревни Завал (счетчик: 0)
<< предыдущие (до 2019-01-19_02-37-53) | следующие (c 2024-09-21_14-05-22) >> на этом всё пока |