Но зачем?

>>13409
Мне для учебы.
А вообще... Ну, во-первых, чтобы хранить большие объемы пикч так, чтобы никто не видел. Начиная от личных фоточек и заканчивая паками хентая - у многих анонов пека по факту не личный, а семейный. Во-вторых, быстрый поиск - найти что-то в папочках и подпапочках в фс это уже не два клика, а минут десять на большой коллекции. Тут же набрал три-четыре тега и все, весь поиск нужного занимает несколько секунд - найденное после выбора его падает в папку обмена и доступно для постинга куда угодно через браузер. В-третьих, цензура скоро закроет все буры (на том же гелбору уже местами вылетает табличка), и брать пикчи будет неоткуда, ну не впн же для этого покупать? К моей же софтине можно будет сбоку прикрутить i2p и шарить картинки в сеть.

>>13408

Охуенные у тебя названия коммитов.

что эти цифры значат

Криптография на чём реализована? Алгоритмы/шифры какие?

>>13414
Ничего. Тупо рандом. Потому что на начальном этапе туда писать нечего.
>>13418
AES128 на все. Впоследствии будет еще AES256 (на выбор) и RSA2048 для мастер-ключа. Все из стандартной поставки жавы, никакого колхоза.

>>13420
Надо учиться разбивать правки на атомарные коммиты и коммитить как можно чаще же.

>>13421
Слишком много аутизма. Пусть гитхабовцы автоматизируют это и чтобы оно само называлось и коммитилось, когда я жму Save в редакторе. Иначе это только тормозит работу.

>>13422
Ычую. И код пускай сами пишут.

>>13423
И для этого инструменты делаются, иначе бы до сих пор в машинных кодили.

Переходи на ИДЕЮ (https://www.jetbrains.com/idea/), нетбинс убог (c) ИМХО
А ещё у тебя Сишный стиль оформления кода, некритично конечно, но если пойдёшь устраиваться джава-кодером это плюсом не будет.

И ещё советую почитать вот этих умных дядек:

Мартин Р. Чистый код. Создание, анализ и рефакторинг (2010)
Д. Босуэлл, Т. Фаучер - Читаемый код или Программирование как искусство - 2012
Стив Макконелл - Совершенный код

java_кодер_мимо_крокодил ^_^

>>13425
>Сишный стиль оформления кода

обесни

t. не оп

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

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

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

>>13425
> Сишный стиль оформления кода
Но ведь стандартный для Java стиль и является вариантом сишного K&R.

Я давно хочу такую прогу, но пока ничего лучше Geeqie (что совсем не то) не нашёл. На джаве не пишу, но могу озвучить хотелки:

1) Чтоб держало в памяти изображения, имеющие 100-200-300-500 тэгов, которые я вводил для поиска чаще всего за последние 30 дней. Количество таких тэгов — пользовательскя настройка, естессно.
2) Поддержка archivemount. Нечего изобретать велосипед, да и мне например, шифрование не нужно совсем, а единый контейнер для картинок — очень. Залить 30 000 файлов на облако одним файлом гораздо быстрее, чем по отдельности.
Обычный tar, без сжатия. Со сжатием всё только тормозить будет, это ненужно.
3) Ящитаю, надо всё-таки поддерживать некую иерархию папок, чтобы пользователь мог внести новое изображение сразу в некий субкаталог (не важно, реальный или нет, но лучше и проще, наверное реальный), чтобы изображению автоматически присвоились теги от имён вышестоящих каталогов типа faces/_negative/disappoint/despair/ ← sensei.jpg.
Идея в том, чтобы даже без базы, если она вдруг грохнется/ты бросишь выпускать апдейты/джавасофт на моих новых часах будет тормозить, можно было пользоваться иерархией папок для навигации.
4) Развивая эту мысль и глядя на то, что у меня уже насортировано сейчас, я бы отталкивался от того, как пикчи вообще появляются на свет. В моём случае, их создаёт mpv и автоматически кладёт их в именованную папку со скринами типа /home/picts/screens/<show_name>
Я могу сказать ему, чтобы он искал папку screens как раз в каталоге, что был подмонтирован archivemount, и он будет создавать подпапки и класть в них скрины без моего участия, что здорово. И грех не воспользоваться этим, чтобы взять имя такой конечной папки и не сделать из неё тег, который потом присвоить всем лежащим внутри картинкам.
5) Проблема в том, что скринов куча, и что-то из них потом отправляется скажем, в /home/picts/faces/ (см. выше), при этом я бы хотел иметь картинку в обоих каталогах, но это привело бы к дупликации. Поэтому логичным выходом из этой ситуации было бы просто использовать симлинки.
6) Да и теги все пусть будут папками.
7) Навигировать по дереву каталогов в Geeqie не совсем удобно, но всё, чего там не хватает — это простого поля, который бы отсеивал папки по именам — сейчас там ожидается только абсолютный адрес каталога — http://i.imgur.com/ejAjiqI.png . Желательно ещё как-то ПРОЩЕ переходить между каталогами, колесом мыши например, потому что по безликим именам папок трудно найти картинку, которая понравится. Подбираешь то же лицо, например, в уме одно, а кликаешь рандомно и хочешь совсем другое, но ты его бы по имени не нашёл. Нужно как-то облегчить этот рандомный тык, а то ЛКМ ещё попасть надо;
8) Тамбнейлы разных размеров, при этом желательно использовать системный кеш и добавлять/обновлять создаваемые в него же.

