0x131315

Цель - усложнить разбор проекта в случае воровства, т.к. попытки уже были.

Если попытки были - потратьтесь на ionCube!
Окупится быстро!

Mint неплохой вариант: и выглядит хорошо во всех вариантах, и построен на ubuntu, соответственно имеет большую базу довольно свежих пакетов, и не требует лишних телодвижений по настройке графического окружения и.т.п. Это отличный вариант в стиле поставил, и пользуешься, при этом не плюёшься от внешнего вида. =)

По вашим вариантам:
Kali инструмент для вполне определённой работы. Это не дистрибутив общего назначения. Будет неудобно использовать для чего-то кроме основного назначения.

Debian потребует времени и знаний, чтобы получить удобное окружение, то же и с Arch, и даже в большей мере - он больше ориентирован на энтузиастов.

Fedora разумный вариант но может быть местами не стабильной, и OpenSuse будет на следующем месте за ней. Это, в целом, вполне неплохие дистрибутивы для использования на десктопе.

Ну и незаслуженно нет в списке Ubuntu, где, кстати, есть больше одного DE, и внешний вид можно легко менять и довольно кардинально, если уж на то пошло. =) Если нет по какой-то причине жёсткой завязки на rpm, то Ubuntu и её производные это лучший вариант.

OpenSuse - если очень хочется RPM, Debian Buster (т.е. текущий Testing, через полгода будет следующим стабильным) или Arch если умеете готовить.
Kali - это дистрибутив для полевых работ, в котором кроме спецсофта практически ничего и нет, но при этом на тот же Debian всё оттуда прекрасно ставится.
Fedora - это песочница для тестирования технологий, для любителей искать невзлетевший после апдейта софт.
Windows - Tassel 5 поддерживает, как и R Studio. Admixture можно попробовать запустить в WSL, равно как и то, что вы не указали.

работал с kali, в целом и внешне и функционально нравится но говорят что глупо иметь её как основную, так ли это, и почему?

Потому что дистриб специализированный для инженеров по сетевой безопасности.

2 года стоял ubuntu (biolinux, шустрый, но не понравился внешне)

дистриб не может "не понравится внешне". В любом дистрибе есть куча DE, экспериментируя с которыми можно получить тот вид, который хочется, тем более в бубунте. При выборе дистриба (а не DE) обычно другие критерии:
- Пакетный менеджер, то есть программа, которая обновляет пакеты, систему и т.д.
- Система инициализации - systemd, init и т.д.
- Модель обновления - пакетная или source-based

Да, нужно сделать отдельную таблицу многие-ко-многим, в которй будет user_id и post_id.

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

Да тут вариантов не много. Переменная, которая хранит тип лицензии должна называться licenseType.

Открыть документацию? Да не, бред какой-то.

А вообще не надо менять шило на мыло, используйте PDO.

Во-первых: начните изучать архитектурную часть программирования, изучите паттерны проектирования, изучите SOLID, DRY, KISS и остальные модные словечки, постарайтесь всё это осознать, или, на крайняк - зазубрить. Всё придет с опытом, изначально все не понимали зачем всё так сложно, но эта сложность обусловлена неисчислимыми литрами слёз и потраченных нервов, всё не просто так.

Судя по всему это тестовое или учебное задание. От вас требовалось отоверинжинирить простую задачу. Давайте попробуем:

Суть задачи - есть файл с определенной структурой хранения данных, структура строковая. Требуется этот файл преобразовать в другую структуру данных и вывести эту структуру в json формате. Задача ясна.

Разобъем задачу на отдельные независимые этапы:
1) Преобразование одной структуры данных (текстового файла) в другую (объект, понятный PHP, к примеру)
2) Преобразование этой структуры данных в Json формат.
Первый вопрос, который может возникнуть - почему сразу не преобразовать в json? Ответ - при расширении системы в будущем - нам понадобится вывести данные в виде массива, или в виде XML, или даже в виде готового файла Excel. Нам будет сложно дополнять логику изначального класса, ничего при этом не сломав и не затронув уже существующий функционал. Также ответом на этот вопрос может являться каждая буква из SOLID принципов, подробнее отвечу дальше, когда буду пояснять за реализацию, см. ниже

Теперь рассмотрим эту задачу с точки зрения ООП, начнем думать не от конкретной реализации, а от интерфейса и абстракции (мы не парсим конкретный файл, мы парсим просто файл, мы не переводим его в конкретное представление json, мы переводим его просто в представление):
Нам понадобится 2 класса - непосредственно класс, читающий файл и преобразующий его в простейший тип данных (например PHP array). Второй класс - преобразователь простейшего типа данных парсера в какой-то определенный тип:

1. LogFileReaded implements/extends FileReaderContract(интерфейс, возможно абстрактный класс, если понадобится предустановленная логика)
   
   Непосредственно наш преобразователь (не забываем, что передавать путь к файлу и все настройки нужно из вне, к примеру, в конструктор. Нельзя, как вы - хардкодить всё внутрь файла, на крайний случай - можно использовать конфигурацию), на ввод получает файл определенного типа с определенной известной структурой, на выходе выдает информацию из файла, преобразованную в базовый тип (массив, в нашем случае). Если нам когда-то понадобится парсить другой тип данных или структура данных будет изменена - мы сможем написать отдельный класс для этой логики, а не рушить целостность уже работающего кода, добавляя туда новую логику. Запомните - нужно стремиться не менять, а дополнять.
   
   
2. JsonPresenter implements/extends DataTypePresenterContract
   
   Абстракция содержит контракт на метод output(), а в конструкторе принимются исходные данные. В конкретной реализации JsonPresenter в output() будет банальный json_encode() (да, это нормально, нет, класс не лишний и нет, json_encode() нельзя пихать в сам парсер) А теперь к вопросу - почему не следует просто запихать это всё в парсер и вместо массива отдать json: в будущем, когда система будет расширяться - нам понадобится представить данные в виде XML - что тогда будем делать - переписывать весь код парсера ради добавления switch case "json" и т.д.? А если что-то сломается во всей системе? А если вариантов представления станет настолько много, что файл будет просто не читаем? А при данном подходе достаточно будет просто написать новый класс XMLPresenter, или даже ExcelPresenter, который на выводе не строку будет выдавать, а целый файл (опустим типизацию output пока)). Также этот класс можно реализовать в виде декоратора (паттерн), да и много еще как.
   
   

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

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

P.S. В данной реализации опускаются и упрощаются некоторые моменты для понятности

Я бы использовал оба способа одновременно:

• Указывать значение по умолчанию в сущности необходимо, т.к. сущность всегда должна быть валидна;
  
• Указывать значение по умолчанию для столбца тоже необходимо, т.к. бывают случаи когда приходится работать с "голым" SQL.
  

<?php

namespace App\Entity;

/**
 * @Entity
 */
class User
{
    const DEFAULT_ROLE = 'user';

    /**
     * @Column(type="string", options={"default": User::DEFAULT_ROLE})
     *
     * @var string
     */
    private $role = self::DEFAULT_ROLE;
}

description и text являются зарезервированными в мускуле.
если хотите их использовать как названия колонок, то используйте бэктик: `description` и `text`. ну и это кагбе общепринятое правило для избегания ошибок.