424 karma · joined June 4, 2025
The 100m dash record is about an objective mesaureble property of the device, speed in this example. If we were talking, say, about inference speed, then yes, of course it's Claude who generated X tokens in Y seconds, not you.
Isn't a better analogy to ask if you drove a car completely on autopilot to some destination, then was it you who drove there or the car?
Also, for the record, I also don't like the AI-written publications. My concern is the consistency in using the terms. This is also related to the idea to not to antromorphize AI.
> – It was clear what had been done. The media player's cord had been ripped out and its own content had been played.
To me, it's more an act of vandalism than hacking.
– for observers on the road, make them more likely to film this and share on social media;
– for news agencies, make them allocate as much coverage as possible for this incident;
– for regular readers, simply to more likely grab theirs attention.
I'm the one who unknowingly published the link here, and I'm happy to cooperate. Looks like you can't flag your own publication for some reason.
Why? Loosing a good-working employee is a problem for the boss. Especially if the employee earned some trust and knows a lot of context about the workplace.
But why does it start to fill from an empty screen when opened? Shouldn't the news flow all the time like a river?
> Unit 42 reported earlier that we had observed post-compromise activity that we initially thought was related to the PHP2Shell vulnerabilities. What researchers saw was an attack against a European government agency executed in the context of a vulnerable PHP application. This led us to believe that it was exploitation of those vulnerabilities. We are unable to confirm that initial access is associated with the specific PHP2Shell CVEs. We have retracted our previous update from October 23.
This is exactly what I was missing
What I imagined is browsers rendering the content with headings, quotes, etc. Browsers could have some default styles to render MD files. Those styles could be configurable the same way “Reading mode” is usually configurable.
The plain unstyled rendering of strings of text is, of course, available even now. That's why I'm saying this needs a browser-level support.
> you only need a very simple script to convert md to plain html
I get, that it feels simple compared to other software. Even more, MD was designed specifically to be simple!
But if you think about it, this is still too much complexity to just share some text.
With native browser support, you could run zero commands to build a website.
I think this is mostly important for regular users, not developers. Imagine if creating a Word document would require the same level of complexity as building a web page: I doubt that the format would be so popular as it is nowadays.
Doesn't look like this to me.
The main point of the essay is that MD files should be supported on an OS level. This way, you could share an MD file with anybody, and it will “just work”.
You could develop your own viewer, but this will not solve the problem of “just working” for every user. Because most users wouldn't install some app just to open the file you shared with them. The same way you don't expect users to install any software to open websites, images or PDFs.
Of course, there are services that do that for you, ranging from Hugo to Obsidian Publish. But they all add a level of complexity that you have to manage.
Also, this makes user-level styling much simpler. This is what any “Reading mode” does, but without reverse-engineering the content from a soup of tags and classes.
I've struggled with the same problem, and Coolify helped me with it. It supports auto-deployment from GitHub via a bot integration, so you don't have to manage Github Actions. It can also deploy from a Docker Compose file, which is good for self-hosting other people's projects.
Of course you still have to have a list of instructions on how to set up your server with Coolify. But at least it's a finite set of instructions, meaning you don't have to update it every time you host a new project.
Isn't this the point of Pi to implement all the features you need yourself? Complaining about lack of features in Pi doesn't make sense to me, it's their whole identity.
Although I must say that describing specific problems is valuable on its own. It's just (a) why stop there and (b) if stop there, why shape it as a complaint and not as a list of features that are worth discussing.
> As it tends to be heavily trafficked, the overall bandwidth is a key consideration
I guess this is also done to prevent bad actors from abusing the fact that this domain is hit by people who might not know what they're doing (the ones copy-pasting code without reading it)
> No one rewatches a team meeting from 3 years ago to remember constraints around a feature. People write things down and use those records instead.
Memory plugins don't re-read old transcripts. Memory snippets are basically the notes that people write down after the meeting.
The problem, however, is different. The problem with memory plugins is that your agent basically writes a note every time someone says a sentence, and then tries to work with those 5000 notes.
Instead, the agent should recognize what's important and write only that. And that is, of course, a documentation. (And ADRs, if you want not only a description of the final state, but also the trajectory of how the agent arrived to it. Which, arguably, contains more information than the docs themsleves.)
Another difference is that memory snippets are immutable, append-only and don't have a lot of structure. Of course, this is done to be able to store lots and lots of notes: they should be independent. The main problem is that increasing the number of notes adds not enough benefits to compensate for downsides of this structure-less immutable format.