…
9–∞) Чтоб как в Geeqie:
- лейаут (в целом) см. http://i.imgur.com/iAoOZKD.png ;
- чтобы между секциями окна можно было переходить по какому-то хоткею, который переключал бы фокус между ними по часовой стрелке;
- Pan View (календарь-мод);
- (отключаемая) плашка с инфой http://i.imgur.com/2EkLfEn.png ;
- поиск;
- чтобы имена под тамбнейлами можно было включать по необходимости (по умолчанию пусть бы не отображались);
- пусть при выделении картинки абсолютный путь до файла автоматически копируется в буфер обмена — чтобы можно было вставить средней кнопкой мыши в поле формы в браузере и прикрепить пикчу к посту;
- но нужен ещё элемент «'Filename' to clipboard» в меню ПКМ на тамбнейле или в окне большого превью, который копирует абсолютный путь к файлу в буфер обмена в одинарных кавычках, экранируя внутренние — для вставки в качестве аргумента командной строки, когда я даю его команде imgur (которая уже аплодит на imgur и копирует ссылку в буфер);
- ну или сделай так, чтоб можно было аплодить прямо из твоей программы и ссылка копировалась бы в буфер;
- настраиваемые хоткеи, чтобы можно задавать обыкновенные клавиши (WSADQERFZXV) на действия (пред., след., в начало, в конец, зум 1:1, вместить, приблизить, отдалить и т. д.) КЛАВИШИ ДОЛЖНЫ БЫТЬ ПРИВЯЗАНЫ К КЕЙКОДАМ, А НЕ КЕЙСИМАМ, ЧТОБЫ РАБОТАЛИ НА ЛЮБОЙ РАСКЛАДКЕ;
- открыть в редакторе на мой выбор нажатием одной клавиши, пусть я могу назначить любые клавиши, к примеру «G» на GIMP, «P» на фотошоп и «I» на Inkscape. Пусть вызов этих редакторов также будет в меню ПКМ (я часто обрезаю скриншоты, редактирую, иногда обвожу в векторе);
- сортировка по имени/дате снизу вверх и наоборот — при поиске скриншота среди сотен отснятых;
- поддержка GIF-анимации (только в окне превью, которое большое), а также webm, чтоб со звуком и vp9 (можно через mpv с указанным --x11-name, чтобы как-то его отличать), а то ни того, ни другого в Geeqie нет, а очень хочется;
Ну вот, вроде всё. Если ещё что вспомню — напишу.

> А буры?
Я по ним лазаю, но скачаиваю что-то крайне редко. Граблю что-то вообще раз в столетие. Потому что они на 99.99% pure shit. Так что сами разбирайтесь, что с ними делать и как.

