Log под Ubuntu

[RX1AL]

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

Обеими руками и ногами голосую за!

Добавлено через 3 минуты

Коллеги, также хотел сказать, что я сейчас делаю лог для Ubuntu на Python/PyQT/SQLite.

Если еще возможно, было бы неплохо поменять базу данных с SQLite на Firebird. Под Ubuntu все есть,
а база пошустрее будет и возможностей поболее.

[UR3LCM]

Даже 10 - ка Линуса (на работе) и та далека от совершенства... И 2 ядра проца грузит в 2-3 раза больше, чем винда..... И на диске занимает будь здоров...... на слабом компе Р3 с 256 ОЗУ даже нет смысла ставить - тормоза будь здоров... И в чем преимущество? В бесплатности?

А у меня Celeron 667 MHz, RAM 128 Mb, GNU Linux kernel 2.6.30.5, дистрибутив Puppy 4.3.1. Гуляю по Інтернету, смотрю видео, слушаю музьіку... Часто одновременно : )
Причем отлично работает: fldigi, baudline, gpredict, Qtel, svxlink, Eagle, TLF, и еще немало радиолюбительского софта, требующего в том числе и real time. На диске занимает 200..300 Mb.
SDR приложения: LinRad, QUISK, SDR-shell+DttSP требуют несколько побольше ресурсов, запускаю на Celeron 1,7 GHz 256 Mb.
Wine практически не пользуюсь.

Вьі наверное вьібрали пункт "УСТАНОВИТЬ ВСЕ" десять DVD ; ) и запускать при загрузке все на свете службьі.

Линукса ДЕСЯТКИ не бьівает. Бьівает ЯДРО GNU Linux некоторой версии (на сегодня 2.6.xx) и ДИСТРИБУТИВ: Fedora, Mandriva, Ubuntu, Debian, AltLinux, ASP, SlackWare и еще пара сотен.

Преимущество Linux прежде всего в ОТКРЬІТОСТИ. Всегда можно сделать так как хочешь, под свои потребности. И конечно: защищенность, надежность, соответствие промьішленньім требованиям.

Добавлено через 14 минут

Коллеги, также хотел сказать, что я сейчас делаю лог для Ubuntu на Python/PyQT/SQLite.
У меня есть небольшая просьба, высказать ваши пожелания

Чем Вас не устраивает QLE. Или есть желание попробовать сильі в Python под QT ?

Из Linux логов пробовал log из Fldigi, QLE, TLF. У каждого есть свои преимущества. На сегодня мне вполне хватает Fldigi.
Как считаете, что же нужно в логе превередливому пользователю?

Добавлено через 12 минут

Если еще возможно, было бы неплохо поменять базу данных с SQLite на Firebird. Под Ubuntu все есть,
а база пошустрее будет и возможностей поболее.

ИМХО єто лишнее. SQLite ведь не СУБД, только библиотека функций для работьі с файлами содержащими БД. В результате все приложение получается "в одном флаконе". Firebird, также MySQL, IBM DB2, PostgreSQL являются полноценньіми СУБД и требуют отдельного администрирования, обслуживания. Если пользователь часто даже не в состоянии определить какие службьі нужно включить, какие вьіключить, то такая система для него будет только обузой.
Но если вьібирать архитектуру с СУБД, то тут наверное должен бьіть PostgreSQL. Остальньіе далеки от лицензии GNU GPL.
Да и по скорости он неплохо вьіглядит.

[RX1AL]

ИМХО это лишнее. SQLite ведь не СУБД ....

Не совсем согласен. В SQLite нет поддержки типа decimal, также отсутствуют хранимые процедуры,
UDF, полно-текстовый поиск по полям с индексацией. Все можно прикрутить, но это танцы с бубном.
Кроме того, если речь идет о базе, то использовать ее, как embedded (равно, как и файл базы) в режиме
эксклюзивного доступа нехорошо, так как нет возможности обращений со стороны других клиентов.
А такая возможность и функциональность удобна для работе в контесте, когда есть одна база и несколько
клиентов. Если конечно, данный лог будет писаться с поддержкой контестов... Но очень бы хотелось.

Поэтому, наверное, лучшим решением будет выбор базы, которая поддерживает клиент/сервер архитектуру. IMHO

[UR3LCM]

Не совсем согласен. В SQLite нет поддержки типа decimal,

Где в логе крайне требуется decimal ?

