d-stream

Смотрим например https://docs.microsoft.com/ru-ru/dotnet/machine-le...
Скачиваем из описания taxi-fare-trans.csv, считаем число строк... сравниваем с количеством половины своих известных состоявшихся фактов (дабы вторую половинку скормить на тест)… думаем...

Тяжело гадать не видя кода. Не знаю умеет ли DB like и каков синтаксис.
Судя по беглому гуглингу - отличия от MSSQL в основном в экранировании спецсимволов и фокусы с кодировками.

Итак тесты:
1. убеждаемся что оба запроса показывают одинаковое число:

select count(*) from table 
select count(*) from table where str_field like '%'

2. убеждаемся что находятся строки с тестом, начинающемся на букву "А"
select * from table where str_field like 'A%'

3. убеждаемся что находятся строки с тестом, начинающемся на любую букву
select * from table where str_field like '[A-Z]%'

думаю дальше цепочка понятна?
hint выделен болдом

? подразумевает выражение "дать одно из двух" - дать, а не сделать.

То есть нормально это var xxx = (z

Ну если еще добавить отгрузки (реализации) и поступления ТМЦ - то собственно получается, что баланс - вычисляемое из сумм всех платежей/отгрузок. Ну иногда может потребоваться некий хелпер в виде готового значения чтобы каждый раз не суммировать.

p/s/ возможно вернее это будет звучать как "сальдо"

Я ИП

кстати стоит подумать об ОСН и возврате НДС с экспортируемых товаров. Но надо прикидывать - оправдают ли вернувшиеся 20% затраты на полный цикл затаможки и содержание ОСН структуры.
Плюс еще с 90 годов возврат НДС был неплохим бульоном для жульничества и возврат деньгами давно уже прикрыт.

ROWS | RANGE pg умеет?

Ну или накрайняк row_number в селекте, который ручками превращать в sub_page_number в рамках окна (для ситуации когда вест на 20 страниц ) по своему критерию n-m строк на страницу

В силу малозаконности такого действия (грубо произвольная выплата физлицу подразумевает так же уплату за него 13% НДФЛ и отчислений в ФОМС и ОПС, если явно не оговорены нюансы с каждым получателем) - придется достаточно часто искать еще не ликвидированные сервисы выплат... Ну или уходить в выплаты "не деньгами".

1. авито - позиция может быть ворованой, ненужной, нерентабельной, маловостребованной, бракованной = цена Боинга может оказаться $1 при любой иной рыночной...

2. износ - у более-менее крупных пользователей есть статистика износа и отказа современной электроники (в том числе бессвинцовые припои и т.п.)

3. Те самые TDP - один процессор, жрущий 10 или 30 Вт - безразлично, коридор в датацентре со стойками, в каждой из которых по 40 серверов и в каждом по 2-4-8 процессоров - это уже совершенно иные цены на электропотребление, охлаждение и стоимость резервирования мощностей.

Сеть управления != Сеть VIP (админов, которые видят все)

А так - похоже на феншуй.

Ну и пара моментов:
1. видеть из vip сети другие сети - это не только пакет от vip к юзерским, но и обратно... со всеми вытекающими...
2. при заметном трафике между сетями - маршрутизация на микротике будет тяжеловатой и более красивым вариантом будет применение L3(L2+) коммутаторов которые маршрутизируют пакеты между сетями со скоростью коммутации

Нужно ли мне будет платить налоги в России, если я не резидент РФ и у меня нет представительства в РФ?

То есть в России нет ничего. Даже если сильно захочется платить, то от кого? )
Если как амазон/али отправлять товары почтой - то получатели перебрав лимиты возможно будут платить таможенные пошлины, но это их бремя. Если же речь о нематериальных товарах - до тех пор пока не появится необходимость разместить резидентно в РФ представительство/филиал/etc - ничего платить не потребуется.

Вообще все что описано - это исходное и заложено в шрифтах и их отображении на конкретных устройствах. По крайней мере исходно шрифты именно так и задумывались. То что требуется вмешательство в виде таких "подпорок" означает что авторы шрифта - накосячили... и скорее всего подпорки для одного dpi дадут антиэффект при другом. Аналогично - при масштабировании.

ps более явно это уже испытано в бумажной полиграфии с давних времен.

Тут встает выбор:
1. Или на каждый этаж заводить управляемый коммутатор из дешевого сегмента (D-Link какой-нибудь на 16-24 портов), что не особо нравится в плане расширения, поэтому склоняюсь к второму варианту;
2. Разориться на парочку многопортовых стоечных коммутаторов и вести к каждой машине свой кабель.
На сколько нарыл в интернете можно взять два по 48 портов и объединить их.
Помимо пользовательских ПК, будут сетевые МФУ, возможно ещё камеры, ip-телефония и т.д.

Истина лежит где-то посередине. 1. Все коммутаторы должны быть управляемыми (про vlan уже написано), 2. "центр" и "доступ" - тут скорее по геометрии-протяженности смотреть надо - не факт что от коммутатора в серверной до какого-нибудь кабинета будет гарантировано меньше 90м кабеля...

Ну и в любом случае нормальный феншуй - "ядерные" коммутаторы желательны с повышенным интеллектом. Например умеющие ограничено маршрутизировать на скорости коммутации (так называемы L3 коммутаторы). Ну и быстрые. А уже юзерская часть - коммутаторы L2 попроще, подешевле и например 100мбит с гибабитными аплинками.

Хороший бесперебойник. Хотелось чтобы все оборудование выше он держал хотя бы минут 30-60. Т.к. выбор зависит от нагрузки и заложенного резерва (~30%),

В общем-то обычно бесперебойное питание на UPS ориентируется на 5-10-15 минут, а остальное время - резервные вводы, ДГУ и т.п.

Притом это не мода, а просто рациональность - ибо ДГУ + 10-минутный UPS - зачастую заметно дешевле 2-часового UPS.

Просто из личного, свежего: netplan писали какие-то грибные персонажи Пелевина... в общем присоединяюсь к толпам народа, кричащего "выкинь netplan")

Возможно уже действа по выкидыванию будет достаточно чтобы правила iptables заработали как и ожидается

Навскидку
1. zip-bomb https://ru.wikipedia.org/wiki/Zip-бомба
2. вариации автозапуска (в свое время были такие фичи в WinRAR)

Вообще народ топчется по граблям на более "стандартизированных" конфигурациях (антивирус грохает атоловские драйверы, атол взбрыкивает на magic number и т.п.) так что путь выбран не без трудностей)

Навскидку: в 10 ветке драйвера (а другие уже летят помирать) есть web сервер c которым можно более-менее легко и комфортно общаться (json-задания). Если на малинке получится его стартануть - будет полегче.
Вторая проблема - обратный канал: надо как-то в рамках умений ккм дать возможность ему докладывать ОФД (иначе через месяц ккм превратится в тыкву) - то бишь нужен ethernet-over-usb

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

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