>>13443
1. Будет, это уже запланированно.
2. Как раз доделываю. Шифрование встроено, но ключ лежит по-умолчанию в папке с архивом, и если его не убирать - то при запуске спрашивать ничего не будет.
3, 4, 5, 6. Уже есть, альбомы. Одна картинка может быть во многих альбомах. Но класть такое количество пикч в ФС не считаю разумным - после и бекап не сделать быстро, и встроенный в ОС поиск/индексатор давится, и с симлинками теряем кроссплатформенность. Основная цель софтины - это как раз огромная кроссплатформенная портабельная помойка для картинок, под теги падает все подряд, в альбомы уже ручками раскладываем что доставляет. То есть спарсил пак - раздал на торрентах - и любой может одним кликом открыть коллекцию, не теряя тегов, альбомов и прочей метаинформации.
7. Для этого есть теги.
8. Их надо хранить и делать, а это и диск, и процессорное время. На массовую загрузку ой как влияет. Скорее всего, выбор генерации разных превьюшшек будет в настройках - ибо мне лично хватает 128х128, кому надо больше, поставит флажки.
Я от системного кеша уйти стараюсь, а тут... Смысл в том, что при засорении папка кеша адово оттормаживает систему, и это самое засорение происходит при ~70к превьюшек там.
>>13444
Со многим согласен.
Гифы и webm запланированны, но на перспективу. Потому их не настолько много, чтобы они создавали какие-то трудности при обычном размещении в ФС.

Зачем, если есть полноценные криптографические файловые системы, а на прыщах им можно даже раздел не выделять, хранить как обычный файл?
> Будет то, другое, третье...
Комбайны не нужны. UNIX-way во все поля.

>>13459
Первая и главная цель этого - учеба, ибо делать примеры из книг слишком рутинно и печально. Потому частично велосипеды, да. Если полученный франкенштейен будет хоть кому-то полезен, вообще хорошо.
>если есть полноценные криптографические файловые системы
Их нет труЪ-кроссплатформенных, был трукрипт да сплыл. Форки же где под вендой не работают нормально, где под линуксами собирать с исходников надо, ну ты понел.

>>13454
Теперь главное не забыть про Автобус, к тому времени, как ты это допилишь.

>>13484
А там до релиза не так много времени уже. Архитектура проекта уже продумана, те или иные решения протестированы, часть выкинута, часть в процессе запиливания. Месяцок-другой, думаю, уйдет на полное допиливание.
Так что не забуду.

>>13492
Я вообще-то имел ввиду самому не забыть про Автобус, ибо я тут нечасто…

>>13408
Опчик, сколько ж лет я тебя ждал. У меня огромные кладезя манги и долгое время приходилось вести учёт вручную, вбивая названия, теги и прочую мету в экселевской таблице. Когда всё это надоело - попытался сделать программу, которая хоть немного автоматизировала бы процесс, но надолго забросил разработку и сейчас фиг вспомню что к чему. Собственно, изложу тогдашние хотелки и просто мысли здесь, чтобы тред не засорять: http://pastebin.com/ZTqtLbgW

Теги можно автоматически проставлять на основе анализа изображения.
http://demo.illustration2vec.net/

>>13531
Ага.

>>13530
За список спасибо.
А тем временем я отказался от хранения всего в одном блобе, ибо и со стороны пользователей, и со стороны разрабов идею закидали фекалиями, типа если ты забросишь проект, этот блоб ничем не открыть. Что же, пожалуй прислушаюсь. Теперь файл ключа шифруется rsa, ключи в стандартных форматах, сами файлы шифруются AES256 (с патчем), или AES128 (с дефолтной жавой), или шифрование можно выключить.
По пункту 0 - настроек будет много, но на перед релизом альфы. Для легкого изменения внешнего вида css и иконки будут лежать отдельно в папке, а не в ресурсах.
Пункт 1 - это уже CRM какой-то получается. На альфа-релиз планирую только альбомы и теги.
Пункт 3 - будет и то, и другое.
Пункт 5 - изначально задумал, но в альфе не будет, потому что надо подумывать, что стоит собирать из инфы, а что нет.
Пункт 4 - приделать несложно.
Пункт 10 - в альфе не будет. Далее в планах приделать webm и gif.