также отсутствуют хранимые процедуры,

По моему тут наоборот. SQLite єто СУБД встоенная в приложние. Следовательно, подготовленньій клиентской частью приложения запрос одновременно является процедурой для СУБД, и может использоваться многократно в т.ч. с различньіми параметрами.

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

СУБД ведь облегченная - Lite, для "десктопа". На нем даже аппаратного RAID массива нет, с гарячей заменой : )

А такая возможность и функциональность удобна для работе в контесте, ...
Поэтому, наверное, лучшим решением будет выбор базы, которая поддерживает клиент/сервер архитектуру. IMHO

O "MOMB Contest Team" и клиент/серверной архитектуре согласен,
но много ли таких пользователей ?

Относительно остальньіх .. Давайте посчитаем!
Определим размер одной записи в БД:
DATA TIME: 2 байта в формате unixtime, лучше 4 байта - для устанения переполнения в 2034 году;
CALLSIGN: 6 символов плюс дополнительньій префикс 4 и суффикс 4. Итого c с запасом: 16 байт;
FREQ/BAND: 4 байта, или 2 байта до 65535 КГц;
SND/RCD RST: по 2*3=6 байт, хотя можно обойтись и двумя;
MODE: 1 байт;
QSL status: 1 байт;
QTH, OPR NAME, INFO: вьіберем 80 байт.
ОБЩАЯ ДЛИНА ЗАПИСИ: 112 байт

Пусть радиолюбитель проводит ежедневно в течении года по 100 QSO.
Тогда размер БД за год будет: 112*100*365=4088000 байт или около 4 МБ/год
Стоит ли из-за 4Мб подьімать СУБД ? Тем более на "десктоп".

[RX1AL]

Где в логе крайне требуется decimal ?
....
O "MOMB Contest Team" и клиент/серверной архитектуре согласен,
но много ли таких пользователей ?

Относительно остальньіх .. Давайте посчитаем!
....
Стоит ли из-за 4Мб подьімать СУБД ? Тем более на "десктоп".

Использование типа decimal нужно для ввода частоты из DX кластера в трансивер через CAT, например.
По поводу хранимых процедур еще раз: запрос, подготовленный клиентским приложением не является
stored procedure базы данных. Это просто SQL statement или query, т.е. обычная команда клиента к базе,
включая и параметры. SQLite не поддерживает stored procedure, например, GetCallsignByCqZone(zone)
и т.д.

Кроме того, есть и минусы:
"the disadvantages of SQLite are,
- No right outer join. Workaround: use left outer join instead.
- Not much integrity checking. Workaround: be really careful in the application code.
- No decimal numbers. Workaround: lots of aspirin." - цитата с официального рефлектора.

Добавим все же поля в базовую табличку для QSO. Сорри, я буду в типах сиквела писать:
Id - int (unique primary key auto increment) (4 Bytes)
DateTime - datetime (8 bytes)
Callsign - nvarchar(16) (16 bytes)
Frequency - decimal (5 bytes при точности 1-9)
Band - char (4 bytes) или enumeration {160М, 80М, 40М и т.д. } по числу диапазонов с типом int (4 Bytes)
Mode - char(10) (10 bytes) или enumeration {CW, SSB, RTTY и т.д. } по числу мод с типом int (4 Bytes)
CQZone - int (4 Bytes)
ITUZone - int (4 Bytes)
RSTS - char(10) (10 bytes) - для записи номера и в контесте
RSTR - char(10) (10 bytes) - для записи номера и в контесте
WPX - nvarchar(4) (4 bytes) - префикс для учета по диплому
IOTA - char(6) (6 bytes)- для записи номера, например, EU-127
RDA - char(5) (5 bytes) - для записи номера
WFF - char(8) (8 bytes) - для записи номера, например, SPFF-123
QTH, Name, Notes - nvarchar(100) (100 bytes) - для записи QTH, Name, Notes - 80 bytes маловато будет
Manager - char(10) - для записи менеджера, или директа
QSLStatus - bit (1 byte) - для бумажных карточек
LoTWStatus - bit (1 byte) - для LoTW
EQSLStatus - bit (1 byte) - для eQSL

