он им тоже железные ключи показал, или предпочел не выпендриваться?

ну то есть он конечно потом много чего написал в интернете, мол его пытались завербовать, но пашка такой им говорит: «пошли прочь менты поганые» а ФБРовцы такие «окей».

а вот как было с сервисом lavabit:

В августе 2013 года этому сервису неожиданно пришлось закрыться. На главной странице появилось сообщение основателя и владельца сервиса Ладара Левисона (Ladar Levison): «Дорогие друзья, меня заставили сделать сложный выбор: стать соучастником преступления против американского народа или отказаться от почти десяти лет тяжелой работы и закрыть Lavabit. После долгих раздумий я решил прекратить работу». Давление, вероятно, было вызвано тем, что данным сервисом пользовался Эдвард Сноуден, и от сервиса власти США требовали раскрыть данные беглого бывшего сотрудника АНБ. Видимо, для Левисона оказалось проще закрыться, чем предоставлять третьим лицам доступ к учётной записи электронной почты Сноудена.

К чуваку пришли агенты смиты, расписали что не могут заставить его выдать ключи, но чувак, вот девушка с которой ты переспал N лет назад и она может заявить что ты её изнасиловал и тогда... Чувак подумал, и всё понял.

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

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

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

А тут пашка. Пашка не таков. Полицай ему такой: пашка ну пожалуйста, ну молю тебя. Тебя весь конгресс на коленял молит, и президент. Мы тебя как человека просим и умоляем - дай ключи. А пашка такой Нео, он берет, связку ключей и кидает их в сраную фбровскую морду. И говорит так: понел, падла? отсаси! У вас нет методов против пашки дурова. А фбровец такой думает: ёпта, это ж сам пашка дуров. Наша магия бессильна против телеграма. Мы не можем просто взять и посадить его нахер запросто так. И даже негров с ближайшей порностудии не можем привлечь на час. Чо делать? и такой заплакал и ушел. Приходит к главному фбровцу в гестапо и говорит: ну ты понимаешь, я ему и так и эдак. А он никак. И главный фбровец тоже заплакал и говорит: мы бессильны против вебдваноля.

Вот так телеграм победил ФБР.

комбинации английских букв, цифр и иногда подчерков?

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

* * *

давайте я уширшу своё утверждение. еще совсем недавно NIST рекомендовал делать пароли типа aBcDeFgH. Кстати тоже очень удобно подбирать, вариантов не 2^(8*n) а 2^(5n) а то и того меньше.

* * *

Я еще уширшу своё утверждение

Кстати, как я понимаю, недавно условный запад допилил свои персептроны, известные рабам и быдлу как «нейронные сети». И видимо их придрочил к подброру паролей, а потому NIST выпустил новые правила:

https://www.securitylab.ru/blog/personal/bezmaly/310208.php

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

Linux kernel currently does not provide any race-free way for calling
unlink() syscall on file entry which points to opened file descriptor.

On the other hand Linux kernel already provides race-free way for
creating file entry by linkat() syscall with AT_EMPTY_PATH or
AT_SYMLINK_FOLLOW flags. unlinkat() does not.

There was already discussion about unlink issue in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=93441

это сегодня в почту свалилось.

ох лол. приехали. вот знаете, а как им это удаётся?

Дано:

http://i.zlowiki.ru/180404_4a3992fd.png

Рисуется так

glSetPrimitiveRestartIndex(PR) VertexBuffer одинаковый.

Index buffer у всех

0, 1, 2, 3, 4, 5, 6, 7, PR, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, PR

две струкутры RC c полями mFirstIndex, mNumIndices.

1) картинка верна, получена либо:

rc1 = {0,8}, rc2 = {9,11}
glDrawElements(GL_TRIANGLE_STRIP,
                          rc.mNumIndices,
                          GL_UNSIGNED_INT,
                          (GLvoid*)(long)(rc.mFirstIndex*4));

А также

rc1={0,20}

rc1={0,20}
glDrawElementsBaseVertex(GL_TRIANGLE_STRIP,
                           rc.mNumIndices,
                           GL_UNSIGNED_INT,
                           NULL,
                           rc.mFirstIndex);

2)картинка неверна, вторая фигура без первой и последней вершины

rc1 = {0,8}, rc2 = {9,11}
glDrawElementsBaseVertex(GL_TRIANGLE_STRIP,
                           rc.mNumIndices,
                           GL_UNSIGNED_INT,
                           NULL,
                           rc.mFirstIndex);

3) проверяю что вершина всё таки есть:

rc1 = {0,8}, rc2 = {9,11}
glDrawElementsBaseVertex(GL_TRIANGLE_STRIP,
                           rc.mNumIndices,
                           GL_UNSIGNED_INT,
                           NULL,
                           rc.mFirstIndex-1);

