alextingle

That's completely irrelevant. YouTube's advantage is its monopoly of user attention. If you want people to receive your message, no amount of money spent on alternative hosting infrastructure will help to get people to actually watch your video.

My point is that Telegram does the same things, but is much, much more polished.

If I reply to a message on Telegram, the original message is summarised and linked. Slack starts a weird new "thread" which hides the subsequent conversation in a difficult to access backwater.

If I want to edit a published message on Telegram, it's right there in the context menu. On Slack I have to do a complicated dance... hover over the message so that a hamburger menu appears, click on the menu, then click on the edit option. Click-drag just doesn't work.

If I want to search through message history on Telegram I click the search icon, type my search term and there are my search results. On Slack, again it's hidden behind a different hamburger menu. More click-click-click, and eventually I see my results, obscuring the current conversation! But not all of the results are there, apparently you have to pay for that.

Reactions are hidden behind a clunky hover-click-click interface.

...I could go on and on. It all kind of works, but it feels unfinished, like it's a prototype that's been bashed out in a weekend. Or it feels like a clunky web-app a-la Discord.

It's almost as though you didn't read the article.

Slack just seems so clunky to me, after years of using Telegram. Feels more like a knock-off Discord. Just me?

Is the question actually difficult, though? If you ask for some standard task, then of course those who are leaning heavily on LLMs will do well, as that's exactly where they work best. That doesn't tell you anything about the performance of those candidates in situations where the LLM won't help them.

I suppose, if you are specifically looking for coders to perform routine tasks, then you'll get what you need.

Of course, you could argue that ~90% of a programmer's work day is performing standard tasks, and even brilliant programmers who don't use LLMs will lose so much productivity that they are not worth hiring... Counterpoint: IMO, the amount of code you bash out in a given time bears no relation to your usefulness as a programmer. In fact, producing lots of code is often a problem.

Well, this one was much like the last one, and less interesting than the one before that. I'm pretty sure that if/when they manage a test that demonstrates a significant step forwards, then the interest will return.

> If we could just get off the tree-of-diffs model.

That's exactly what Git's innovation was, though. It doesn't work with patches or diffs, it works with (essentially) snapshots of the tree, and how they are related to each other.

You need the commit history, because that's the fundamental point of the VCS. Linux devs need to be able to demonstrate the provenance of each piece of code in the tree. That's the problem that git exists to solve.

> it was a bad, but performant copy of monotone's DVCS UI/UX.

I don't think the UI is what makes git, git. AFAIK Torvalds didn't put much thought into workflow or UI design - that evolved later. It's what goes on inside .git/ that's the innovative bit.

Git is the radically different architecture. Before it we had RCS, CVS, SVN, and a host of others that were simply striving to improve on the RCS model... a model that was simply unable to scale to large distributed projects with many collaborators.

Torvalds dreamed up Git in a weekend, and it's radically different from the patch-tree stuff that came before it. It's not taken over the world for no reason.

Did I miss that in the article, or did you just make it up?

I'm not sure I understand. What do you feel she did wrong?

Which bit of that is vitriol?

I'm really starting to like Perplexity. I was relating an anecdote about it earlier today.

I was trying to answer an obscure question about the meaning of something in Linux's /proc filesystem. Whatever I entered into DDG or Google, I just got hits where someone had posted a copy of the file into a forum post, so it hit all the search terms, but the discussion wasn't actually about my topic.

Perplexity understood the question, and answered it... dead wrong! But its fake "citation" links led directly to several pages where people really were discussing my topic, and they answered my question.

[the point] <-------------------------------------------------------> [you]

I don't think there's anything fundamentally wrong with the gig economy model - it's a way of working that suits some workers and clients. But the balance of power needs to be shifted towards the workers (and clients) and away from the platforms.

I think this article is spot on. Platforms obfuscate their algorithms, and use that secrecy to play workers off against each other, and against their clients. Regulation would really help. There ought to be a right to...

1. An official explanation for each decision the algorithm makes. That could then be used as the basis for mandatory arbitration, if a party believes it's unfair.

2. Effective, and timely support from a human being, if that's required.

Together those would force the platforms to make their systems fairer (else be swamped by dealing with arbitration decisions), and easy to navigate (else be swamped by costly support calls).