Вроде все для базовой таблицы. Считаем:
4+8+16+5+4+10+4+4+10+10+4+6+5+8+100+10+1+1+1 = 211 bytes.
И вы брали случай для работы только радиолюбителя (среднего). Теперь возьмем любую DX-педишн
по IOTA, DX или выезд по RDA, WFF - в день будет по 1000 QSO минимум. Для контестов аналогично,
если не больше. Поэтому ваш расчет немного не верен по размеру базы. Также не стоит забывать про
размер базы по умолчанию - он тоже есть, если не просто пишем все в файл (но это маразм).
Добавим сюда же все справочные таблицы для DXCC, RDA, WFF, IOTA и т.д. Без них же никак,
хранить их надо. И набежит уже приличный объем, далеко не 4-8 мегабайт.
Поэтому лучше иметь полноценную СУБД, чем мучиться с поделками и иметь с ними проблемы. IMHO стоит подымать.

[RW4PAN]

Установил я этот Fldigi....и как туда базу от UR5EQF загнать....не хочется терять.
Спасибо.73!

[RD3AMP]

Установил я этот Fldigi....и как туда базу от UR5EQF загнать....не хочется терять.

Логи в fldigi хранятся в обыкновенном формате ADIF в папке logs.
Можно конвертировать лог (логи) в ADIF и просто положить их в указанную папку.
Наверное слетят всякие произвольные аттрибуты - qsl отправлено/получено и тому подобные, но всё, что требуется для описания собственно qso сохранится.
На моем компьютере еще xlog установлен и fldigi дублирует записи в последний по времени изменения лог xlog.
Но это так, скорее для бэкапа и наглядности.
Хотя в xlog недостатков хватает, поскольку программа не обновляется год или уже больше. Например страны dxcc кривые, пришлось поправлять список после наших реформ - добавлял F и K после 2, чтобы Калининград определялся

[RX4HX]

Использование типа decimal

Потепаться языком можно...
Для будующих кто хочет начать свой лог писать:
у меня практически все свободное время сейчас на лог уходит. Да мне это нравится - тут не в деньгах дело...
Но! Если кто то думает что он в выходные пару часов уделит написанию лога... лучше не уделяйте! Все равно ничего хорошего не будет)))

[RX1AL]

Для будующих кто хочет начать свой лог писать:
.... Но! Если кто то думает что он в выходные пару часов уделит написанию лога... лучше не уделяйте! Все равно ничего хорошего не будет

Леша, в данном случае, согласен с тобой. Но, добавлю тоже. Если уж начинать
писать свой лог, то сначала на бумаге, где всю структуру описать, все функции,
а потом садиться и топтать клаву. Иначе будет куча ошибок, чего-то будет забыто,
где-то начнуться баги... и будет не до новых фич и опций, а время уйдет на баги
и их исправление. Кстати, без обид, у тебя ведь тоже так пока.

PS Не хватает тебе структурного программирования. И если б ты открыл свой код,
как предлагали, то твой лог бы уже был вылизан от многих ошибок. Но
хозяин - барин!

[UR3LCM]

Использование типа decimal нужно для ввода частоты из DX кластера в трансивер через CAT, ...

Частота в Гц прекрасно хранится до 4,2 ГГц в целочисленном типе INTEGER (MySQL) и занимает 4 байта. Или Вьі предполагаете извлекать из частотьі корни?

По поводу хранимых процедур еще раз: запрос, подготовленный клиентским приложением не является stored procedure базы данных. Это просто SQL statement или query, т.е. обычная команда клиента к базе, включая и параметры. SQLite не поддерживает stored procedure,
например, GetCallsignByCqZone(zone) и т.д.

Посмотрите вот єто:
SQLite Tutorial
Copyright (c) 2004 by Mike Chirico
mchirico(@)users.sourceforge.net
http ://souptonuts.sourceforge.net/readme_sqlite_tutorial.html
Обратите внимание на раздел
"Modifying the Source: Creating a Permanent Sign Function"
и раздел
"Creating a User-defined Sign Function: msign"
Ответьі налицо.

Относительно "... GetCallsignByCqZone(zone) и т.д.". Я бьі сделал так:
SELECT callsign,cqzone FROM log WHERE cqzone IN (3,7,15) GROUP BY callsign ORDER BY callsign ASC;
Думаю, что єто сработаєт ;-)

Кроме того, есть и минусы: "the disadvantages of SQLite are,
- No right outer join. Workaround: use left outer join instead.