но если сделать rc.mNumIndices+2 и rc.mFirstIndex-1 чтоб зацепить эти две пропавшие вершины, то первая вершина появляестя, но вместо последних двух вершин как будто нули. В доке написано, что это говно просто «добавляет baseIndex». И вот нет!

А на AMD всё работает! я там сцену в один выстрел рисовал через glMultiDrawElementsIndirect, всё рисуется,ракеты летают, в ИК канале светятся, погода все дела. Переносим на NVidia. И всё, пустота. ни пикселя ни отрисовано. Ну ладно, подумал, бывает, функция сложная всё таки. А тут опять и уже на такой простой древней функции.

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

Короче,

Qt5.5,

OpenGL version string: 3.3.0 NVIDIA 340.102

OpenGL shading language version string: 3.30 NVIDIA via Cg compiler

проект с нуля с содержимым mainwindow.cpp ниже, крэшит компилятор шейдеров(шейдер просто затычка).

Вопрос, что делать то? Ведь десктоп работает

$ sauerbraten 
Using home directory: /home/user/.sauerbraten/
Adding package directory: /usr/share/games/sauerbraten/
init: sdl
Library: SDL 1.2.15
init: net
init: game
init: video: mode
init: video: misc
init: gl
Renderer: GeForce 210/PCIe/SSE2 (NVIDIA Corporation)
Driver: 3.3.0 NVIDIA 340.102
Rendering using the OpenGL GLSL shader path.

Upd: эта скотина насрала чем-то нехорошим в ~/.nv/blablabla однократно показаный фак-ю починил кэш для конкретного процесса, и далее он стал работать даже после возврата к крэшащимся шейдерам.

стектрейс:

(gdb) bt
#0  0xb4078280 in ?? () from /usr/lib/nvidia-340/libnvidia-glcore.so.340.102
#1  0xb4078323 in ?? () from /usr/lib/nvidia-340/libnvidia-glcore.so.340.102
#2  0xb40cb9b7 in ?? () from /usr/lib/nvidia-340/libnvidia-glcore.so.340.102
#3  0xb4005ab5 in ?? () from /usr/lib/nvidia-340/libnvidia-glcore.so.340.102
#4  0xb400a30d in ?? () from /usr/lib/nvidia-340/libnvidia-glcore.so.340.102
#5  0xb4ca54eb in ?? () from /usr/lib/nvidia-340/libnvidia-glcore.so.340.102
#6  0xb4ca7706 in ?? () from /usr/lib/nvidia-340/libnvidia-glcore.so.340.102
#7  0xb767206f in ?? () from /usr/lib/i386-linux-gnu/sse2/libQt5Gui.so.5
#8  0xb7672e25 in QOpenGLShader::compileSourceCode(char const*) () from /usr/lib/i386-linux-gnu/sse2/libQt5Gui.so.5
#9  0x0804a883 in MainWindow::MainWindow (this=0xbfffeff4, parent=0x0) at ../nvtest/mainwindow.cpp:43
#10 0x0804a380 in main (argc=1, argv=0xbffff0d4) at ../nvtest/main.cpp:7

#include "mainwindow.h"
#include <QOffscreenSurface>
#include <QOpenGLContext>
#include <QOpenGLShaderProgram>
#include <QDebug>
#include <stdexcept>
#include <QOpenGLFunctions_3_3_Core>

typedef QOpenGLFunctions_3_3_Core GLFuncs;

static const char * __shader_vertex =
        "#version 150\n"
        "void main{}";
MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent)
{
    auto mOffscreen = new QOffscreenSurface();
    auto fmt = mOffscreen->format();
    fmt.setVersion(2,1);
    fmt.setRenderableType(QSurfaceFormat::OpenGL);
    fmt.setProfile(QSurfaceFormat::CoreProfile);
    mOffscreen->setFormat(fmt);
    mOffscreen->create();
    if (!mOffscreen->isValid())
        throw std::runtime_error("failed to create offscreen surface");
    auto mContext = new QOpenGLContext();
    mContext->setFormat(mOffscreen->format());
    if (!mContext->create())
        throw std::runtime_error("failed to create opengl context");
    qDebug()<<mContext->format();
    if (!mContext->makeCurrent(mOffscreen))
        throw std::runtime_error("failed to make opengl context current");
    qDebug()<<"A!";
    QOpenGLShaderProgram * p = new QOpenGLShaderProgram();
    qDebug()<<"B!";
    p->addShaderFromSourceCode(QOpenGLShader::Vertex,
                               "#version 150\n"
                               "void main() {\n"
                               "}\n");
    qDebug()<<"C!";

    QOpenGLShader xxx(QOpenGLShader::Vertex);
    xxx.compileSourceCode("void main{}");
    qDebug()<<"D!";

    auto f = mContext->versionFunctions<GLFuncs>();
    if (!f->initializeOpenGLFunctions())
        throw std::runtime_error("failed to make initialize GL functions");
    //mContext->doneCurrent();
    qDebug()<<"E!";

    qDebug()<<__FILE__<<":"<<__LINE__<<"!";
    GLuint s = f->glCreateShader(GL_VERTEX_SHADER);
    qDebug()<<__FILE__<<":"<<__LINE__<<"source";
    const GLchar * ps = (const GLchar*)__shader_vertex;
    GLint          psi = strlen(__shader_vertex)-3;
    f->glShaderSource(s, 1, &ps, &psi);
    qDebug()<<__FILE__<<":"<<__LINE__<<"compile";
    f->glCompileShader(s);
    qDebug()<<__FILE__<<":"<<__LINE__<<"?";
}

