Very exciting! I guess I'll have to wait for Django and Pydantic support to migrate to it on Zulip, but type checking was the last major linter that's still slow in Python.
I think most projects limit commit message titles to 68-72 characters, not 50, which is indeed too little to say much of anything. I don't find it hard to write 70-character summaries, and as a maintainer, I find it very useful to have those available for skimming.
When I do maintainer work that involves skimming a list of dozens of commits for information, it's very helpful to have concise commit titles.
I like that this tries to extract from the human the information that they didn't provide in their initial commit message.
So many tools go the direction of asking AI to generate a commit message for you, which will spend most of its space repeating in long form information available in the Git metadata, like the list of files changed.
And one can't really expect it to do a great job, if the information of "why did you change this?" wasn't available to it.
No. See the "Sponsorship and discounts" section on the pricing page, which makes clear the 10 users limit for free usage of the mobile notifications service is for workplace use, not communities.
What do you see as the gotchas with Zulip for community use? Zulip is 100% open-source, and we sponsor our hosted services (mobile notifications, etc.) free for OSS projects.
Hi ! So zulip is actually probably top of this list as the best self managed solution and I’m sorry if I conveyed that it was even near the same ballpark of some of the others. I actually think it’s pretty neat. Interestingly the thing that made us spin down our zulip instance after ten minutes was the “async conversations”. I understand this is a core differentiator for zulip but it immediately felt like the teams channel threading which none of us can stand. The intentions are noble, and the implementation is way better than teams, but it’s interesting to me that solutioning for preventing things from getting buried became the core UX philosophy at play. Really there is something that just works with an absolutely straight forward chronological list of chat messages used in conjunction with a capable search indexer. It’s not that we aren’t willing to try new paradigms, we have tried this paradigm. For a while now. Our topic’d channels are a ghost town these days, our entire org has just moved to making group chats in teams that serve as channels and pinning them because it’s just way easier to work together with regular chat. Ironically we fail to respond to things and struggle more to find things in a topic/threaded paradigm as it seems to go a little too far in isolating “noise”. A lot of serendipitous participation and aha moments and memes come from just glancing a chat discussion that might not immediately involve your attention, and we just operate way better in the open chat space needing only channels/members for the right amount of organization.
I also found the Zulip UX to be really confusing at first. The issue is messages show up in multiple places which is unintuitive for someone with a spacial brain like me. What I do (because I use Zulip every day) is read messages only in their threads. I click on one thread in the sidebar, get caught up, then move to the next thread. (This is also how I use Discord and Slack.) So I treat it as if channels contain threads which contain messages.
But Zulip’s default view is a list of all messages in all threads in all channels which has no context for the individual messages, like
Zulip's product lead here. Yep, reading messages thread by thread is the recommended way for most folks. (There's even a keyboard shortcut for going to the next one.) The inbox view, which lists the threads where you have unread messages, is the default home view (unless your org admins changed that setting).
The combined feed is helpful for some (e.g., in lower-traffic organizations, or if you like to see messages as they come in), and was the default home view many years ago.
Unfortunately, cyber attacks are an application that AI models should excel at. Mistakes that in normal software would be major problems will just have the impact of wasting resources, and it's often not that hard to directly verify whether it in fact succeeded.
Meanwhile, AI coding seems likely to have the impact of more security bugs being introduced in systems.
Maybe there's some story where everyone finds the security bugs with AI tools before the bad guys, but I'm not very optimistic about how this will work out...
There are an infinite number of ways to write insecure/broken software. The number of ways to write correct and secure software is finite and realistically tiny compared to the size of the problem space. Even AI tools don't stand a chance when looking at probabilities like that.
Poor quality, user-hostile experiences are a very common consequence of entrenched monopolies.
So many companies buy Microsoft regardless of the quality of the actual products. Given that context, why would directors invest in an expensive, invisible effort like controlling quality, when they could spend those resources on product launches that are naturally legible to upper management?
- The class of threat is interesting and worth taking seriously. I don't regret spending a few minutes thinking about it.
- The idea of specifically targeting people looking for Crypto jobs from sketchy companies for your crypto theft malware seems clever.
- The text is written by AI. The whole story is a bit weird, so it's plausible this is a made up story written by someone paid to market Cursor.
- The core claim, that using LLMs protect you from this class of threat seems flat wrong. For one thing, in the story, the person had to specifically ask the LLM about this specific risk. For another, a well-done attack of this form would (1) be tested against popular LLMs, (2) perhaps work by tricking Cursor and similar tools into installing the malware, without the user running anything themselves, or (3) Hide the shellcode in an `npm` dependency, so that the attack isn't even in the code available to the LLM until it's been installed, the payload delivered, and presumably the tracks of the attack hidden.
> be tested against popular LLMs, perhaps work by tricking Cursor and similar tools into installing the malware, without the user running anything themselves
My sense is that the attack isn't nearly as sophisticated as it looks, and the attackers out there aren't really thinking about things on this level — yet.
> Hide the shellcode in an `npm` dependency
It would have to be hidden specifically in a post-install script or similar. Which presumably isn't any harder, but.
They could have made it a setting, with an explanation of the security benefits of it, so that folks who are paranoid can take advantage of it.
A relevant threat scenario is when you're using your phone in a public place. Modern cameras are good enough to read your phone screen from a distance, and it seems totally realistic that a hacked airport camera could email/password/2FA combinations when people log into sites from the airport.
Ideally, you want the workflow to be that you can copy the secret code and paste it, without the code as a whole ever appearing on your screen.
