igorzakhar

alex4answ, процедурный стиль использует только понятия модель памяти, типы, инструкции, программа и подпрограмма.

Вот и всё. Никаких составных типов. Концепция "состояние" в коде никак не выражается. Держите её если хотите в голове либо в комментариях.

Никаких сущностей в коде. Держите из в голове или в комментариях.

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

Но это всё уже вводится в структурном программировании.

Процедурное программирование вводит модель памяти с понятиями стек и куча. Хотите сделать функцию в процедурной парадигме - вам придется оформить её в виде подпрограммы и вызывать её из другой. Причем понятия линковки нет, вы будете делать это используя адрес в куче, а какие-то данные, типа, аргументы, будете сами на стэк ложить, каждый раз при вызове подпрограммы "функция".
Ах, да, захотите функцию для сложения двух чисел, придется сделать ctrl-c, ctrl-v и в теле подпрограммы написать сложение двух кусков данных взятых со стека. Для разности - копируете код, в теле меняете инструкции. И так для каждой функции.

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

Ну, и поскольку ОС не даст лезть за пределы одного процесса, подпрограмму придется положить в сорцы выше, чем ваш код.

А максимум абстрагирования, которое вводит процедурное программирование, это символьное произвольное именование адреса в памяти. Да и вместо типов, скорее, используется смещение байтов для коллекции, которым просто даны имена.

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

IDE может в качестве статического анализа помочь решать многие вопросы, но проще один раз сделать умный компилятор и перейти к языку, который позволяет абстрагировать. Поначалу было не совсем понятно, какой набор плюшек должен быть вшит в компилятор. Но стечением времени люди родили язык Си.

Ретроспективно, для процедурной парадигмы можно определить следующую область применения: любые математические задачи.

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

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

А вот в языке с полной поддержкой процедурной парадигмы можно делать такие подпрограммы, которые косплеят функции, но возвращают несколько "аргументов", причем пишут прямо в память. Да и в принципе, в процедурной парадигме можно делать свой ABI, нет никаких стандартов, нет правил, ничто не истинно и всё дозволено.

В целом, понимайте схемы как пространства имен. Схемы помогают логически организовать структуру БД. Различные приложения или компоненты приложений внутри себя имеют более высокую связность, чем между собой, тоже самое и с данными в БД - часто таблицы сами по себе организуются в логические группы, причем внутри группы связей довольно много (внешние ключи, какие-то общие хранимые процедуры и т.д.), а между этими группами - мало или нет вовсе.

Важно понимать, что различные БД плохо подходят для логического группирования, т.к. разбиение по базам данных нужно скорее для администраторов, а не для приложений. Плюс, в большинстве СУБД, где существует понятие схемы, возможно ставить внешние ключи на таблицы в другой схеме, но нельзя на таблицы в другой БД. Иными словами, отдельные БД удобно создавать тогда, когда вы разделяете данные абсолютно не связанных приложений или сервисов. Например, складского учета и форума поддержки пользователей. С другой стороны, если вы хотите логически разделить таблицы в соответствии с компонентами одного приложения (например, корпоративный портал: 4 таблицы для поддержки авторизации, 10 таблиц для поддержки форума, еще 5 для чата со службой поддержки или отделом продаж) - то именно схемы будут удобным механизмом для этого.

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

А что будет если несколько юзеров будут на одну public-схему коннектиться?

Помимо того, что схема - это пространство имен, в большинстве СУБД это еще и пространство безопасности. Даже в рамках одного многокомпонентного приложения имеет смысл ставить границы безопасности для ограничения возможных потерь и разрушений в случае компрометации одного из компонент.

Вот допустим, у вас есть отдельная схема для таблицы авторизации и аутентификации и отдельная - для корпоративного форума. Сервис авторизации у вас выполнен отдельно от форума (например, авторизация выдаёт токены пользователю, с которыми он потом может зайти на форум). С точки зрения безопаности было бы логичным выдать сервису авторизации и форума различных пользователей в базе - тогда, при взломе форума невозможно будет получить доступ к паролям в базе или изменить права на портале, подправив данные в таблице ролей. Конечно, многие СУБД разрешают ставить права на отдельные таблицы, однако схема в данном случае играет роль контейнера и позволяет проставить единые правила для всех таблиц внутри неё.

то есть при работе в постгре предпочтительнее вместо отдельных баз делать разные схемы в одной

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

Вот вам еще хороший пример. У вас есть приложение для ведения бухгалтерии и складского учёта на фирме. При этом сложилось так, что вам нужно хранить на одном сервере данные нескольких разных фирм (например, вы предоставляете готовый сервис под ключ нескольким клиентам). В этой ситуации более чем логично хранить данные разных клиентов в разных БД, а данные бухгалтерского и складского учета - в различных схемах в рамках одной БД конкретного клиента.