Если не утруднит, приведите PSE реальньіий пример запроса с правосторонним обьединением к базе данньіх HAM-лога (не пример єтого типа запросов). Ну и предназначение использованньіх таблиц, конечно.

Добавим все же поля в базовую табличку для QSO. Сорри, я буду в типах сиквела писать:
Id - int (unique primary key auto increment) (4 Bytes)

Зачем нужен дополнительньій индекс, если индексирование по полям datetime, callsign, frequency обеспечивает уникальность записи и ускоряет доступ.

Frequency - decimal (5 bytes при точности 1-9)
Band - char (4 bytes) или enumeration {160М, 80М, 40М и т.д. } по числу диапазонов с типом int (4 Bytes)

Вьі ИМХО здесь преднамеренно раздуваете запись. Что єто еще за БАНДа :-) ?
Хранить частоту, некий диапазон и еще и применять хранимьіе процедкрьі СУБД, по моему єто уже слишком.

Mode - char(10) (10 bytes) или enumeration {CW, SSB, RTTY и т.д. } по числу мод с типом int (4 Bytes)

Єто сколько же "модов" развелось в HAM-radio. Имхо тут достаточно ОДНОГО байта типа ENUM('CW','SSB','FM', ..., 'USERDEF254', 'USERDEF255')

CQZone - int (4 Bytes)
ITUZone - int (4 Bytes)

Количество зон зарезервировано на случай присоединения к нам радиолюбителей с других галлактик? :-)) ИМХО достаточно TINYINT - один байт

RSTS - char(10) (10 bytes) - для записи номера и в контесте
RSTR - char(10) (10 bytes) - для записи номера и в контесте

По ДЕСЯТЬ байт на рапорт? Нет слов ... и сил продолжать далее.

... Считаем: 4+8+16+5+4+10+4+4+10+10+4+6+5+8+100+10+1+1+1 = 211 bytes.
... Теперь возьмем любую DX-педишн по IOTA, DX или выезд по RDA, WFF - в день будет по 1000 QSO минимум. Для контестов аналогично, если не больше. Поэтому ваш расчет немного не верен по размеру базы.

Ладно. Примем ваш "дутьій" размер записи.
Пусть DX-педишн молотит по 1000 QSO цельій отпуск, т.е 24 рабочих дня.
211*1000*24=5064000, т.е. всего около 5Мб данньіх.
Всего ПЯТЬ мегабайт за ЦЕЛЬІЙ отпуск!

[RX1AL]

Или Вьі предполагаете извлекать из частотьі корни? .... Ответьі налицо. .... Думаю, что єто сработаєт ;-)

Зачем нужен дополнительньій индекс, если индексирование по полям datetime, callsign, frequency обеспечивает уникальность записи и ускоряет доступ.
....

Коллега, без обид! Ну зачем же так извращаться с типом int, который максимально хранит 2,147,483,647?
По-вашему получается просто изврат, если надо сохранить 14.100,25 Мгц. Это же надо каждый раз использовать
конвертацию типа float (decimal) в int, вместо того, чтобы сразу использовать нужный тип.

По поводу user-defined function (UDF), о которой вы пишете. Скажите, пожалуйста, какую связь имеет UDF с
хранимой процедурой? Ответ: никакой. Так зачем приводить пример того, что неправильно? Поэтому ответы
не "налицо", а как раз - нет ответа. Относительно "я бы сделал так" - вы и пишете обычный SQL запрос, т.е.
statement/query, в данном случае select, и что вы хотите доказать? Хранимая процедура на языке
пишется с другим синтаксисом:
CREATE PROCEDURE procedure_name
@param data_type = default_value,
@param data_type = default_value,
@param data_type = default_value
AS
например:
CREATE PROCEDURE GetAddress
AS
SELECT * FROM Person.Address
GO
и компилируется затем.

По поводу уникального индекса. В данном случае индекс служит для того, чтобы обеспечить identity integrity в базе данных,
а не уникальность данных на основе индексированных полей. И как вы собираетесь биндить (data binding) данные на любой
визуальный контроль и реплицировать таблицу, если у нее нет уникального ключа или guid? Хотелось бы увидеть.

