kookamamie

How does Zed fare for C++ development? Last I checked it did not support CMake as a build system.

Oh no, there are high-end desktops. You're right, laptops completely different profiles for these things.

> <tr :for="user of users">

I'm at a loss of words. Is this really seen as a good idea?

The naming scheme is horrible, to be quite frank.

To understand this, consider these names in the order of release time: Quadro RTX 6000, RTX A6000, RTX 6000 Ada, RTX Pro 6000, RTX Pro 6000 Max-Q.

Yeah, kind of. I have an 6000 Ada and 5090 here.

It's good to remember it's a marathon, not a sprint and that everything rots over time.

> NVIDIA RTX A6000

Unfortunately that's already behind the latest GPU by two generations. You'd have these after A6000: 6000 Ada, Pro 6000.

> The Python plaintext library

Then, goes on to present a convoluted node-based system for managing content. Why call it "plaintext" when it clearly has nothing to do with it? Perhaps describing it as some kind of a Markdown alternative, i.e. a markup-language would make more sense?

[flagged]

> You don't need very high resolution

Yes, you do. Also, 1024x1024 is not high resolution.

An example is segmenting basic 1920x1080 (FHD) video in 60 Hz formats.

We offloaded our memory to Google and then our writing to LLMs.

There's too much information in the World for it to matter, I think is the underlying reason.

As an example, most enterprise communication nears the levels of noise in its content.

So, why not let a machine generate this noise, instead?

I find it funny how the generation of content is now called ”server-side rendering” to make it sound cooler than what it actually is.

Exactly. Had to scroll for ages to find anything to do with demo audio. A good demo song/track should be the first thing on the page, I think.

I applaud this exercise in masochism!

This reminds me of Halide (https://halide-lang.org/).

In Halide, the concept was great, yet the problems in kernel development were moved to the side of "scheduling", i.e. determining tiling/vectorization/parallellization for the kernel runs.

Agreed completely. Most auto-vectorization approaches are hit-miss and you still cannot have big-binaries, where instruction set is decided dynamically, trivially.

ISPC comes close, but does come with a learning curve.

> 1. Compose the program into several threads of execution, traditionally scheduled and ran by the operating system

The step 0 is missing:

Compose the program into several lanes of execution, traditionally executed via SIMD.

This is a massive piece of performance left on the table on modern computer architectures, by assuming threading is the first manifestation of concurrency.

Looks like form-over-function to me. Cool looks, little content.

It's also very dangerous, I think. Grok is used on X to arbitrating ground-truth for topics I think it has no chance assessing.

Correct, it uses just numbers without any specific information about a colorspace being involved. Decoding and encoding sRGB happen during (texture) read and write stages.

Looks pretty nice. I think there'd be a way of computing the blurriness without the iterative approach and without the aliasing produced in the process.

> most surreal product screwups

It seems you're not aware of the issue which plagued tens of Cursor releases, where the software would auto-delete itself on updates.

It was pretty hilarious, to be honest. Your workflow would consist of always installing the editor before use.

The whole article reads like a complex mystery itself. Took a while to piece together what was even being investigated.

I find the blog funny for its disclaimer for the workstation specs.

> There is a heatsink on the SSD to help keep its temperature down.

Good to know!

Hypermedia. The what now?

The background is animating far too fast and is very noisy to look at. Win/Chrome/9950x3D/RTX5090.

It kind of is - although, with a twist.

I think most things done currently with the frontend "frameworks", could be achieved with standard HTML5+JS, without any "build steps" or other bloat involved.

This said, there is a case for building on a commonly used mature platform, such as React, to speed up the development cycle and in order not inventing the wheel again.

> In my opinion, most websites should be using htmx

In my opinion, in five years no one uses htmx, but another shiny toy. Hence, how about not starting to use it at all?

Yes, fully agreed. However, the way the companies currently approach this - catering for the ever-reducing niche, will end up killing the DLSRs over time. They just don't offer enough over phones, and the UX/SW being so crappy alienates the potential new userbase completely.

Yes, it's mind-bogglingly difficult and complicated.