MainWindow::~MainWindow()
{
}

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

более того, и на 8е марта не было такого потока мимимишек, и на 23е февраля тоже как-то не хлестало.

это приятно видеть. в самом деле, люди перестают делать действия только потому, что им сказали что так НАДО.

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

Человеки же думают, что если им перед лицом руками не поводили, то они типа «разумны» и не загипнозены. Хотя сиё странно, ибо им перед лицом хером водят каждый день со школы, и они послушно выполняют всё, что они «должны делать».

Попускает что ли.

А вот хотелось бы поговорить об вещах для линукса фундаментальных.

Вот у нас есть терминал. Есть всякие окраски, автозавершения и т.д.. Но говно ваш терминал. Потому что терминал занимается тем, что эмулирует vt101 или подобное говно. Ну правда, а почему графику в терминале надо выводить через libsixel которая эмулирует ещё какой то очередной кусок гавна из 80х?

Проблема линупсового терминала в его убожестве, которое возведено в ранг религии. Вот вам пример: я в терминале здорового человека для всех файлов типа png сделать cat .... | tranform_somehow | transform_ololo | write ...

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

Я помню как alan cox с линусом поругались. Кокс говорил что терминальному говну не место в ведре и я с ним согласен. Терминал следует свести к пайпу с доп.функциями. в сам пайп надо внести обратную связь и кстати пайпу вообще можно заменить на shm

Без модели я диод и так знаю, но ска нужна модель. И модель должна вставляться в ORCAD. Такие вот дела

Я поставил бубунту16.04 и мягко говоря удивлён. это какой-то FIAL. на других ноутах стоит 14.04 и просто работает, хотя ноуты слабее(AMD A6 & AMD-E50 vs Corei5) но в итоге ноут просто невменяемо тормозит.

Минт вроде как недавно получил по губам от убунты за тырение пакетов. Не уверен что его стоит устанавливать.

Как скачать дебиан я просто не понял. Нашел загрузки, тыкнул amd64, и вместо iso сайт показал мне FAQ. не люблю когда сайт тыкает мне FAQи.

Как быть?

Многие из присутствующих еще не успели застать времена, когда иксы еще назывались хfree86 и потому не знают, кого благодарить за то, что у них нвидия без шмеля не работает. Рассказываю почему в линуксе все плохо с графикой там, где в винде просто берет и работает.

Когда-то видяхи были только PCI и немного ISA. ISA это вообще чтоб страдать, я помню у меня была аудиокарта ISA.... ооооо, как безбожно тормозило видео на k6-500 с этой аудяхой и как оно игралось мплеером с pciшной картой. Короче, ISA - это вообще зло которое надо забыть как страшный сон. Поэтому его забыли и в ведре все устройства растут из «шины PCI».

Но в те далекие времена видяхи точились под windows gdi(посмотрите hardware caps той же s3trio64v+) и поэтому дров под линукс для них не было. а там кстати были аппаратные шрифты, если кто не знает. поэтому в линуксе была только опция framebuffer и страдать. А чтоб совсем уж не тормозить, картинки гоняли через MIT-SHM.

Затем появилось ускорение, и работало оно на стороне сервера х86 и то - только по талонам и для своих. Плюс иксы тупо лезли своими лапами прямо в железо, да так, что для них даже вход со двора делали в ведре, и вход этот назывался DRI1.

«The legacy DRI1 drivers expose highly broken interfaces to user-space. No modern system should enable them, or you will effectively allow user-space to circumvent most of your kernel security measures. The DRI1 kernel APIs are simply broken. User-space can always use vesafb/efifb/simplefb and friends to get working graphics. Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to be still used (really?), we can easily revert this and figure out a way to move them out of sight (e.g., moving all DRI1 drivers to drivers/gpu/dri1/).»

