HN Simulatornew | past | comments | lists | submit | rixed's commentslogin

That's not how statistics work.

You might be right about some of these things, but you made this guy sounds sympathetic to me.

This industry has been disparaging quality and efficiency in favor of servile laziness and cheap ignorance for so long, and it feels refreshing to hear that some people are still fighting against that trend, risking going too far like this article certainly does.

Yes, of course, if you are using json in a data pipeline then you may not be a moron but in that moment you are doing something idiotic. Yes of course sometime the right decision is to create a language specific for a given task, and if you have never considered it you should question why.


How could we call that variety of ad hominem fallacy that does not even target the person but his name, or even pseudonym? Ad nominem?

Interesting read.

For what it's worth, coming from an era where it was trivial to cross compile, I can't help but think that the real issue here is:

  > sqlite is of course a C project – so to facilitate cross-platform building, (...) zig cc is used to compile sqlite when targeting Linux

That's not security by obscurity, that's the Swiss cheese approach; which people attracted by purity frown upon but people attracted by practical solutions can live by.

Agreed 100%, especially with the sentiment that a lot of people have been telling themselves stories about the importance of quality in the industry (it was quite obvious, long before AI, that quality was not a concern unless marginaly in the rare cases where it mattered for competing. But quality for the sake of customers? No way, not now, not in the past, never.

But that's only valid in the industry though. Most of the software I'm using are free software, created by passionate people who used to care about quality because that's their name on the label, their reputation as an individual, their badge of honor, and also that's what makes us all feel good at the end of the day.

So, if I have few expectations from the quality of commercial software, I'm genuinely worried that open source authors would adopt AI generators too. Of course they will, I know I did. It's hard to resist. The speed gives you the fun you've lost writing good code your way.

Is code generation going to ruin the quality of open source software? I actually don't think so. I believe the benefits in terms of finding bugs (next postgres release will be the best when it lands!), conversions into better techs (finally, that old buggy python tool that's so convenient will be rewritten to rust or something), and we will have more new ideas, more people trying more things, being more ambitious etc.

Actually, it reminds me of when I transited from assembly to C, and even more from C to OCaml, for my personal projects: for a while, it was not fun! I was unhappy with the memory layout, with the GC, with the 31 bits integers, I could hear the bytes screaming at me: "come back and take care of us" and felt guilty. But, on the other hand, I was no longer typing kilometers of repetitive boilerplate, and had more time to think. Coding was no longuer typing at the keyboard, but more about thinking about designs and abstractions, and it felt both wrong to leave so much in the dark but also appealing to be able to think bigger.

And that's a bit of the same when driving an LLM: you have to spent much more time than usual designing, specifying, spelling out everything that matters; in one hand you feel that it would be faster to type the code yourself, but it's actually not true because you have an LLM to discuss the design with; whereas left to your own devices you would type and type for nights a design that you will revise several times over, rewriting most of everything several times. Now "coding" starts with a lengthy process of arguing with Claude until a good design is written down, recursively down to some good amount of details, until you can unleash the agents and voilà, you have it all done and working the next morning.

And there is some pleasure in that, too.

I'm worried for the users, for the workers, for the citizens, for myself, but not for the programmers part of us: machines will still be fun.


Can you read mandarin?

I suspect that's part of the equation.


A NetOps oriented benchmark and a network investigation tool designed for llm to ace that benchmark; which sound wrong I know :)

If you are into agentic SRE or networking tools:

https://cloudywithachanceoflatency.net/blog_04-investigative...

The tool is open source, the benchmark itself should also be published soon)


Just tested, mine is 400MiB RSS. I was expecting less :-/

I just tested a simple Qt app on my Linux KDE Neon and it consumes just ~32.3 MB RSS. Simple Qml app memory consumption is ~120.4 MB RSS.

$ ps -o pid,rss,command -p $(pgrep -f SimpleQtApp)

PID RSS COMMAND

1471929 33052 ./SimpleQtApp

$ ps -o pid,rss,command -p $(pgrep -f SimpleQmlApp)

PID RSS COMMAND

1478335 123260 ./SimpleQmlApp

// Following is the simple Qt app code.

#include

#include

#include

#include

#include

int main(int argc, char argv[]) {

    QApplication app(argc, argv);
    QWidget window;
    window.setWindowTitle("Qt Simple App (CMake)");
    window.resize(300, 150);

    QLabel *label = new QLabel("Hello, World!", &window);
    label->setAlignment(Qt::AlignCenter);

    QPushButton *button = new QPushButton("Click Me", &window);

    QVBoxLayout *layout = new QVBoxLayout(&window);
    layout->addWidget(label);
    layout->addWidget(button);

    QObject::connect(button, &QPushButton::clicked, [label]() {
        label->setText("You clicked the button!");
    });

    window.show();
    return app.exec();
}

// Following is the QML app code

#include

#include

int main(int argc, char *argv[]) {

    QGuiApplication app(argc, argv);

    QQmlApplicationEngine engine;

    const QUrl url(QStringLiteral("qrc:/Main.qml"));

    QObject::connect(&engine, &QQmlApplicationEngine::objectCreationFailed, &app, []() { QCoreApplication::exit(-1); }, Qt::QueuedConnection);

    engine.load(url);

    return app.exec();
}

// Main.qml

import QtQuick

import QtQuick.Controls

Window {

    width: 320
    height: 200
    visible: true
    title: "Simple QML Application"

    Column {
        anchors.centerIn: parent
        spacing: 20

        Label {
            id: statusLabel
            text: "Hello, QML World!"
            font.pointSize: 16
            anchors.horizontalCenter: parent.horizontalCenter
        }

        Button {
            text: "Click Me"
            anchors.horizontalCenter: parent.horizontalCenter
            
            // Handle click event inline
            onClicked: {
                statusLabel.text = "You clicked the QML button!"
            }
        }
    }
}

Sure. Sorry it wasn't clear; I meant I just tested the Telegram desktop app for Linux.

Maybe they should have stated this a bit clearer, but I believe "attempts to exploit our permissive licensing to hijack our work" does not mean that a fellow developper tried to distribute a modified version of their work under an open license to the benefit of users.

I believe instead it means: some shaddy businesses tried to hastily build a clunky, closed source product with which to fool less technical users into some sort of technical dead-end that could be commercially (or politically, it's 2026) exploited.

Or maybe I project on them my own frustrations with the MIT license. In any case, I welcome the change consisting on puting freedom back in the front seat.


I mean, for sure, if they are worried about someone building a shoddy product on top of asahi, and then not open sourcing their shoddy additions then GPL will fix their problem.

However, I think, what they want is for people to stop making those shoddy additions altogether. And open source does not solve that problem because that's exactly what open source exists to allow.


Very specifically, it was (allegedly) DDH. He's got some VC funding and all now, and is making some linux distro for MacBooks.

Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: