alexvitkov

Every week we get a new AI that according to the AI-goodness-benchmarks is 20% better than the old AI, yet the utility of these latest SOTA models is only marginally higher than the first ChatGPT version released to the public a few years back.

These things have the reasoning skills of a toddler, yet we keep fine-tuning their writing style to be more and more authoritative - this one is only missing the font and color scheme, other than that the output formatted exactly like a research paper.

This would be acceptable if it meant adding one more shader, but with "modern" graphics APIs forcing us to sometimes have thousands of permutations for the same shader, every variant you add multiplies that count by 2x.

We also don't have an infinite amount of time to work on each shader. You profile on the hardware you care about, and if the choice you've made is slower on some imaginary future processor, so be it - hopefully that processor is faster enough that this doesn't matter.

> OH, trust me - corporate environments are not at all conducive to making sure bugs get fixed for Womperloo 11.4 users.

That's true, but Meta+Shift+F11 will usually be fixed if it breaks on Windows, and ironically will very likely work Womperloo 11.4 as well, because Wine basically runs all Windows software that doesn't make it an explicit goal not to run under Wine perfectly.

> Linus Torvalds is not going to sit idly by while an update is shipped out that breaks Womperloo, I'll tell you that.

Linux is a great example - it's the most arguably the most successful FOSS project, and that's no small part due to the fact that Linus, as well as a ton of other programmers get paid a lot of money to work on it.

A scary amount of critical FOSS projects are just some guy's hobby, and a hobbyist will often work on problems they find interesting, regardless of whether or not they're important for the "community".

If you're coming home from work and have one hour of free time, do you really want to spend it investigating why a Meta+Shift+F11 doesn't work in your program under Wayland on Womperloo Linux 11.4?

That's the #1 reason why people need to be paid to work on important software. In a corporate environment (with somewhat reasonable management) boring but important work will land in someone's Jira ticket and they'll be paid to get it done.

Unfortunately our CEO at a 5000 person company that heavily uses Slack, still hasn't activated their Slack account, so I don't have much to finetune the bot on.

It's not the only technical control they have - every single datapoint an app can gather is ultimately provided from the OS. They could let you disable access to metrics that have proven to be useful for fingerprinting. They could also attempt block known tracking code - all games with IronSource ads will run the same tracker binary, byte for byte. There's a lot of things they could do, but don't, since in the mainstream they have a pretty good reputation when it comes to privacy.

Alright, just give me 5 minutes to quickly inspect the likely over 100,000,000 lines of code that either go directly into a ROM or are part of the build tooling, and reverse engineer however many binary blobs are involved in the process.

The "you can just read the code" mindset is completely unrealistic, even for software that's orders of magnitudes smaller. If the issue at hand is entering my Google password, I'd rather do it in a ROM built by Google.

Fair point, but I highly doubt that this is how it's used most of the time. And taking 20 screenshots and compositing them in mspaint can be a meditative experience.

I'm glad the writer is enjoying Firefox, but posts like these make me realize we've forgotten how to use computers.

Built-in screenshot tool? "You don't need to install extensions"! Really? Dude just press Print Screen, it even works outside a browser, if one day you have to be put through the unspeakable torture of using a native application! Single-use burner emails are also nice and all, but why exactly does this have to be linked to my browser?

Of course switching browsers it's gonna be a big deal, when you actively walk out of your way to lock yourself to your browser's "ecosystem", but better Mozilla than Google I guess.

If that's what the license says, fair enough, but that's not how I parsed it. This is not a software-specific license so it's not as clear as say the GPL, where there's very explicit language for source code, object code, compilation, execution, distribution, ...

Here's an excerpt from the license:

    - 1. Subject to the terms and conditions of this Public
         License, the Licensor hereby grants You a worldwide,
         royalty-free, non-sublicensable, non-exclusive, irrevocable
         license to exercise the Licensed Rights in the Licensed
         Material to:
      - A. reproduce and Share the Licensed Material, in whole
        or in part, for NonCommercial purposes only; and
      - B. produce, reproduce, and Share Adapted Material for
        NonCommercial purposes only.