Где у Вас потери-то? tracert всего лишь показал, что какие-то узлы не отвечают на ping. Они могут прекрасно работать, и маршрутизировать трафик, но не отвечать на пинг.
Делайте pathping до yandex.ru, например, или другого более-менее быстрого узла.
Это всё во-первых.
Во-вторых - читайте договор. Или оферту на их сайте (если есть). Как правило, нигде ни один провайдер не указывает такие параметры, как процент потерь, гарантированную доставку, и гарантированную скорость. Указывают только максимальную скорость - ДО хххМбит/с. Т.е. скорость, например, МОЖЕТ быть 100 мбит, но это никто не гарантирует.
Тем более, Ваш конечный адрес принадлежит Valve Corporation, и начинается уже на 7 хопе.
https://bgp.he.net/ip/155.133.252.35
До 6 хопа всё это ТТК, и у них прямой пиринг с Valve, так что, по-идее, должно всё быстро работать, но, судя по пингу - сервер, к которому Вы подключались, далековато, скорее всего не в России.
Мало того, это могут быть перегруженные сервера, на которых работает игра (видимо, CSGO), или даже специально так настроено, чтобы сбалансировать задержки от разных игроков или снизить нагрузку или предотвратить возможные DDoS'ы. Предполагать можно что угодно. Хотите быстрее - переезжайте в другой город/страну, поближе к серверу, чтобы быть с ним (почти) в одной локалке. Вот тогда и пинг будет 1-3мс. Физику не обманешь, скорость света в оптике около 0,6 скорости света в вакууме, и на больших расстояниях эти задержки + задержки сетевого оборудования + задержки сервера и конечно, Вашего компа и маршрутизатора тоже - вот и получите 30-40мс.
Так что либо делайте нормальное тестирование, изучите на https://bgp.he.net/ к каким сетям и провайдерам относятся узлы в трассировке, и тогда уже делайте выводы - где проблема, а где её нет.
GLHF!

user@localhost:/sbin$ ls -l poweroff
lrwxrwxrwx 1 root root 14 Sep  5 18:01 poweroff -> /bin/systemctl

user@localhost:/sbin$ ls -l shutdown 
lrwxrwxrwx 1 root root 14 Sep  5 18:01 shutdown -> /bin/systemctl

Почти никакой разницы, обе команды - всего лишь симлинки на один и тот же файл. Но shutdown позволяет задать время, а в poweroff (согласно man'у) такой параметр не предусмотрен.

https://help.github.com/en/articles/removing-sensi...

Все просто.
1. Если канал без буфера, то при чтении из него программа заблокируется на этом месте, пока кто-то в другой горутине не запишет в этот канал значение. Соответственно, операция записи тоже заблокируется до тех пор, пока кто-то не захочет прочитать из канала.
2. Если канал с буфером и в буфере еще осталось место, то операция записи не заблокируется, а сразу вернет управление. Операция чтения тоже не заблокируется, если в буфере есть какие-то данные. Если же буфер полный, то запись будет вести себя так же как в п1. Если буфер пустой, то чтение будет вести себя так же как в п1.

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

Это /dev/null для маршрутизации. Пакеты, которые маршрутизируются в Null0 -- фактически, просто дропаются.

Такой подход используется в разных целях. Например, вам нужно заблочить мощный поток трафика на определённую подсеть, для которой вы -- транзит. Такой поток может быть, например, DDoS'ом. Блочить такое на файрволе -- может быть довольно дорогим удовольствием, с точки зрения используемых системных ресурсов. Поэтому сетку просто блэкхолят. В разных системах это по-разному называется -- в IOS это Null0 (и то, возможно, не во всех модификациях), во фре -- так и называется, blackhole.

Для NAT сам по себе этот интерфейс роли большой не играет, но его могут использовать. Например, у вас на устройстве нат для какой-то сетки. Сетка вам анонсируется по какому-нибудь протоколу динамической маршрутизации. Допустим, сессия динамической маршрутизации сломалась, и пользовательская сеть больше не доступна. Но на файрволе остались NAT-правила для неё. Соответственно, если придёт пакет снаружи для DST IP из клиентской сети (которая отвалилась), то шлюз посмотрит в таблице маршрутизации, не найдёт там specific-записей для этой сети и отправит пакет в default gateway. А на default gateway указано, что вот эта клиентская сеть доступна для него через ваш шлюз. И он опять отправит пакет на ваш шлюз. Ваш шлюз -- опять вернёт его в default gateway. И так будет до тех пор, пока TTL пакета не истечёт и пакет не будет прибит. Поэтому такие сети иногда блэкхолят. Если сессия динамической маршрутизации поднята, и клиентская сеть доступна -- пакет уйдёт туда. Если сессия упадёт, то пакет сразу будет заблэкхолен, т. е. прибит, и не будет крутиться по кольцу между вашим шлюзом и его default gateway'ем до истечения TTL.

Тут все просто, нужно разбить строку из 9 символов на 3 октета

1 = rwx
2 = r-x
3 = r--

Дальше заменить и просуммировать в каждом октете символы

r = 4
w = 2
x = 1
- = 0

на выходе будет 754

Для этого есть специальный модуль

import atexit

@atexit.register
def goodbye():
    print("You are now leaving the Python sector.")