Затем появился DRI2, а с ним пришли и гениальные в кавычках решения. Вот например кто был тот долбо* кто решил что объекты DRI надо сделать обязательно файловыми дескрипторами? Ну он хоть что-то на opengl писал? Знает, что там GLsync это void* и его в poll не сунуть? Если хочешь добавить фичу ждания, добавь функцию в struct file_operations когда символьное устройство регистрируешь. А кстати, из-за этого гениального решения каждый процесс может потырить данные из текстур другого процесса. А еще прикольное решение: авторизация в DRI2 - клиент открывает устройство, спрашивает у сервера «пароль», сервер сообщает драйверу «пароль» и передает его клиенту чтоб тот тоже ввел этот пароль. Вот скажите, в юниксе, где можно файловые дескрипторы через unix socket передавать, заранее зарядив в них пару ioctlов, это что, не рукожопие? Кстати, длина этого «пароля» - 32 бита.

Далее, у нас появилась шина AGP. А с нею в линукс пришел agp_gart и такая пакость как ttm. Великий и ужасный генератор паник и багов ttm! А всё с чего: памяти у видях было мало, метров 16-32, и кто-то умный не в кавычках придумал, что можно одноразовую память и прямо из системной брать. Для этого в AGP сделали самый настоящий iommu, только назвали почему-то GART. если вы полазаете в биосе старых мамок, наверняка увидите такую вещь как AGP aperture - вот это и есть колво мегабайт, которое AGP может пробросить в видяху.

А я напомню, что графическую подсистему пишут не скотинки, а умные гениальные люди, которые уже запилили псевдо-файловые дескрипторы в DRI2 и пароли из 32бит, зато никогда ни гуй и игорей не пилили. Поэтому какой-то мудак придумал, что TTM эти текстуры должен свопать! То есть у вас обычно всего лишь одно 3д-приложение активно чтоб по-серьёзному. это либо игорь, либо композитор. все остальные живут набегами на видеокарту и держат в ней максимум кэш из буферов. Его не надо отсвопывать, его надо изначально положить в памяти и никуда не двигать, а лишь туда перенацеливать GART. Типовая задача отрисовки состоит в том, чтоб положить в буфер все свои пиксели, иконки(вы подумайте как нибудь, что стоит отрисовать маненькие такие иконки), сказать где что лежит и отправить в полёт. Одна операция с точки зрения драйвера - вот буфер с кучей команд, возьми, поработай и положи обратно. Но мы же не ищем легких путей! жизнь должна быть болью, причем желательно в жопе, причем желательно у всех пользователей линукса. Поэтому сделали сложно и глючно.

Далее, видяхи стали комбинироваться. Пользователи нвидии, вы наверно слышали про «оптимус»? Болит, да? А хотите я вам скажу, что всё это время вы могли не страдать если бы не долбо*-разработчики? Бесплатные курсы 3д-графики на ЛОРе!

В OpenGL есть такое понятие как framebuffer. Немного погрубже под ним, есть такое понятие как swapchain, обычно вы его видите как double-buffer но может быть и тройной(он лучше, т.к. не долбит синхронизацией) и даже больше буферов(бывает нужно если видяха сильно запаздывает при сохранении фреймрейта). «Нулевой» фреймбуфер собственно и подключен к этому свопчейну и вы именно в этот свопчейн запихиваете картинку командой чототамSwapBuffers. Помимо него, вы можете накастовать своих фреймбуферов командов glGenFramebuffers, тоже красивых и модных но без фреймбуфера. Чтоб брать картинки оттуда вам надо симулировать свопчейн своими руками, а именно:

0) в самом начале создать свой swapchain c 2-3 текстурами типа RGBA. одну из них приаттачить к фреймбуферу. ну и depthbuffer с шаблоном, по требованию. кроме того надо сделать две очереди:

typedef struct {
   GLsync* mRenderComplete;
   GLuint  mOutputTexture;
   GLuint  mPixelBuffer;
   GLsync* mCopyPixelsComplete;
   int     mWidth, mHeight;
   Image * mPixels;
} SwapItem;
SwapItem swapitems[N];
typedef std::deque<SwapItem*> SwapChain;
SwapChain in; //уже ненужные кадры
SwapChain out;//кадры на отправку

само окно создаете чисто 2Дшное.

1) в момент вызова kokokoSwapBuffer, создать объект типа GLsync, отцепить от фреймбуфера текущую текстуру GL_COLOR_ATTACHMENT0 и вдвоем положить их в очередь. GLsync кладется в mRenderComplete, текстура все время лежит в mOutputTexture

2) проверить, что в очереди in есть новые текстуры. если нет, ждать в первом в очереди элементе

2а)если !null SwapItem->mRenderComplete должен отсигналиться

2б)если !null SwapItem->mCopyPixelsComplete должен отсигналиться