Насчет намеренного раздувания, нет, не раздуваю. Хранимые процедуры может и не нужны, но иметь возможность видеть
диапазон сразу, не делая поля для его вычисления (или за счет переменной в коде) - не так уж и плохо. Насчет достаточно
и одного байта для хранения мода - возможно, только тогда надо будет писать конвертор: байт в тип строки, и где-то
хранить все строковые константы. Вы такой путь предлагаете? Что ж, он имеет право на жизнь, но будет не удобен для
программиста. Насчет использования типа tinyint вместо int - не очень хорошая идея. Есть куча моментов, в реальных базах,
где лучше так не делать, так как траблы бывают.

Насчет вашего смеха RSTS в char(10). Запишите пожалуйста в вашей форме следующее: 5991564RV04 - в любом удобном
вам типе.

По поводу 5 мегабайт. Чтобы закончить спор, создайте пустую базу с таблицами в SQL 2005/2008, MySQL и т.д. и скажите
сколько она занимает. Уверен, что не 0 байт длины...

И коль так много советов по оптимизации базы и ее структуры, то создайте базу и напишите простую форму для лога.
Посмотрим на результат, а так пока не видно.

[UR5FCM]

Насчет вашего смеха RSTS в char(10). Запишите пожалуйста в вашей форме следующее: 5991564RV04 - в любом удобном
вам типе.

Миша а что номер будет вместе рапортом идти?
У меня рапорт РСТ+ два поля 599 1564 RV04 т.е.
RST - SRX - SRX_STRING как в АДИФ стандарте

Насчет частоты то она у меня в типе DOUBLE PRECISION или FLOAT
Поетому можно заменить Decimal в SQLite на DOUBLE PRECISION или FLoat

[RX1AL]

У меня рапорт РСТ+ два поля 599 1564 RV04 т.е.
RST - SRX - SRX_STRING как в АДИФ стандарте
....
Насчет частоты, то она у меня в типе DOUBLE PRECISION или FLOAT

Игорь, все можно заменить, если есть тип данных. Но в SQLite их набор весьма и весьма
ограничен: Null, Integer, Real, Text, Blob. Можно использовать Real, но там сразу 8 байт (!),
многие будут против.

Про реализацию типа Integer сказано, что сохраняется "1, 2, 3, 4, 6, or 8 bytes depending
on the magnitude of the value".

Дело не в том, в скольких полях хранить, а вопрос был, как сохранить все в типах данных SQLite.

И коллега забыл про использование Foreign Key. Не совсем
понятно, как он будет это реализовывать без Primary Key (который может быть Integer, а
может быть и составным - composite.

PS Кстати, в таблице для QSO забыто поле для страны по DXCC (Foreign Key) из справочника,
который в отдельной таблице (после импорта файла .CTY).

[R0JF]

+1

У меня есть небольшая просьба, высказать ваши пожелания по программе (что бы вам хотелось в ней видеть).

Спасибо!

Приветствую Ваше начинание!

Итак, что хотелось бы:

1. "Универсальность" (НЕпривязанность к -rpm -deb -gz форматам, например как у cqrlog - shell-овский скриптик, распаковывающий лог в ДОМАШНИЙ каталог, а не в системный, с автоматической установкой прав на файлы)
2. Хм... Ну, на счет хранения - даже затрудняюсь. В принципе и mysql можно, но и простой adif вполне бы подошел. Опять же "меньше лишних мегабайтов"
3. ОЧЕНЬ хочется "непривязанности" к версиям glibc (т.е. сборка со статическими либами). Пусть "потяжелее", но зато "безконфликтно"
4. Функциональность. Хочется поддержки нескольких логов (у меня например раздельные для /P, базовый и /QRP)
5. Интерфейс. В принципе, пойдет и самый простецкий типа xlog, но чтобы без необходимости на каждую связь тыкать мышей в диапазон-дата-время-мода-rstR-rstS... Т.е., чтобы умел подстаавлять дефолтные rst, сохранять последние диапазон-мода и самостоятельно считать время.
6. Отслеживание повторов.
7. Нормальный экспорт-импорт adif

Вроде пока всё. Имхо ничего ужасного и сложного.

73! Удачи. Охотно буду бета-тестером. (Ubuntu 10.04LTS)

[RX4HX]

но и простой adif вполне бы подошел

Не подойдет. На счет того, что высказанно было выше на счет БД: все кто тут считает байтики забывает вот о чем: БЫСТРЫЙ ПОИСК! А для этого нужна не просто БД!

Добавлено через 57 секунд

И если б ты открыл свой код

А смысл? Неужели Вы думаете что кто то захотел бы мне помогать? Я Вас умоляю...