I don't understand what I'm reading in the slightest, I wouldn't touch this with a ten foot pole.

I can "produce", "reproduce" and "share" the licensed material. I'm definitely not sharing it, so if "running the code" is allowed at all, it must fall under the "produce" or "reproduce" categories. The text is pretty clear that you can only "produce" and "reproduce" it for NonCommercial purposes as well, so what does that leave me with?

How exactly do you use what looks like work-planning software non-commerically?

As for the license, it's their code and they can release it under whatever license they want, but they obviously shouldn't call it open source. Usually companies do this sort of thing to take advantage FOSS's reputation, but in this case it just looks like ignorance to me.

Reasoning about the lifetimes of objects in an arena is as simple as it gets - there's only one lifetime, and pointers between everything allocated on the arena are perfectly safe. The complexity of figuring out what's going on, with with respect to the number of objects and links between is O(1).

There's no universal "God pattern" that you can throw at every problem. I used arenas as an example as I didn't want to write a zero-substance "OOP bad" post, but my point wasn't that instead of always using OOP+inheritance you should always use an arena, it was that if you think about your memory, more often than not there's a vastly superior layout than a bunch of heap objects glued together by prayers and smart pointers.

> Otherwise, one would just declare a structure member of the class from which one would inherit in the OOP style and a virtual function table pointer, and one could write an identical program with the OOP program, but in a much more verbose way.

No, you don't have to do that. Once you start thinking about memory and manually managing it, it you'll figure out there's simpler, better ways to structure your program, rather than having a deep class hierarchy with a gazillion heap-allocated objects, each with distinct lifetime, all pointing at each other.

Here's a trivial example. Say you're writing a JSON parser - if you approach it with an OOP mindset, you would probably make a JSONValue class, maybe subclass it with JSONNumber/String/Object/Array. You would walk over the input string and heap allocate JSONValues as you go. The problems with this are:

    1. Each allocation can be very slow as it can enter the kernel
    2. Each allocation is a possible failure point, so the number of failure points scales linearly with input size.
    3. When you free the structure, you must walk over the entire tree and free each obejct one by one.
    4. The output of this function is suboptimal as the memory allocator can return values that are far away in memory.

There's an alternate approach that solves all these problems. If you're thinking about the lifetimes of your data, you would notice that this entire data structure is used and discarded at once, so you allocate a single big buffer for all the nodes. You keep a pointer to the head of that buffer, and when you need a new node, you stick it in there and advance the pointer by its size. When you're done you return the first node, which also happens to be the start of the buffer.

Now you have a single point of failure - the buffer allocation, your program is way faster, you only need to free one thing when you're done, and your values are tightly packed in memory, so whatever is using its output will be faster as well. You've spent just a little time thinking about memory and now you have a vastly superior program in every single aspect, and you're happy.

You should never write code that's impossible to understand without fancy IDE features. If you're writing such code, the best thing you can do for yourself long term is switch to a text editor without LSP (read Notepad) right now, which will force you to start writing sane code.

This is true for any language, but it's especially true for C++, where most large codebases have tons of invisible code flying around - implicit casts, weird overloads, destructors, all of these possibly virtual calls, possibly over type-erased objects accessed accessed via smart pointers, possibly over many threads - if you want to stand any chance of even beginning to reason about all that you NEED to see the actual, concrete, scientific types of things.

We've forgotten how to do it - the idea of dragging a button offends our modern sensibilities. You can't just drag a button, what about the layout?! What about responsive design, how will it look on a 300x200 screen and a 8k one? What about scaling? Reactivity?

You can use modern MSVC or Clang with an old C runtime/Windows SDK. It's a pain in the ass since new compilers are way stricter with what they compile, so you get a bunch of warnings, but it will work.