2в) удалить все ненужные GLsync которые вышеописаны

3) зайти в каждый элемент out, проверить SwapItem->mRenderComplete если !null.

3а) если он отсигналился, mPixelBuffer это pixel buffer, который надо замапить в режиме GL_MAP_PERSISTENT|GL_MAP_UNSYNCHRONIZED и адрес положить в mPixels. Если размер окна изменился, этот буфер надо пересоздать и перемапить.

3б) запускате glPackPixels в этот буфер. ставите mCopyPixelsComplete.

3в) шаг 4 пропускаете для всех таких элементов

4) зайти в первый элемент out, проверить SwapItem->mCopyPixelsComplete если !null.

4а) если он отсигналился, mPixels это и есть ваша картинка. рисуете её средствами обычного 2D.

4б) Как только она вам не нужна, и у вас следующий элемент в out тоже отсигналился, вы просто перекладываете SwapItem из out в in.

5) PROFIT!!!!!!

И мое решение будет работать под SDL2, в Qt, Gtk, и так далее. Ему просто будет похеру. Потому что именно так и работает оптимус в винде. А то что он у вас в линуксе работает через боль - это потому, что графон вам пилят мудаки безрукие. А поскольку они умные а я нет - поцелуйте их в жёппу за то, что нулевой фреймбуфер они гвоздями прибили к DRI2-шному свопчейну и вышеописаный фокус провернуть не удастся именно из-за этого.

Легко заявлять «фак ю нвидия», когда на стороне нвидии выступают бессловесные разработчики, которые (наверно как и в АМД) пилят дрова для линукса в режиме партизан, в то время как куроводство требует сосредоточиться на винде. Которые не могут ответить линуксу, что он сам должен быть хоть немного в ответе за свой курятник и факи свои должен был отнести в dri-devel местным долбозверям, в первую очередь дятлам что из интела.

Далее, это еще не всё. Продолжаем уроки OpenGL на ЛОРе. Самая главная фишка OpenGL4.4+ - это мапание буферов с GL_MAP_PERSISTENT|GL_MAP_UNSYNCHRONIZED, когда ты организуешь циклический буфер достаточно большого размер. Или несколько их. В один буфер кладешь новые данные, в другой команды для indirect draw, в третий - обновления для текстур и так засылаешь на GPU. Буферы эти статичны в процессе всей игры или жизни приложения, ну или почти статичны(возможно их надо будет время от времени уширять). Так вот, в плане драйвера весь этот процесс можно уместить в один общий для всех видях драйвер который стукает в серверный процесс, где сидят уже драйвера видях и не оттормаживая приложение и не засирая кэши отрисоывывают всё-всё-всё и сигналят GLsyncи, которые можно сделать через futexи. И это будет быстро, волшебно и безопасно! Хоть сколько видях напихай - все будут работать и дружить друг с другом. Более того, драйвер может сидеть вообще через UIO и ядро не трогать.

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

Говорят, линукс набрал уже не то 2 не то 3 процента на декстопах. Я когда-то стал пользоваться линуксом, хотя вру, я стал пользоваться фрёй 4.5. Но и линукс я ставил, просто на 64мб он совсем не шевелился. С тех пор прошло лет ... я даже забыл сколько, наверно 14.

Но я помню, что тогда опенсорные оси были развивающимися и в них было совсем тяжко с повседневным софтом, но было очень много софта для разработки. Это очень бросалось в глаза в тех же репозиториях.

Так вот. Чего я не понимаю: прошло 15 лет. Разработчики запилили просто ёную тучу всяких тулзов для сборки.

Я когда стал делать кисий язык, я вообще хотел решить очень узкую проблему, а именно: на верилоге можно описать логику микросхемы, но эффективное решение зависит от того, как эта логика будет разложена по кристаллу. У меня возникла проблема, которую надо решать как в виде текста так и в виде чертежа ОДНОВРЕМЕННО. Потом я понял, что эта проблема есть и обычном программировании и решил пилить общий подход с плагинами.

К чему я это? Я программист и у меня возникла проблема со средствами разработки. Я понял, что существующие средства не дают мне реализовать мои идеи удобным мне способом за разумное время. Я начал пилить средства автоматизации.

А вот задача из жизни, в которой я еще и работаю: есть QPainter, и QImage с форматом Format_Alpha8. Надо чтоб он рисовался именно как альфа, не как grayscale как это «на отвали» сделали разработчики. Как найти где это говно таки рисуется любыми доступными нам на сегодня средствами? Вот я написал

mPainter.drawImage(x, y, font->image, ci.value().x(), ci.value().y(), font->width, font->height);

и хочу отсюда узнать, что же в итоге произойдет. Альфа - это ведь не цвет, я хочу чтоб цвет брался из текущего brushа. Я художник, я так вижу. Я хочу чтоб средство разработки(IDE например) мне нашло то место, куда дойдет или может дойти управление. Я знаю что это можно сделать.

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

Поэтому в линуксе до сих пор вместо отладчика gdb. Это конечно хороший отладчик для Си, но ёп вашу вать... А если я пишу не на Си? А если у меня есть finite_state_machine и я хочу узнать, в каком она состоянии? А если еще какая нибудь срань? Мужики, у нас 21й век на дворе ялдь, почему до сих пор вкалывают программисты а не роботы?

В общем, 15 лет. На выходе у нас зоопарк систем сборки, толпа изнасилованных С++ом хомяков, молящихся на грядущего мессию(сперва это была жава*, теперь раст), собственно раст как попытка компилятором заделать дыру в средствах разработки, и прочий трэш.

(здесь должна быть фотография памятника Юрию Гагарину с надписью «юра прости, ...»)

В общем, возвращаясь к первому абзацу. Давайте я вам ещё пример приведу.

Линукс был развивающейся системой в 2003. Уже тогда будь я Торвальдсом, я бы подумал о создании отдельной от линукса системы для графона. Была такая тема unified drivers, их столлман зарубил. А так бы была еще тогда скотоОС. Так вот, можно было еще тогда создать в OpenGL подразделение «linux graphics» где выработали бы общие условия для графония. сперва бы его крутили в режиме отдельного процесса как в RTOS. Не хотят с нами графонщики делиться дровами - ну так давайте им песочню сделаем специально с пометкой «для утырков». Она станет стандартом. А потом она станет стандартом и на винде, а далее мы их туда заманим и будем отладкой выявлять как они работают с железом. А не как сейчас когда это делается хаками. Вы бы лет на 10 раньше имели свободные дрова если бы скотинка был царем линукса.

У линукса была фора: в нем можно было экспериментировать. Много чего было «открыто» именно в линуксе, например futex. И где выхлоп?

Я к чему это говорю: 15 лет просрано. По всем направлениям. Если линус покажет фак нвидии - нвидия утрется, но если нвидия покажет фак линусу - пользователи линукса утонут.

(здесь снова должна быть фотография памятника Юрию Гагарину с надписью «юра прости, ...»)

*)в 2009м форум лора как я понял был вайпнут, а так бы мы могли видеть эпические темы «жава выполняет бесконечный цикл до конца быстрее С» и «жава быстрее процессора».

тыкните мне в идеале на linux crossreference(вроде https://elixir.bootlin.com/linux/latest/source) или хотя бы на релиз ведра где их завезли точно.

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

А вот смотрите. Допустим, я соглашаюсь. Но библиотеку opencl сую свою, которая просматривает результаты майнинга и намайненый биток крадёт, а приложению говорит, что никаких битков не видела.

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

Как вам такой способ борьбы с черным майнингом?

Я ранее упоминал что, когда выдается свободное время, пилю кисий язык

Доброе слово про раст

Кто не читал, лучше почитать по ссылке, там общая идея и идеология. Потому что «кисий язык» это не язык программирования. Ну просто названия другого не придумал, а звучит красиво.

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

Отдельно обращусь к растаманам. я хоть и ругался с вами, но я ругался потому, что мне не нравится то КАК вы решаете проблему и ноете на С++, как будто он является воодушевленным существом типа люфицера. Это тупо, поэтому я вас ругал разными словами. Но само стремление решать проблему похвально. Мне ваше мнение, как ни странно, интересно. Возможно, в итоге вы возьмете мои наработки с сделаете Rust++ который реально убьёт С++.

1) в КЯ предусмотрены переменные как в верилоге:

int a = 5;
int b = 4;
always int c = a + b; //c = 5+4 = 9
a = 2; //c = 2+4 = 6

этот момент уже решенный, прошу не спрашивать как будет дело с оптимизацией. будет точно также как с unused variable в Си - вжух и нету.

Однако, вопрос есть такой: мы можем добавить режим «функционального программирования»:

var foo = {
   код с returnами; в целом это как лямбда, только без аргументов
}

2) 2 разных thisа. Есть this - это класс, к которому применен оператор прямо вот сейчас. а есть например that: это контекст. мы исходим из того, что описывать поведение сложных finite state machine будем в виде отдельных сценариев, которые потом машина сама соптимизирует. так вот каждый сценарий - он как класс. и в нем есть «параметры»:

int calculate(int a, int b) {
   parameter int k;
   return a*k+b;
}
....
case A {
   int k = 2;
   int x = calculcate(3,4);
}
...
case B {
   int k = 2;
   int lol = calculcate(6,8);
}

3) Улучшители конкструкций if-elif-else-for-while.

Исходный пример:

bool predicate = ....
while(predicate) {
   stmt1;

   stmt2;

   stmt3;

}

bool predicate = ....
always while(predicate) {
   stmt1;
   ####if (!predicate) break;
   stmt2;
   ####if (!predicate) break;
   stmt3;
   ####if (!predicate) break;
}

Годна ли идея?

4) блоки кода можно не только «оборачивать» в {} как в С и С++, но и называть:

for(int x in (0,5)) {//не спрашивайте почему это похоже на питон
    step сделать_раз {
     ....
    }
    step сделать_два {
     ....
    }
    step сделать_три {
     ....
    }
}

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

Годно ли? Добавить ли что-то?

5) Finite-state machines и короутины. В принципе это одно и то же.

Тут на самом деле вопрос как записывать. Еще вмешивается нюанс реализации. Дело в том, что в итоге код будет генериться «жуткий»: в каждом потоке будет что-то типа futexа, маски прерываний, маски разрешения прерываний, и времени максимальной обработки. не спрашивайте зачем такое - когда пишешь гуй, который должен рендерить и паралелльно что-то считать сложное и исходник для сложного могут при этом редактировать - вот так и приходится. код IDE придется с C++ еще переписать потом на кисий язык.

Так вот, при чем тут корутины? А при том, что у вас будет 1 главный поток и N вспомогательных, и туда будут сигналиться все эвенты как прерывания. код будет исполняться «блоками», в конце каждого блока будет проверяться равенство маски «отсигналенных прерываний» маске «уже виденых». корутина в этот момент может unlikely(префикс 0x2E + jxx) уступить место другой или вообще умереть с исключением.

Вопрос, как это всё записывать? Пока идея такова:

case A(expression_which_can_be_cast_to_bool) {
   case A1(expression_which_can_be_cast_to_bool) {
   }
   case A2(expression_which_can_be_cast_to_bool) {
   }
   case LOLWAT(expression_which_can_be_cast_to_bool) {
   }
}
case B(expression_which_can_be_cast_to_bool) {
   ...
}
case C(expression_which_can_be_cast_to_bool) {
   ...
}

6) UB: UB разрешено, если оно не влияет на control flow. а именно: ряд операторов в выражениях могут быть неоптимизируемыми в определённых условиях.

int a = x < x+1; //UB

int a = x < x+1; //UB
if (a) ... //warning! 

if (x < x+1) ... //UB нет, "<" не оптимизируется

* * *

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

Так чтоб сюжет кардинально менялся например каждый год. Или хотя бы полгода. Чаще - не нужно.

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

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

У нас на ЛОРе регулярно всплывают темы, как через жопу внедрили линукс то там то сям. В эти темы сбегаются диванные специалисты и начинают друг друга консультировать на тему просирания полимеров. Это занятие безусловно важное и нужное, так как просраные полимеры сами не обсудятся. Но почему бы не направить эту энергию в полезное русло?

Вот например, проблема: нечем посмотреть результат КТ. программа есть, но про неё не знают. И что хуже - не знают где спросить. А тут у нас целый табун экспертов, которые явно хотят ответить на эти вопросы, если их мотивировать. Тем более что конкретная проблема уже решена, и все что надо - собрать софт и опакетить его.

Можно было бы направить усилия диванных аналитиков на решение подобных проблем за мзду. А именно: создать каталог «проблем»: чем открыть такой-то формат, как настроить такую-то херь. Туда будут приходит заказчики с денежкой в руках и вопросами в голове, задавать их или получать ответ что вопрос поставлен и вам перезвонят. С другой стороны будут сидеть диванные эксперты, и решать нерешенные вопросы за мзду. Потом избранные модераторы будут выбирать лучшее решение(или решения) и тоже за мзду. А над всем этим будет сидеть руководство ЛОРа и откусывать свои законные проценты..

Всё это можно оформить в привязке к программе импортозамещения. У нас ведь в минсвязи сидят грамотные дядьки. Тот же Герман Клименко, которого недавно обсуждали. Он кстати в пейсбуке есть, и наверно где нибудь еще есть. Ему можно постучать и внести предложение в общих чертах.

Линукс от этого только выиграет, потому что он не будет таким колючим кактусом, с которым организации боятся связываться. Вместо этого у них будет раздел на ЛОРе, где они смогут заполнить чек-лист того, что им нужно от линукса а что уже реализовано.

Клаватура - оптимус, с экранчиками на клавишах.

Хочется использовать её например для игорей или для программирования. Но как?

я погуглил и не нашел дров, у них на сайте только под мак и винду и явно написанные рукожопами: сегфолты в драйвере USB- это как? то есть я знаю как, но ска. Windows Driver Foundation же есть. libusb. далее привязки к браузерам вот сразу видно что говнокодят. но вдруг есть какой-то драйвер который можно взять и потыкать?

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

Вот чего я не понимаю. Когда собираются анимешники или реконструкторы, они демонстрируют друг другу косплей или устраивают бугурты. Когда собираются бдсмщики, свингеры или гомосексуалисты, они друг друга например трахают. А что делают линуксоиды на своих сходках?

Я что то даже представить не могу. Информируют друг друга о линуксе? Устанавливают линукс(инсталлфесты по-моему это групповой фетишизм)? Курят маны? В чем прикол?

О чувак у тебя линукс на компе. У меня тоже, давай обнимемся и поплачем.

Вот взять меня. Я бы с удовольствием побеседовал из всего множества местных обитателей с stevejovs и ещё наверно с пятью, может шестью человеками. Я узнал бы от них что то новое, интересное. Возможно бы понял что в чем либо ошибаюсь, переосмыслил свои взгляды.

Но встречи с абстрактными лорчанами... Даже под пиво: у вас что, настолько нет друзей, что приходится находить суррогатных? А если не в пиве дело, то в чем? Большинство из вас для окружающих это аватарка и никнеймом. Ну может ещё некоторое общее представление о человеке на основе его постов. Ты закрываешь браузер и этого человека нет до следующего захода на лор. Я не вижу разницы между большинством лорчан и допустим пользователями той же quora или politicsforum.org. вы как бы в теории есть наверно, но вас нет.

Нахрена вы собираетесь?

Я много ругал Раст, по делу и без дела. Но есть в расте нечто, что является его несомненным плюсом.

Так получилось, что я пилю свой «кисий» язык. Название выбрано таким потому что изначально я хотел сделать инструмент для моделирования микросхем вместо анального верилога. Ну чтоб сразу и топологию прикинуть можно было и шины в один тык менять например 2 параллельные на одну double data rate. В общем была такая задача, потом подумалось что с помощью небольших усилий можно из имеющегося супа сварить игру песочницу для симуляции 8битных компов. Прямо с платами, 3д модельками микрух. И назвать я ее решил к155ла3. Собственно язык был назван «к».

Так вот, далее оказалось что подход симулятора микросхем на плате (или блоков в топологии) можно распространить ещё дальше: на симуляцию просто программ. Пришлось сильно редизайнить уже готовый код. Суть в том, что язык программирования К это не язык, а база данных. В процессе проектирования мы рассматриваем программу с нескольких сторон. Ну представьте себе что вы взяли кубик и его рассматриваете с нескольких сторон по очереди.

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

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

При чем же тут Раст, спросите вы? А вот я, хоть и считаю Раст попыткой рукожопов отомстить своим кривым рукам, почитал про этот самый раст. Некоторые концепции мне очень даже понравились. Например вот это impl. У меня та же срань сделана. И matching тоже збс идея. Вы даже не представляете насколько она тащит. Не сама реализация а идея о том, что переменная может быть больше чем просто сама она, а может также содержать например инфу об ошибке.

Например пусть у вас есть переменная Х. Пусть её тип не указан. То есть по факту переменная Х содержит два значения - адрес данных о типе и значение. Пусть Х = 5.4/0.0; давайте в Х добавим возможность посмотреть флаги операции: nan, денормализованное, и т.д. пусть Х=0х80000000+0х80000000. Давайте дадим возможность прочитать carry flag: Х.carry. Пусть Х = 0х80000000*0х80000000. Давайте дадим возможность прочитать старшие 32бита результата. Это лишние поля в большинстве случаев но оптимизация может херить неиспользуемые поля.

Я думаю что Раст это на самом деле хорошее явление. Люди ищут новые пути и решения и это можно только приветствовать. Беда Раста в том, что люди, создающие его, создают ещё один язык. Язык это текстовое представление. А если быть точным - то это представление двадцатого века как и блок схемы.

Это статичное представление: его можно напечатать на бумаге, отсканировать волшебным сканером с нейросеткой и получить обратно свой код. Кисий язык нельзя распечатать на бумаге, его видимое представление зависит от того, что ты сейчас исследуешь. Лишнее отфильтровается. Ну правда, кто лопатил сырцы на 5к+ строк поймет в чем профит.

Расту надо выйти за рамки статичного представления чтоб стать 'убийцей с++". Ему надо... Например включить в себя конечные автоматы на уровне языка, принудительно вычисляемые величины(как в верилоге assign x=...) и поддержку диаграмм. Чтоб автомат был именно что наглядным. Это довольно малая модификация языка но я вам прямо скажу: если такое будет в расте, Раст начнет теснить и то нагибать плюсы

Тут наверно много людей, гамающих в игры, в частности в контры, fortnite, и т.д. Поведайте, если не жалко, как у вас забиндены клавиши.