>>13532
А я ведь помню эту серию тома и жжерри.

>>13532
Кто это у тебя на картинке?

>>13537
Ну поищи сам, не вчера родился же https://google.com/search?q=smug%2Bmoeshit%2Bnekomimi&safe=off&tbm=isch

>>13408
Сделай тред в б Иичана, когда доделаешь.

>>13408
>>13656
Обязательно ни в коем случае.

>>13665
Очень жаль к счастью.

>>13408
Все уже давно придумано:

https://msdn.microsoft.com/ru-ru/library/ms179331(v=sql.120).aspx + varbinary.

http://www.sqlite.org/see/doc/trunk/www/readme.wiki + blob.

https://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html + blob.

И так далее.

>>13700
Щито это? Я шифрование, БД и прочие вещи не велосипедю, все стандартное и по-максимуму использую уже готовое. Даже от блобов кастомных отказался в пользу общепринятого способа хранения. Велосипеды там на уровне архитектуры больше.

>>13702
Что там как у тебя дела, ну расскажи же!

>>13780
Все потихоньку. Я не планирую быстро сделать релиз, поскольку изучаю на этом проекте технологии и фреймворки, отчего по десять раз рефакторю один и тот же модуль. Первая цель - разобраться в яве и всей экосистеме, вторая - сделать юзабельный безглючный релиз. Такой софт с глюками, костылями и изменениями в архитектуре БД никому не нужен. Зальет анон туда миллион пикч, а завтра обновление поломает БД, и анон больше использовать такой софт не будет.

>>13783
Если оно на яве, я не уверен, что анон его вообще качать будет. Или ты запакуешь всё в один экзешник с jre и не скажешь никому об этом?

>>13784
Зависит от анона. Я попользую. Но для меня главное - не шифрование. Для меня киллер-фичи такие:

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

Описания - текстовое сообщение произвольной длины у каждой картинки.
- полнотекстовый поиск по этим текстам.

API/java-библиотека для доступа к хранилищу
Пусть там указывается пароль, но получать картинки (как byte[] или InputStream) и метаинформацию через него (описания, теги, mime type).

Поддержка хранилищ в одном файле. Т.е. не postgres, а скажем sqlite (хоть это и так себе вариант). Либо такое - есть этот непонятного формата файл и когда первый раз его открываешь, он индексируется в БД, а потом картинки берутся из него, а поиск и всякие теги берутся из БД для скорости.

Не слушай >>13421 - коммиты разумнее разбивать по смыслу. А когда меняешь что-то в одной и той же вещи по смыслу, делать надобно Amend (пока не запушил на гитхаб). Так ты не будешь бессмысленно повышать энтропию в репозитории.

Я когда исходники смотрел, меня сильно удивило, что морда на JavaFX. Хотя наверно здесь это лучше, чем веб или Swing.

Забыл еще одну Самую Главную Киллерфичу.
Разумная избыточность не в ущерб шифрованию.
Т.е. если винт посыпется или еще чего, нужно чтобы вот всё это хранилище не рассыпалось. Чтобы можно было "лечить архив": из поврежденного хранилища снова сделать чистое, размером поменьше (выкинув поврежденные части).

Предлагаю создавать еще немножко метаинформации из самой картинки. Например, можно находить средний цвет картинки и искать их не по тегам, а ближайшие картинки к оттенку (гуглить "Формула цветового отличия", если используешь CIELab, можно заюзать CIE76 даже).

>>13783
> Я не планирую быстро сделать релиз
> по десять раз рефакторю один и тот же модуль
> сделать юзабельный безглючный релиз
> софт с глюками, костылями никому не нужен
Оставайся таким как можно дольше.