Love the entity init->use->yeet cycle. Fantastic terminology, may steal it.

  void Entity::Yeet() {
      yeetery.push_back(this);

It doesn't matter how many layers of Python you use to obfuscate what a LLM actually is, as long as the prompt and the data you're operating on are part of the same token stream, prompt injection will exist in one form or another.

Glad to know I was a world class engineer at the age of 8, when all I knew were the <h1> and <b> tags!

My biggest problem with node-based programming interfaces is the absurd number of nodes required for even fairly simple expressions, e.g `b*b-4*a*c` is 9 characters in most textual languages, but it would require 9 nodes in most visual scripting systems.

I imagine you could have an arbitrary "expression" node with N inputs and a textfield, but I've never seen it done and it still feels like a bigger hassle than punching out the expression in a textual language.

He mentioned in the article that the corruption happens at a seemingly random spot the middle of a large buffer, and you can only have a HW breakpoint on 4 addresses in x86-64.

> The project was quite big (although far from the largest ones); it took 40 minutes to build on my machine.

A bit tangential, but I've been crying about the insane Unity project build times for years now, and about how they've taken zero steps to fix them and are instead trying their hardest to sell you cloud builds. Glad to see them having to suffer through what they're inflicting on us for once!

Regardless, very good writeup, and yet another reason to never ever under any conditions use exceptions.

This is not an unpopular opinion you needed to make a new account for. None of us do.

While I wholeheartedly agree with the premise, the article doesn't really say anything other than "TCP good, your abstraction bad, don't use abstraction".

Doing frees/moves/copies on the second stack makes it harder to track the lifetime of allocations, and restricts what you can use it for - to free a block on the stack you necessarily have to free everything after it.

Most programs have a point where you know nothing on it is used and it's convenient (and very performant) to free the entire thing, and that makes it way easier to reason about - when you alloc from it you know your block of memory it's valid until a <RESET> point:

  - For a video game you can <RESET> at the start of every frame
  - For a web server you can alloc a new stack for every incoming request and <RESET> after the request is over
  - For a short-lived program you may not even need to <RESET> at all

You don't need explicit language support to do this -- it's a fairly common practice in videogame development, but we usually usually call it an arena/scratch buffer. Ryan Fleury has a wonderful article where goes at length about different memory management strategies [1].

It's just a static buffer that you can use for temporary allocations, e.g. to return an array of 50 int32's to a parent stack frame you can just allocate `50*sizeof(int32)` bytes on that buffer and return a pointer to the beginning, instead of a heap-allocated `std::vector<int32>`. Every allocation advances the head of the buffer, so you can have multiple allocations alive at the same time.

Every once in a while you need to free the buffer, which just means resetting its head back to the start - in the case of games the beginning of a new frame is a convenient point to do that.

This doesn't solve dynamic memory in general, as it can't be used for long-lived allocations, it just saves you a bunch of temporary heap allocations. It doesn't solve all problems that RAII does either, as RAII is often used for resources other than memory - files, sockets, locks, ...

[1] https://www.rfleury.com/p/untangling-lifetimes-the-arena-all...

  char path[100];
  snprintf(path, sizeof(path), "/proc/%d", pid);

You're assuming the pid will fit in 93 bytes! The exact same mistake as `char pid[5];`

Jokes aside, sometimes userspace deserves to be broken, and `char pid[5]` is IMO one of those cases. The fact that we treat integers as a scarce reusable resource is bad, and the fact that we now have a second-order process identifier to cover that up is worse.

Vulnerabilities are related to the web being complex, and just this one quirk involves a parsing algorithm with 6 transformations of a user-provided value.

> or to block symbol characters in names.

People tend to very very quickly their mind on that one once they get a few right-to-left control characters that flip over the text layout of the entire program.

This really doesn't add up to me. I don't have the numbers, but I would assume that:

1. A very small percentage of website visitors will end up paying for a subscription.

2. They make way less than $5 per user per month from ads.

The money they'd lose by providing an ad-free experience to paying customers should be a rounding error. Removing ads will also increase conversion, but who knows whether or not that will be enough to offset the revenue lost.

I don't particularly care about their "business reality" - if you're an online news outlet you're not paying the costs of printing and distribution - your expenses are just journalist salaries and the marginal costs of keeping a website running. If you need to charge anything close to $5 per user per day to keep such an operation running, you should be out of business.