3,222 karma · joined February 9, 2010
Folks who are thinking about these YC changes as a layoff are missing the point -- YC is exiting what had been a major part of their business (especially if measured by total dollars invested).
And from the outside it seems likely that the reason for the layoff is probably less that YC is in troubled financial straights and needs to cut costs on its operations, but because their late-stage investing business was losing money and YC has decided to give up on it and no longer has work for specialists in that work.
Ruff has essentially all the features of major Python linters (pyflakes, flake8, pylint, pycodestyle, autoflake, even isort), and it runs more than 100x faster than the fastest of them. In practice, this means this portion of our Python linting toolchain, which previously was a thing you had to wait for on a codebase of our size (or even when linting individual large files), now completes in under a second even when checking the entire codebase.
(It can't replace `black` or `mypy` yet, though the linked post describes plans to replace `black`, which I'm very excited about).
I can't recommend it enough.
But universities that are not in that top school range need to be communicating that the likely outcome for a PhD in their field is work in industry. There are a lot of industry jobs that involve reading research papers and doing research (with variation in whether you publish it), which are the key meta skills that a PhD is intended to teach.
But it's doing students a disservice for a school that's not in the top 10 schools in their field to market to students that they'll have a job exactly similar to their advisors'. It's certainly a possible outcome if you're unusually talented and have a good advisor who has a reputation in the field and work hard for decades and get lucky with how your research is received by the field! But it's an unlikely one, and one shouldn't plan one's life in a way where you're going to be really sad if you spend a few years getting a PhD at that school can't find an academic job.
Structurally, if the average professor graduates 10 students over the course of their career, half of which go to industry, then an institution with a given prestige level will send 5x as many graduates to academia as it has slots to hire professors.
So just from pure statistics, if everyone is trying to hire for new faculty jobs PhDs from the most prestigious institutions, one should expect the average PhD graduate who goes into academic to get a job at an institution about 5x less prestigious (one a percentage basis) as the one where they got their PhD. (Hiring is of course more complicated than that, but I think you don't need to make a lot of assumptions about the professor hiring process explain the data in the article).
It's not exactly a pyramid scheme design; there was significant growth in the total number of professor jobs, due to population growth and increasing college attendance rates. And in many fields, there exists high demand for PhDs for work in both industry and government research labs. But these statistics mean that only top schools have the option for a large portion of PhD graduates to get professorships... And I don't think there's any realistic reform that academia could make to change this reality.
https://github.com/zulip/python-zulip-api/tree/main/zulip/in... has a few bridges similar to what you're building that may be helpful references; the Zephyr one is the most sophisticated and the Matrix one is about to be rewritten (https://github.com/zulip/python-zulip-api/pull/765), so those may be useful resources.
See also https://zulip.com/integrations/ for native integrations that often provide a better experience, taking advantage of topics to thread notifications together nicely.
Can you provide a link to the 4-year-old GitHub issue you found? I'd like to clean it up to reference what has changed since then.
https://zulip.com/integrations/doc/slack_incoming
It probably deserves another pass on the documentation; it's been improved a few times since then and may no longer deserve the "beta" designation.
One of my personal goals for Zulip (https://github.com/zulip/zulip/#readme) is for it to be a teaching-quality codebase. This entails a lot of decisions about how Zulip is designed and how we as a community collaborate on it. But above all, it entails a focus on constantly trying to debug and fix barriers to new contributors joining the project, in addition to investing in things like readability, well-designed test suites, documentation for contributors, etc.
I'd look for those attributes in a project.
At Zulip, we’re out to build the world’s best collaboration platform, and we’re committed to keeping it 100% open source. Zulip is the only modern team chat app that is designed for both live and asynchronous conversations. Our product serves as the communication hub for businesses, open-source projects, educators and communities around the world.
We’re looking for a senior frontend engineer to join our small core team and help define the future of team chat. In this role, you will *work closely with Zulip’s product and design leads to drive work on a major initiative to redesign Zulip’s core surfaces.*
We are also hiring for other Engineering and Marketing roles. For full details on this role and other open positions, check out https://zulip.com/jobs/. Apply at jobs@zulip.com.
https://zulip.readthedocs.io/en/latest/subsystems/full-text-...
(It's only available when self-hosting at present.)
https://zulip.com/help/start-a-call
All of our supported providers support screensharing. Our philosophy on this is that having a nice integration with multiple dedicated video call providers is almost certainly going to be a better user experience than building our own video call stack.
In particular, a lot of preparatory refactoring towards supporting this has been merged over the last year, and we have a contributor planning to focus on this project over the summer.
https://github.com/zulip/zulip/issues/12309 is probably the right issue to follow for now. My plan for today included writing a much more technical version of that issue with a specific implementation plan, before someone submitted Zulip to Hacker News :).
I agree it's possible in theory to reuse the API key for end-to-end encryption, but I don't think that's the right design. This is in part because the encryption algorithm may, now or in the future, have different requirements for format, key size, etc. But more importantly, a cryptographic weakness in the encryption algorithm should not allow an attacker to stealing API keys.
It might be best to move this conversation to #backend in chat.zulip.org :).
The push notifications issue is important to me. I'm the one who opened #6954 five years ago, when we were first implementing mobile push notifications, and I've encouraged contributors to pick it up a number of times over the years. I appreciate your bringing attention to this -- it will likely make it easier for me to get folks excited about working on this mostly invisible improvement. https://news.ycombinator.com/item?id=31573940 elsewhere in today's thread has a bit more technical context for those who are curious.
As a bit of side comment, I think how long ago an issue was opened is not what makes it important. About 250/1650 of our open issues are at least 5 years old, and while some old issues are quite important, many of them are still open precisely because they are not important. So while I agree that #6954 is important, my view is that would still be the case if it had been added to the issue tracker yesterday.
I'll post a separate comment about end-to-end encryption of conversations, since that's a complex topic.
(I lead the Zulip project)
For security model reasons, those push notifications need to be sent to Google/Apple via a server operating by Zulip itself. So your local Zulip server needs to share a secret with the Zulip mobile app on your device, and then it can encrypt the push notification's content so that only the destination mobile app can read it (and the intermediaries cannot).
It's a basic cryptography problem at a high level, but there's subtle details around what metadata can be safely encrypted (the client does need to know which Zulip server's secret key to use!), backwards-compatibility, library choice, etc., that make it not trivial, which is why we haven't managed to implement this yet.
If anyone wants to help, I'd love links to privacy pages that folks really like and/or lists of questions that readers would like to see such a page clearly answer.
Our plan is to add end-to-end encryption for mobile push notifications, and we've got a design, but limited progress on implementation. One can follow the issue here: https://github.com/zulip/zulip/issues/6954.
I don't think I've heard of Gale, nor can I find it now that you mention the name... Which I guess is consistent with your "fell off the face of the Earth" theory. If you or anyone else can find a link, I'd love to read about it :).
We have always had a practice of prioritizing feedback and feature requests from open source communities, because improving the productivity of the global open source community is an important part of our mission as an organization.
One of the largest such investments has been the native public access option (no account required!) that we released earlier this month:
https://blog.zulip.com/2022/05/05/public-access-option/
(I lead the Zulip project)
I'd love it if you reported what you're experiencing in #frontend in chat.zulip.org. We'll want to collect a profile from your browser, so we can figure out why you're seeing choppy scrolling.
I think the most likely possibility is that they do have team members who look at perhaps some sample of conversations where they think it's likely that GPT-3 is not handling some input well, and use those as test cases for their team to debug and improve the model. If it's the case that the OpenAPI team working on GPT-3 has a way to make tactical adjustments (perhaps be extending their training data set in a way that their engineers expect to fix the bug), then I think them having a team that squashes bugs, especially those reported publicly, seems like a plausible explanation for bugs being fixed suspiciously soon after a user finds a good one.
In a normal software product designed to solve a problem that is imprecise/heuristic in nature (and with a privacy disclaimer/model that explicitly permits this sort of development), that'd be expected and great, and the only question would be whether one can make the problem-specific bug squashing work easy to scale (i.e. you don't want it to require a bunch of time from a machine learning expert to fix each bug). For many applications where one can imagine using something like GPT-3 as an input, it's not really a problem to have an error rate that can be reduced through investment as long as one can figure out a way to quantify those things and your application is one where an acceptable error rate is possible.
For GPT-3 in particular, they might not want to confirm this class of explanation, because they're marketing the technology as a little big magic.
If you'd like to summarize the upstream issue as "RabbitMQ as well as every distributors of it that we've investigated allows remote execution of arbitrary code on your server through having no effective access control mechanism for the distribution port, which is open by default after installing the software.", that summary is defensible.
That still sounds to me like a critical security issue. One should be very disappointed in a vendor that had not patched years after its public disclosure, especially given the context that we're apparently not first project using RabbitMQ to be affected by these security choices by Erlang and RabbitMQ. See, for example, https://nvd.nist.gov/vuln/detail/CVE-2018-1279, back in 2018. We definitely won't be the last, either.
I hope nobody is going to argue that it's reasonable to publish server software with a "documented" RCE vulnerability, especially if you don't make any effort to highlight that detail. https://www.rabbitmq.com/access-control.html, the main page about access control in RabbitMQ, does not even mention this security concern; you have to read their clustering guide, which should be irrelevant to anyone not intending to use RabbitMQ clustering.
The core bug there an insecure secret generation algorithm in upstream Erlang/RabbitMQ, which seems more broadly notable to me!
Despite our spending many hours composing detailed reports and lobbying security teams to get this problem fixed for everyone, not just Zulip, `apt install rabbitmq-server` continues to make a Debian/Ubuntu system vulnerable to RCE, and this fact has apparently been public for years.
We did manage to get `rabbitmq-server` fixed in Debian testing, and it is scheduled to be included in the next Debian stable release, I would really have thought an RCE issue like this would result in an immediate security advisory.
As a final remark, if you self-host Zulip, please subscribe to our announcements mailing list (https://groups.google.com/g/zulip-announce) and make sure your installation is up to date, so that you benefit from the hard work our security team does to keep Zulip users safe.
As a bit of commentary, my experience is that most SaaS vendors fix security bugs quietly. Others will do an brief internal investigation and only consider doing a public disclosure if they believe data privacy regulations require them to do so, because they discovered that the vulnerability had been in fact exploited. Usually public disclosure decisions are made by business executives with PR considerations in mind, so that shouldn't be surprising. See, for example, https://www.zdnet.com/article/slack-resets-passwords-for-1-o....
Zulip's core values include transparency, and our policy is to publicly disclose all security bugs that we discover with a formal CVE number, and this blog post is part of that practice. As noted in the blog post, we did an extensive audit and emailed every customer who our audit logs could not prove was not affected with enough detail to let them audit the situation. We did that despite our audit finding no evidence that this vulnerability was ever intentionally exploited, because we think it's the right thing to do.
Some technical detail I can add for those interested is that our postmortem plans following this incident include further investment in the internal audit log system used for the investigation (`RealmAuditLog`, if any readers feel like grepping our codebase). Improvements we made in mid-2020 were very helpful in investigating whether this bug had in fact been exploited, and we take this as a sign that we should increase investment in that system.
I'm sorry to hear you had a bad experience with Zulip. If you can share details on the UX problems you had, perhaps in https://zulip.com/development-community/ where we can have an extended conversation, I'd be very appreciative. I personally review every issue reported in zulip, and some of the specific problems you cite are not unfamiliar and surprising to me. Specifically:
* I'm not aware of a plausible explanation for Zulip frequently doing full reloads of the web view. Zulip's core design is to live-update everything [1] and there's only a handful of code paths that can trigger a full reload (the most common being when the server version was updated, and in that code path, the client has an algorithm where it waits up to 30 minutes for a moment when your window is idle and not focused to reload to get the updated version, to minimize the chance of disruption). * I'm also not sure what what state might be forgotten between web client restarts; almost all of our client UI updates happen via the client asking the server to change something, and the client updating via the same server-client push mechanism that updates other clients (the main exception to this is sending messages, where local echo is important for UX reasons). And at least the server-initiated reloads are designed to preserve your precise scroll position, compose box state, etc., and that's been true since ~2013. (Though we did fix a couple bugs where compose box state was not properly preserved in the last year).
I know you're not using Zulip currently, so your memory may be imprecise, but any additional detail that could help us reproduce what you experienced would be awesome!
[1] https://zulip.readthedocs.io/en/latest/subsystems/events-sys...