>>13786
Так дестопное приложение же. Свинг морально устарел, веб чисто теоретически требует сервера кому нужна возня с установкой и настройкой, да и в случае веб-приложения на манер i2p повышается сложность настройки-установки.
>>13787
Если сам файл базы с записями о картинках (h2) не будет поврежден, то отдельные битые пикчи ничего не испортят. Бэкап базы и настроек будет штатной фичей.
>>13785
Почти все перечисленное будет.
>>13784
Да, релиз на гитхабе будет во всех видах, в том числе собранный .exe - кому как удобнее. Хотя, по хорошему счету, .jar ассоциируются в винде с жавой и запускаются как ехе-шники, если стоит сама жава.

>>13790
>если стоит сама жава
Многие не хотят опорочивать свою систему жавой.

>>13794
/0.
Сидеть на венде и рассуждать об «опорочивании» чего-либо смешно, а в швабодном мире без джавы лайбриофис не откроешь.

>>13804
В швабодном мире есть латекс.

>>13810 Латекс — это для изделия №2. TeX отсылает к слову «техника» и читается соответсвенно.

>>13810
А я как-то пытался настроить имакс с затурой для работы в латехе. Для непосвящённых: имакс выступает в роли IDE, где вы собираете документ, пинаете из него PDF-вьювер, а также прыгаете из вьювера на код в документе. Естественно, ТеХ не умеет в PDF сам и ему нужны прослойки-прослоечьки. Короче ниасилил я всю эту кухню, хотя конпеляция участка кода в превью прям на месте (без вызова вьювера) была завораживающей.

>>13897
> Естественно, ТеХ не умеет в PDF
Умеет. Называется pdf(la)tex.

>>13804
Открыть-то можно, не собрать разве, если по dep'ам судить.

>>13899
Да, я перепутал. Превью должно было генериться из DVI, и для его вывода нужна была отдельная приблуда xdvi.

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

Оп, очень полезную и нужную штуку делаешь, сам всё хочу написать подобное для своих нужд, но каждый раз боюсь начинать такой большой проект.
Но бляяя, на жабе? Десктопное приложение на жабе? ЗАЧЕМ??? Это же сразу нахуй, опять же будет раздутое неюзабельное говно, жрущее гигабайты памяти и дико тормозящее на йобао-суперкомпьютерах.

>>13913
Жава не тормозит со времен выхода 1.7 если не раньше, и слухи эти больше вызваны сраным IE6- и апплетами в нем (да, оекаки им родня), что писали жопорукие тыжпрограммисты. Память под кучу оно забирает максимум, да, но во-первых, нафига памяти быть пустой, а во-вторых, двумя параметрами самой жавы эту прожорливость можно отключить, если внутренняя амфибия сильно душит. Ровно та же городская легенда, что и про VB, который и правда был жутким монстром первое время, но теперь в определенных применениях крайне удобен и незаменим. И ровно та же бугуртная горотская легенда про память в андроиде, и целая ниша "чистилок" ее. Память должна использоваться, а не болтаться свободной. Скорость генерации превьюшек у меня одинаковая с тем же долфином из кде или проводником винды. Скорость IO на мелких файлах выше на порядки того же проводника за счет многопоточности.
Жава дает переносимость между платформами, и ничего более подходящего нет. QT слишком хитровыебан и слабодокументитрован против жавы, на чистых плюсах такое писать работы в десять раз больше одна безопасная обработка строк чего стоит и непереносимо, скриптовые языки слишком медлительны и обрасли мхом фреймворков так, что за век не изучить на хороший для префекциониста уровень.

>>13923
>QT слишком хитровыебан и слабодокументитрован против жавы
>хитровыебан
>слабодокументитрован

>>13923
>И ровно та же бугуртная горотская легенда про память в андроиде, и целая ниша "чистилок" ее. Память должна использоваться, а не болтаться свободной

У меня тут на днях paged-память кончилась в винде. Это произошло потому, что три программы, одна из которых мне нужна, подумали, что память не должна быть свободной. Superfetch тоже так думал, пока я не отключил его.

Идите в лес, гражданин, короче.

>>13923
>Жава не тормозит
Уже смешно, ага.
Мне откровенно похуй на легенды, но из двух десятков десктопных приложений на жабе, которыми мне доводилось пользоваться достаточно продолжительное время, чтобы оценить производительность, 100% приложений жрали память как голодные волки и выдавали жуткие тормоза в самые неподходящие моменты. Мне похуй на то, какие там невъебенные скорости работы с файловой системой, или что скорость математических расчётов выше, чем в нативном коде и т.д., но если приложение подвисает и тормозит на уровне пользовательского интерфейса - оно тормознутое говно по определеню. И пока что под это определение подходят 100% виденных мной жаба-приложений.
И нет, я не мазохист, мне приходилось пользоваться этим говном потому что приложения узкоспециализированные и выбора попросту не было.

>>13912
Посмотрел, кстати, пока что это самое приличное из всего, что видел подобного, но бля, оно меееедлееееннооооеееееее. Питон, к тому же однопоточный, даёт о себе знать. Подключил к нему бд тегов данбуры - и всё, банально при попытке вбить тег в поиск оно подвисает секунд на пять. Короче, неюзабельно.

>>13929
>но если приложение подвисает и тормозит на уровне пользовательского интерфейса - оно тормознутое говно по определеню
Всецело в руках говнокодеров, считающих что-то в gui-потоке. Тормоза там только из-за этого, и такой подход чуть ли не стандарт отрасли, сам плююсь. Принцип нормального кодинга в жаве такой - если место в коде может даже теоретически дать задержку при выполнении более 20-50мс - ссанымии тряпками в отдельный поток его гнать. У меня на лету идет копирование\шифрование картинок, с суровым таким IO, сама система виснет - гуй работает прекрасно.
>>13926
Не нравится - отключи эту фичу у меня в релизе она будет выключена сразу. Жава по скорости разработки выигрывает у тех же плюсов, и дает переносимость. Ничего другого просто нет. Ко всему прочему у меня первая цель - выучить жаву, а потом уже сделать что-то на ней.
>>13925
Мне это показалось именно так. Но могу быть неправ.

>>13931
А управление ВНЕЗАПНЫМ сборщиком мусора(второй основной причиной жабьих тормозов) вам тоже уже позволили, или он до сих пор ВНЕЗАПЕН?

>>13931
>Не нравится - отключи эту фичу

Я не о жабе говорил, а о том, что **ПАМЯТЬ ДОЛЖНА ИСПОЛЬЗОВАТЬСЯ**.

>>13932
Но что нужно делать, чтобы сборщик создавал тормоза? for () { new Thread(new Runnable(){...}).run(); }? Я гонял 16 потоков, в каждом идет пережатие пикч, шифрование, дергание хибернейта, дергание levelDB, еще была генерация хешей похожести в репу не попало по причине полной велосипедности - по показаниям профилировщика 10-15% в сборщике мусора в самом худшем случае. IO 65-85мбайт\сек, ОС охуевала, но я не видел, чтобы программа сидела в сборщике хоть сколько-то значимое время.
Да, месье любят вместо написания пулов или использования уже готовых решений тупо плодить тяжелые объекты, и это второй херовый "стандарт отрасли". Там 50-70% в сборщике норм - вот все и тормозит. Этак и на сях можно malloc/calloc каждый раз делать и бросать, а потом плевать ядом, что С тормозит и жрет гигабайты памяти.
А на критических местах не грех и System.gc(); сделать, но без фанатизма.

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

>>13942
> **KUUDAH**
В шараге я не учился. Вообще. Но прежде чем начать делать проект, я тонну постов на SO перелопатил, пару-тройку книг и до того имел опыт кодинга на сях, php и когда-то очень давно кодил на VB. Так что опыт у меня приличный и разное оборудование на поиграть тоже есть.
Другое дело, что вся эта хуйня несистематизиована и "по верхам". С жавой то уже года три знаком, но вот порядок в знаниях оной начал наводить вот этим вот проектом, чтобы дальше по ней работать. Сейчас уже в раздумьях, надо было С лучше вытягивать на нормальный уровень, но вакансий на С почти нет.

>>13943
Ну то есть у тебя кроме вороха плохо систематизированной теории ничего нет, как я и сказал. Вот и не квохчи тогда. Теория != практика.

