Вопрос интересный. Я-бы спросил - какой смысл должно нести это время? Все простые варианты добавить к таблице счетчик времени - вызывают много вопросов. Начиная от того как быть с delete. И как быть MVCC. Можно просто рассмотреть парочку кейсов где 2 пользователя одновременно вставляют и удаляют строки и еще по разному коммитят и откатывают изменнеия и получается нехилое число парадоксов.
Аналогия с файловой системой - неуменстна. Файлы - работают в режиме dirty mode. Тоесть сразу фиксируют результат опреации. А таблица в БД в этом смысле похожа на git-репозитарий со множеством бранчей. Тоесть мультиверсионная вселенная. И подытожить ее состояние в любой момент времени так дешево не получиться.
Для нужд аудита изменений - самое простое создать поле last_update_timestamp в таблиах например. И туда добавлять время бизнес-операции.
Еще для аудита практически во всех dbms есть опции. Для Oracle например есть audit table.
Аудит обычно пишет имя пользователя и время действия и время таблицы над которой действие было.
Для MSSQL тоже есть свой API.
Мне кажется что даже Google не тестировал свою разработку на такие странные лимиты.
1 310 720 вкладок? Их невозможно увидеть глазами во первых. Да и что за пользователь будет такой фигнёй страдать. Техническая интуиция подсказывает что до того как мы достигнем миллиона - в системе сработают другие лимиты. На количество handles в Windows или какой-то счетчик или пул просто переполнится потому что сильно был не расчитан на такое извращенное использование.
Память в 128 здесь вобщем непричем. И если на закрытых вкладках java-машина паркуется то и активные страницы кода и данных можно сложить в swap.
Нет. Гит не является блокчейном потому-как в него не закладывались требования по кворуму и гарантий уникальности и нефальсифицируемости истории.
В git нет понятия блок. И нет алгоритмов POW для подтверждения потраченной работы.
В git владелец может убить master-бранч что само по себе - принципиально невозможно в криптовалютных проектах
UPD: Почему я привлекаю именно юзкейс криптовалют. Потому что в наше время блокчейн плотно ассоциирован именно с этой технологией. Хотя само по себе определение блокчейна может быть либеральнее чем я описал. Например POW может и не быть. Просто рассматривая git надо обозначить его сравнительные недостатки чтоб не было в теме попыток спекулировать просто на похожести этих двух технологий. Да они в чем-то похожи но блокчейн во много раз строже по безопасности. Ведь хранение журнала фин-операций - особая и деликатная задача.
Я-бы посмотрел на количество человек в команде разработки. И еще можно глянуть баг-трекер.
Если там дефекты висят по пол-года - то это тревожный сигнал о том что не стоит
с ним связываться. Ведь эти дефекты - будут у тебя.
Времена когда люди гонялись за операционками остались в 2000х. Особого смысла менять один
декстоп на другой нет. По возможностям они все примерно одинаковы. И если что и осталось выбирать
то это - надежность патчей и оперативность их выкатывания.
Недостатки Убунту описывал сам Столлман. По его мнению эта ОС слегка ... стучит на своих пользователей.
На современном языке - собирает телеметрию. В каком объеме собирает и как - никто не знает.
Никто такой вопрос кроме Столлмана видимо не поднимал. Но даже если так ... какие гарантии
что Минт не делает тоже самое?
При 700 наверное вообще любая БД подойдет.
Но тут надо еще отметить что архитектура БД выбирается исходя из наиболее типичных запросов.
Например для установления дружбы между людей в соц-сетях и для принятия маркетинговых решений
берут графовую БД. Для хранения сета вариативных документов - берут Mongo. Для финансовых транзакций
с историей - берут классические реляционные типа Oracle/PG.
Не нужно тебе брать таких заказов. Просто если ты задаешь такой вопрос - то ты находишся где-то на самом старте Web API. И сколько у тебя вопросов еще будет если ты вдруг возьмешь аванс и приступишь к работе?
Отвечая на вопрос - никто не знает. Надо читать информацию на самом сайте. Там обычно есть описание
этого API и обычно его использование стоит денег.
Доступ к истории проекта закрывать нельзя. Это противоречит идеологии версионного контроля. В старых версиях кроме sensitive info могут быть знания по предметной области. Нам в разработке с одним банком очень помог анализ истории. По крайней мере мы поняли некоторые причины дефектов мультипоточки.
То что пароли и токены коммитились - это epic fail, но лучше их обновить чем поступать как тупо. Вы-же не хотите походить на пришельцев-бюрократов расы "вогонов" (из романа Дугласа Адамса) которые уничтожили планету Земля только потому что им надо было шоссе построить в космосе.
Для современной разработки уже нет смысла держать две оси.
Если на Windows нужна bash-консоль и линукс окружение - то можно поставить WSL2.
Если нужны Linux-специфичные службы и приложения в сети - то их можно поднять через Docker.
Если тебе нужен хайлоад на локальной машине как мне - то просто сразу ставь себе Линукс как основную
ОС. Это радикально и решительно. К чему эта каша-размазня?
Первое - это объем сетевого трафика. Если в таблицу будет добавлено 4 поле например типа BLOB и туда
будут вставлять картинки - то при каждом select * ... картинка будет транслироваться по сети даже если
она вам не нужна.
И второе - просто неожиданно поведение софта, который ожидает поля именно в этом порядке id, name, balance
если кто-то захочет поменять тип данных name например - то он сделает drop column name, а потом
создаст новое поле alter table add column .... то в таблице они лягут в заголовок уже в новом порядке id, balance, name
Какие будут последствия - чорт его знает но ничего хорошего для автоматизированных систем ждать
не стоит.
2) Генерировать XLS со сложной структурой. Тут не знаю. Насколько сложной? Что там? Вся база знаний о планете Земля со времен Шумеров? Ну для работы с XLS есть библитечка apache poi
Ну сигнатурки - это-же только часть вирусов.
Как быть с новыми заражениями на которых еще нет сигнатур?
По хорошему нужно очень глубоко анализировать контент бинарных выполнимых файлов.
По поводу графики. Это - отдельная задача и я думаю что автору лучше сделать сначала просто консольный и работающий вариант а графику уже добавить потом.
Фактически когда мы говорим Linux - мы подразумеваем не саму ОС а ядро. Ядро физически лежит в каталоге
/boot
и это единая точка в системе где можно говорить именно о весии ядра. На все остальное - версия ядра не распространяется. Версии утилит и пакетов и приложений - могут быть любые. И может быть миллионы
их сочетаний вместе с ядром. Это кстати иногда отвечает на вопрос почему у некоторых пользователей
баг воспроизводится а у некоторых - нет.