The EU have a policy of targeting specific US politicians' constituencies, with their retaliatory tariffs. I expect the Canadians will take a leaf out of their book. Should be fun to see who they decide to hit.

Thank you for posting that!

Precompiled headers are a terrible misfeature. I ban them in any code base I am responsible for.

They encourage the use of large header files that group unrelated concerns. In turn that makes small changes in header files produce massive, unnecessary rebuilds of zillions of object files.

The clean practice is to push down #includes into .c files, and to ruthlessly eliminate them if at all possible. That speeds up partial rebuilds enormously. And once you adopt that clean practice, pre-compiled headers yield no benefit anyway.

That is a fair comment.

There's no reason an allocator should ever trip over strict aliasing rules.

malloc() returns an address. The user code writes a value, and then reads a value of the same type. No problem.

Later, malloc() returns the same address. The user code writes a value of another type then reads a value of that same type. Again, no problem. There's no aliasing going on here.

The act of writing a value of a different type tells the compiler that the lifetime of the previous object has ended. There's no special magic required.

Strict aliasing is about situations where we write a value of one type, and then attempt to read a value of a different type from the same location. If you want to do that, then you have to be extremely cautious. But memory allocators don't do that, so it's not an issue.

(Obviously just talking about C here, or POD in C++ terms. If you are dealing with C++ objects with destructors, then you have an extra layer of complexity to deal with, but again that's nothing to do with aliasing.)

Why not just dump a core, rather than going to all that effort?

How does it avoid short-circuiting when the supply and exhaust vents are so close together?

There's lots of text on that web-site, but details of the actual design of the thing are pretty scant.

> this is absolutely possible by the laws of physics

Not with antimatter rockets, it's not. Even though antimatter is extremely energy dense, the rocket equation still applies. You need reaction mass.

If you use laser beams as your rocket exhaust, then you get maximal efficiency (exhaust velocity is C), but very low thrust. That's not going to get you anywhere in days or weeks.

If you use stored matter (hydrogen, say) as your rocket exhaust, then you'd get better thrust, but all sorts of other issues come into play. Radiating all that waste heat. Running out of reaction mass. Again, there's not a practical design that could get you anywhere near a nearby star in "days or weeks", even if you assume "perfect" materials, efficiency, etc.

> If you're on a ship with sufficient fuel, you can keep accelerating forever

Um, no.

Well I learned that the default memory ordering in a std::atomic<> is memory_order_seq_cst. That really surprised me. I had previously imagined that if I'd wanted memory barriers in addition to atomicity, then I'd have to ask for them.

Seems like a strange default to me. Obviously it helps out people who aren't really aware of the problem, but then... surely those people won't think to use an atomic operations library in the first place?

Ironically, this article reads like illegible AI-generated slop.

Are you saying that RAII is "new technology"??

Simply forcing the utilities people to properly repair roads after they have been dug up would be sufficient.

The UK riots were nothing to do with the murders that supposedly "triggered" them. That was all about hateful people seeking any excuse to punch down.

The fact that you try to defend those rioters by perpetuating their transparent lies says everything I need to know about you.

Have you talked to your "failing" team member about this? Have you worked together to try and identify a path towards improvement? Off the top of my head, perhaps they would benefit from more WFH time? Or perhaps a period of part-time work? Perhaps their duties could be shifted around so that they can contribute in a different way for a while? Could they take over some of your mentoring duties?

I mean, this is the bread and butter of your job as a manager, right? Getting the best out of your people?

> If you have an organization with forced bucketing where X% of your team need to be given a subpar rating, how do you decide which one?

Easy. You quit, and find a better job.

That practice is so toxic that it's sufficient to condemn the organisation as unworthy of any buy-in whatsoever. Just leave.

That whole approach is so disrespectful of users. If you are a serious business, then hire sufficient QA people, and empower them to do their job.

Expecting your customers to do your QA for you is super common these days. But that doesn't make it right.

(What really infuriates me is the general lack of feedback channels that enable users to actually contribute to QA. With open source software, end users can at least open a ticket on the bug tracker. If it's a commercial product, all too often the only point of contact is a disempowered call-centre worker, who can't even log a bug for you.)