>>13912
Ставил как-то. Повертел туда-сюда, так и не понял, как туда хоть что-то добавить.

>>13923
> но во-первых, нафига памяти быть пустой
Чтобы не выгружалась в своп. inb4
> 2016
> своп
На линуксах vm.swappiness установлен по дефолту в 60, если мне память не изменяет. Значение инверсное — то есть, когда память забивается на 40%, система уже начинает по-тихому тормозить в своп. Поэтому я этот парметр загоняю обычно в 15.
> а во-вторых, двумя параметрами самой жавы эту прожорливость можно отключить
В jcontrol никаких параметров регулирующих, сколько памяти отжирать, нет. По крайней мере в Oracle JDK 1.8 на GNU/Linux.
> скриптовые языки слишком медлительны и обрасли мхом фреймворков
Некоторые скриптовые языки компилируются в байткод.

>>13929
> но из двух десятков десктопных приложений на жабе
Нельзя говорить об инструменте по двадцати прикладным программам написанным на нём хуй знает кем и как. /Для десктопа — так тем более./

>>13931
> сама система виснет - гуй работает прекрасно.
> система виснет
К вам CONFIG_AUTOSCHED ещё не завезли штоле?

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

>>13964

>>13965
А, дошло.

>>13443
zoner

>>14088
> The program Zps.exe has encountered a serious problem and needs to close. We are sorry for the inconvenience.

>>13408
>>делаю рефакторинг, ускоряющий обработку файлов
это оптимизация, рефакторинг улучшает читаемость кода.

>>14954

Одно другое не исключает. Рефакторинг - это значительные структурные изменения.

Бамп годному проекту.

Исправил баги в своей поделке.

Дополнил свою поделку ещё раз.

оценим, оценим...
и да - для рефакторинга всегда есть место

>>15998
А теперь пару слов... Почему не Гитхаб, а?

>>16017
https://ru.wikipedia.org/wiki/Popcorn_Time#.D0.98.D1.81.D1.82.D0.BE.D1.80.D0.B8.D1.8F

>>16020
Ну и потому, что я решил использовать у себя дома svn и от гитхаба будет деанон ещё.

>>15998
Ты ОП? Ну хоть бы написал что исправлно или добавлено.

>>16020
Твоя программа нарушает чьи-то права или патенты?

>>16056
>Твоя программа нарушает чьи-то права или патенты?
Я уже svn использовать решил. По двум причинам -- искоробочность во фряхе и номера версий вместо хешей.

>>16071
Ну и незашкваренность хипстерами-вебдванольниками ещё.

>>16021
> Ну и потому, что я решил использовать у себя дома svn
https://help.github.com/articles/support-for-subversion-clients/
> и от гитхаба будет деанон ещё.
Регаешь на фейкомыло и запрещаешь его показ в настройках аккаунта.

Bump. Оп ты где?

>>16476
Бамп, бамп и ещё раз бамп.

>>16476
Оп тут. Сейчас нет времени на это, если честно. Да и десктопная жава никому не нужна, это как учить кобол или дельфи в 2017. Особого интереса к проекту я не увидел, если честно.
Сейчас я эту штуку хочу переделать в restful-сервис, а морду можно на том же Qt написать. Заодно и приложение под андроид слабать можно...

>>16928
>Qt
Нет.

>>16928
Так мало кто картинкопаки в 2017 собирает, а уж тем более шифрует. Удачи тебе, ОП, проект достойный, но в узких кругах.

>>17084
Ну, тем кто рисует, например, паки нужны - у нас из-за проклятых моралофажков буры скоро перебанят и переабузят совсем. Да и если собирать в соцсетях, то там бывает деллалл - уже не раз замечал пропадание даже не порнушных картинок из репостов\избранного.
Я сейчас весьма активно полез в изучение спринга, на нем и буду делать серверную часть, только немого позже, как разберусь с основами на чем-то попроще.

>>17323
Будешь отписывать? Тоже собираю, но пока сижу на Graber, он по бурам лишь.