Threads for alynpost

  1. 2

    I received a bill from Prgmr a few days ago, and confirmation of payment to TornadoVPS today. I can’t say the lack of a notification is comforting.

    Apparently we have the rest of this month to fix references to in configurations and DNS.

    1. 2

      I appreciate your forbearance over the deadline. If you find yourself needing more time, reach out to and I’ll forward the request to retain your DNS entries.

      1. 1

        Oh! Was not expecting a reply of this sort. Thank you. I’m just griping.

        Your announcement email got caught by gmail’s spam filter for me. I’ve marked it “not spam”, but I wonder if other customers had a similar issue.

        1. 1

          I did, too.

    1. 2

      I’m kind of annoyed with how rapidly this has been rolled out, personally. I would’ve preferred a few months notice, instead of ‘a few days’.

      1. 3

        I would rather have given more notice myself. If you find yourself needing more time, reach out to and I’ll forward the request to retain your DNS entries.

        1. 1

          What’s the reason for the rush? Is Luke getting tetchy about the domain or something?

        1. 2

          These aren’t exactly the same post. this one is though.

          1. 1

            @alynpost could you please merge these two?

            1. 3

              Thank you for bringing this to my attention @raymii. I agree with you that given the proximity of submitting story d6cytn and story z7floj that they should be merged. Despite being different articles (published on March 6th and December 22nd of this year respectively) they both discuss the same build and are therefor the same topic.

              h/t to @jmtd finding the original submission of the article for story d6cytn, story eflawq. That story is outside the merge window, having been posted 9 months ago.

            1. 2

              I have merged stories mnpjst and bqw8wv in to story jb8fpk. Thank you for keeping track of them.

            1. 23

              The story’s catching a lot of “off-topic” flags. I mostly left it up so there’s a single story people can click “hide” on because it’s clear we’re going to see this a dozen times in the next few days as news trickles out. Also, when this story was posted yesterday it wasn’t clear this was a social engineering rather than a zero-day, and we do consider those topical.

              Years ago we removed the ‘news’ tag. Still today, lot of ‘security’ stories are news because they’re about new vulnerabilities. This feeds back into my concern about the recurring idea to remove the culture/practices/etc tags. With a week to reflect on my response there, I think it boils down to: any time we decide to restrict topicality we amplify two problems.

              First, there are Big Event stories like this one that seem worth leaving up. Call it the “heckler’s promo”, because it’s the inverse of the heckler’s veto. A story effects the entire industry and will be submitted over and over, so we make an exception. We can bite the bullet and stop making exceptions, but we know submitters and some number of readers will be outraged at the removal of stories that feel so important in the moment or are so highly emotionally charged. This very often results in angry tweets and PMs to mods about how we’re removing stories to enforce our opinions about politics and business. Having evil motives endlessly imputed to us is personally draining, and more generally not great for the site’s reputation, so that’s why I harp on the need to be able to point to a clear, public standard such that even someone who is angry at having their story or comment removed can accept that it fell within the bounds. The other benefit of drawing a bright line is that it reduces moderator discretion, power, and potential mistakes. (Edit to add sentence:) The more clearly we can draw lines, the more confident users can be that they’re contributing well and getting treated fairly.

              Second, and much harder, stories often touch on multiple topics and it’s not clear where to say that it has so much of the tagged topic that it should be removed on that grounds. When it’s most of the story? Half? One sentence? Implied by popular knowledge about the topic? When it’s likely to prompt a rehash of a contentious topic? We give ‘security’ a pretty wide leeway on ‘news’ but entrepreneurship and business almost none. This problem benefits from having a bright-line rule for all the same reasons as the previous, and because people assume our definition of topicality is the same as other, more popular sites like r/programming and Hacker News. (And: we’ve gotten a lot of off-topic business stories in the last week or so, I don’t know what’s up with the spike.)

              Hope this helps explain why things look the way they do and is a useful framework for future changes.

              1. 2

                What about bringing about a off-topic or unrelated or breaking-news or squirrel tag for all these types of articles that people love to submit but don’t really fit? Too problematic in that it encourages people to submit them?

                Just wondering how people that want to bring up stories like this and enable those of us that couldn’t be bothered to care can both be appeased. Might remove some of those angry pm’s and tweets if you just go, moved this story to the spam category. Ooh there call it spam as the label. >.<

                1. 5

                  Something like this gets proposed every couple months. I don’t see any reason it would fix anything; the discussion would only shift terms slightly from “why’d you delete this” to “why did you give it the tag of shame” with the same open questions about when to apply it, plus the comments there would show up on /comments, topics would spill over into other threads, etc. Maybe someone wants to take a page from the chat room playbook and run their own site with different rules that are closer to but still broader than Lobsters itself.

                  1. 1

                    It might encourage more submissions, but at least an ‘offtopic’ tag could be hidden by users and incur a hotness penalty.

                  2. 1


                    But why did @alynpost merge the twitter stuff with the cloudflare outage ?! that’s completely unrelated..

                    1. 3

                      I did accidentally conflate story submissions xbl6uc and uptmet and merging them was incorrect. It’s undone.

                      1. 1

                        Thanks :)

                  1. 5

                    Link is broken for me. Working version of the link. I don’t know how to suggest an edit - is a mod able to edit the link?

                    1. 1

                      thank you. Yes, this is my fault. I pasted same URL twice. Now I cannot edit the URL in the submission, so would appreciate if mods could correct


                      1. 1

                        @pushcx , @irene, @alynpost can some one fix the link! Cheers

                        1. 2

                          I’ve removed the accidental duplicate paste of the story URL. Thank you for bringing in to our attention and thank you @NotQuiteAnon for reporting the issue.

                    1. 2

                      There’s nothing there which isn’t covered by the official openbsd documentation.

                      1. 13

                        This blog post is the result of a customer reaching out to us due to installing OpenBSD with full disk encryption but being unable to get a password prompt on the serial console. They reached out after following the instructions provided in the OpenBSD FAQ but were unable to make them work.

                        We went through a handful of other published articles but didn’t find anything that directly covered this scenario, and so wrote these instructions to pull them through installing OpenBSD on their VPS.

                        If this scenario is in the official documentation they couldn’t find it or we didn’t understand it.

                        1. -1

                          boot(8) covers enabling serial on bootloader. It’s even one of the examples given below. Which is all you’d need, as passphrase input is done with the bootloader.

                          Thus the tutorial is just a form of spoonfeeding, and IMHO does not belong here.

                          1. 13

                            boot(8) covers enabling serial on bootloader.

                            And pray tell why would a new user know exactly where to go for serial on the boot loader?

                            Thus the tutorial is just a form of spoonfeeding, and IMHO does not belong here.

                            Elitism like that is what makes the BSD communities so unwelcoming and self-isolating. To contrast, DragonFly keeps tutorials for interesting tasks, like userspace drive mirroring in Hammer. I was able to get started because of tutorials like that - I had a goal to build a NAS and one of their tutorials helped me accomplish my goal. I also would give a shout out to the FreeBSD handbook which was more project/task oriented and quite helpful for new users to learn how all these parts fit together.

                            1. 2

                              And pray tell why would a new user know exactly where to go for serial on the boot loader?

                              Why would they know about a random article online to help them? How do they know it’s up to date? If the system documentation is insufficient, that is a bug.

                              1. 7

                                Usually someone in that situation Google’s their exact situation and first tries the official docs followed by unofficial ones.

                                Also, yeah, I agree the system documentation is insufficient. Unfortunately, when you have enough people with the attitude of “well I understand it, don’t spoonfeed it”, you get a dampening impulse to under document it.

                                “Spoonfeeding” is dog whistling for “I don’t want those dirty common folk who are so stupid”. And that attitude is toxic. Everyone has to start from a position of ignorance. Being kind and open to such is an exercise in patience. Patience makes a community better for all of us. After all, life is short.

                                1. 9

                                  Good comment.

                                  Everyone has to start from a position of ignorance.

                                  One of the things I do is stand up and maintain services (infrastructure) for software teams. A significant portion of which is teaching people how to use the tools–integrating them with their own workflow and habits. After you work with enough people, it becomes pretty clear how different they are when they approach problems or try to understand something.

                                  Almost everyone gets stuck (needs help, has a question) somewhere. Where a person gets stuck comes down to their subjective experience and tends to be particular to them. I get asked what I consider insightful questions–questions that demonstrate the asker understands and is testing their knowledge. I get asked what I consider basic (simple) questions–those that make me wonder how they managed to understand anything else. In all cases I answer the question in the straightforward manner of trying to inform. The way I understand something is not the way other people do, and my evaluation of the quality of a question has no bearing on whether the answer is helpful to the asker or the audience.

                                  In the obverse I do the same–I’ll ask a series of questions where I 1) know the answer, for sure. 2) believe I know the answer but am not sure, 3) have no idea what the answer is. Asking simple (basic) questions helps me confirm that the answers to my other questions are correspondent.

                                  Sometimes a question really is a test of the limits of your own competence, and almost always the asker wants to benefit from your understanding without the level of study (investment) you’ve made. They are working on their own problems, applying their own knowledge, working with many other specialists on a solution that none of you would accomplish alone.

                                  It’s not “spoon feeding” to condense what you know in to a solution.

                                  1. 2

                                    “Spoonfeeding” is dog whistling for “I don’t want those dirty common folk who are so stupid”. And that attitude is toxic.

                                    This was absolutely not the intent of my words. I do not appreciate my words being twisted this far to paint me as something I am not nor do I try to be.

                                    That’s openly hostile, and I find it ironic if anything that you’re calling me toxic, despite.

                                    1. 3

                                      Agreed. Calling someone’s comments a dog whistle so you can attack what you claim they said rather than what they actually said is itself a form of toxicity.

                                    2. 1

                                      Also, yeah, I agree the system documentation is insufficient. Unfortunately, when you have enough people with the attitude of “well I understand it, don’t spoonfeed it”, you get a dampening impulse to under document it.

                                      If you look at the commit list, you’ll see that a huge portion of the commits are purely documentation improvements. I’ve also seen features rejected because they made it harder to write documentation.

                                      If there’s a dampening effect, it doesn’t seem to be very strong.

                                  2. 2

                                    Elitism like that is what makes the BSD communities so unwelcoming and self-isolating.

                                    Good documentation makes them welcoming and not self-isolating at all. This is in contrast with Linux and its poor documentation (save perhaps Gentoo and Arch’s respective wiki sites, which is in no small part why I favor these distributions).

                                    I was able to figure out how to configure the bootloader. Why would I not expect everybody else to be? The starting point was the same: Not having a clue about openbsd, just enough to decide to try it out. Everybody starts there.

                                    why would a new user know exactly where to go for serial on the boot loader?

                                    Assuming that checking boot(8) is not obvious for bootloader configuration, I would try a web search. I just tried this, on the most popular web search engine, for “openbsd bootloader”. The first result is boot(8).

                                    Seriously, why do you think it is a good idea to spoonfeed that which is so easy to find?

                                    Furthermore, If enough people get stuck there, isn’t the correct response to try and improve the documentation itself? It certainly is a much better approach than writing a tutorial.

                                    Openbsd is an open source project. It takes patches, bug reports, suggestions. Documentation can be improved to cover this, so can code: The installer could be made to handle all of this.

                                    1. 1

                                      prgmr isn’t itself BSD project, and they have no particular obligation to try to improve the official documentation of any particular BSD project, rather than just writing their own blog post (although there’s certainly nothing wrong with trying to upstream a documentation patch - I’ve never done this myself and have no idea how easy or hard any given BSD makes this). In any case, I do think there’s value in users of software writing their own blog posts about their experiences with it, that need not be “documentation” in any official sense. (And I’ll say that I got the idea to use a FreeNAS virtual machine to manage those drives from user experience blog posts much like this one, rather than FreeNAS’s official documentation! I wouldn’t have even known that FreeNAS was a piece of software that might solve my problem without such blogs.)

                                      I’ve only recently began using a BSD, in the guise of a FreeNAS virtual machine that I have managing some hard drives. I personally had no trouble installing it or using its web GUI to set up encrypted storage, and it’s been working perfectly fine for me so far. But I’m aware in the back of my mind that I’m not familiar with the command-line tools for managing BSD encryption, and I may need to know how to use them to debug this setup someday. So even though I’m not currently installing BSD on anything, this blog post is still potentially useful to me for gaining a better understanding of a system I already use.

                                  3. 7

                                    With an encrypted /etc, the bootloader can’t read from /etc/boot.conf to know to use the serial console. The novelty here is not booting from the serial console, but how to make an encrypted root and serial console work together.

                                    As of a few years ago it was not supposed to be possible to have only the one file /etc/boot.conf be on an unencrypted partition: We didn’t find any documentation noting that had changed.

                                    1. -2

                                      This issue (and the workaround) is self-evident once you understand how it all works together, which is the result of reading the documentation.

                                      I don’t see why anyone would need to be spoonfeed to this degree.

                                      Every time I do install an openbsd I do not like that the installer doesn’t itself handle encryption. I do hope it will at some point. But all it takes is a short visit to the shell; This is much better than the netbsd situation.

                                      Openbsd is an open source project. It takes patches, bug reports, suggestions. Documentation can be improved to cover this, so can code: The installer could be made to handle all of this.

                                      This is a much better approach than writing a tutorial.

                                      1. 5

                                        Just because you understand it doesn’t mean that others understand it. Using Thought terminating cliches like “Spoon feeding” only serves to paint a user who doesn’t have your wonderful understanding as defective and wrong, which is unnecessary and cruel.

                                        Also, “file a bug and do extra work in my exacting standards” is a pretty entitled attitude. You could very well just shrug and move on or go “hmm, I like OpenBSD and maybe, just maybe, there’s a disconnect in the documentation that will make it easier for all of us?”

                                        If you want OpenBSD to remain on the sidelines and hostile to everyone but perfect people like you, keep it up - your attitude is perfect for that.

                                        And yeah, I’ve encountered this before. The only reason why Linux is more successful is enough like-minded people of a professional demeanor have made multiple distros, websites, wikis, etc - all which have no issue with “spoon feeding” because attitudes like that get you fired.

                                        1. -1

                                          “hmm, I like OpenBSD and maybe, just maybe, there’s a disconnect in the documentation that will make it easier for all of us?”

                                          I covered this case in my comment. File a bug and/or a patch; get the documentation fixed, or improve the installer so that documentation isn’t needed in the first place.

                                          But maybe that isn’t as convenient as placing a howto on a personal website and hoping the documentation does never get fixed, so as to maximize the traffic?

                                          1. 7

                                            Here is the best I can do right now, based on the notes at the bottom of


                                            We have a history of reporting bugs upstream even when we’ve found a local workaround. In this case, frankly it did not occur to me to make a change request for the FAQ, and I’m not sure why. So thank you for that suggestion.

                                            Regardless of whether our information is incorporated into the FAQ, I think it’s valid to additionally do a blog post for the following reasons:

                                            • Changes to FAQ items are generally not push notifications. I could be wrong but I don’t see any way to subscribe to updates to .
                                            • Let’s hypothesize that the maintainers of the FAQ either 1. are overworked (likely) so there’s a delay in publishing the information or 2. do not believe, like you, that this is novel information worthy of going in the FAQ. At least then we’ve done our best to share our work.
                                            • The blog post has better formatting than plain text, and it would be unreasonable to expect someone to enable HTML when reading email.
                                            1. 2

                                              Well done re: sending email to openbsd-misc.

                                              Let’s hope they take it seriously.

                                    2. 6

                                      This is the very attitude that made me drop OpenBSD after I encountered some problems, and the community was unwelcoming at helping me.

                                      You are not nice guys, and while OpenBSD has many nice aspects, it is not that good that it outweighs this attitude. I don’t mean that the obsd community is mean, just too self-important.

                                      Also the docs are pretty nice, but not completely flawless, complete, or up to date. At least not discoverable and interlinked enough to dismiss such writeups. (Much because of the old technologies used).

                                      Also the filesystem layer, and the (not so) “full disk” encryption experience was underwhelming for me. The trunk network driver is what I really miss in other systems, that is the most simple and elegant stuff I admire the most in OpenBSD.

                                      1. 2

                                        the community was unwelcoming

                                        I found the openbsd community to be extremely accommodating and have a lot of patience with useless people such as me.

                                        (not so) “full disk” encryption experience

                                        Now, I am curious. Can you elaborate on what if anything is missing from the disk encryption support? What are you comparing it with, if anything?

                                        1. 3

                                          My experience is rather different with the community.

                                          I wanted two things from FDE:

                                          1. encrypted mirror disk (or mirrored encrypted disk). The documentation clearly states this is unsupported.
                                          2. encryption unlockable both with a key device (disk/file on partition/yubikey) and a password as a fallback. The documentation of bioctl and the docs don’t explicitly state if this is supported or not, but the command line examples suggest it is not. With 1. already making it a no-go I didn’t try this.

                                          I have encountered other shortcoming of the system while evaluating it for its intended role (without encryption), and it proved unsuitable (and I didn’t have the resources to develop fixes, which may or may not be incorporated, while other systems are suitable out of the box). I abandoned the system as updates introduced regressions and made it unusable on the test machine.

                                          1. 2

                                            My experience is rather different with the community

                                            I’ve found openbsd (and netbsd) communities to be quite friendly. Freebsd’s quite hostile. Of course, my experience is that of a single person, thus naturally limited.


                                            You’re right in that it’s an odd mix between LUKS and dm-crypt, as it does handle the key for you (passphrase on bootloader), but doesn’t have the flexibility of LUKS nor the “I do it myself” kind of flexibility of using straight dm-crypt.

                                            Dragonfly is the one BSD that does better in that regard… by simply implementing LUKS.

                                            1. 2

                                              FDE: the LUKS solution also has its not so elegant points (initrd regenereation when crypto setup is changed)

                                              I have very good experience with the NetBSD community from a very log time ago. Super friendly guys! Some OpenBSD guys were friendly, but many more were not. I could not get help for my problems :S

                                              I know a FreeBSD fan guy personally. Way unfriendly guy :) But I try not to generalize too much from a single element sample.

                                              I have never tried Dragonfly, thus have no experience so far. That system also has some interesting aspects, but I’ve never had the resources to try it so far.

                                              I could also point to #fedora on freenode, where I met a very unwelcoming environment with my questions, even more unwelcoming than that I encountered at obsd. Really mean guys there.

                                              1. 2

                                                I agree about netbsd being exceptionally friendly. I was honestly impressed myself. This has been true for at least 15 years.

                                                I haven’t seen hostility from openbsd, but every time (across decades) I reached out to freebsd communities (irc, mostly) I’ve been met with open hostility.

                                                Dragonfly team actually hang out in efnet, rather than freenode or oftc. They’re alright.

                                1. 1

                                  Sidebar: I don’t have a downvote button at all. Does it come with time or points or something? Didn’t see a mention of this on the wiki or about pages.

                                  1. 3

                                    The flag mechanism, between suggest and hide in the byline div below the story title is how one downvotes a story. It is available after a user account is no longer new.

                                    1. 6

                                      Stories don’t have downvote buttons, they have flags. It used to be implemented with a downvote arrow like reddit, but people treated as a “I don’t like this” button like reddit with an extra click.

                                      To see the flag link on stories, a user has to be not new (was 7 days, now 70) and have 50 karma.

                                  1. 6

                                    In the user interface, upvoting a story takes less effort than flagging (what the codebase also refers to as downvoting). To flag a story you have to have a reason, selected from a list (Off-topic, Already posted, Spam, Broken Link) whereas to upvote a story you toggle the “Add upvote” arrow, without need to provide a reason or make any further choice.

                                    Given that flagging takes more effort than upvoting, I like the idea of giving it more weight when calculating story hotness as a means of accounting for the different UI cost of upvoting vs. flagging.

                                    1. 1

                                      really with this?

                                      @alynpost can we merge this with ?

                                      You can correct me if this shouldn’t be merged but I don’t see the point in a new post for this.

                                      1. 2

                                        Thank you @fro. I have merged story nxn7jz in to story ti21d7.

                                        Your request to merge is correct. The article, despite being the same CVE, is a substantive update, adding three sections that can now be published. It’s appropriate that story nxn7jz was submitted [for merge]–it’s routine for credit, acknowledgments, exploits, or more detailed data to be published in this fashion as part of the responsible disclosure process.

                                        1. 3

                                          Thank you @gerikson, @cnst.

                                          I’ve merged story towcaw in to story h2t3qa, the opposite direction of what you requested gerikson. cnst observed story h2t3qa is the primary source with story towcaw responding to it. The stories were submitted so close in time (1-2 hours) to each other that I’m persuaded by the primary source claim.

                                          1. 2

                                            The opposite — the other article has a title that’s very one-sided and misleading, plus, this one is the original source.

                                            1. 2

                                              Thank you @fro. When I first saw your request (prior to your adding a link to the story to merge in to) I thought the story you were asking to merge referred to CVE-2020-7247 / OpenSMTPD 6.6.2p1, which has fallen outside the merge window. I quickly realized you meant story ti21d7 / OpenSMTPD 6.6.4p1, and they are now merged.

                                              1. 2

                                                Yeah I was a bit late on the link. Thanks!

                                            1. 17

                                              Spitballing a couple ideas here.

                                              On the topic of the 70 day new-user timer:I think this will just make the spammers much more difficult to notice as they will create dormant accounts waiting for the timer to expire while maybe posting a low-effort comment here and there. Possibly even automating it by copying or generating content based on previous comments on I don’t see a direct solution to this, but it’s worth to keep in mind how their approach will change with this.

                                              Regarding the new-user limitations in general: How about having two different types of invites you can send out? One regular invite as it is now, and one for people you trust? Sending the trusted invite would mean you personally take responsibility for actions taken by the person you invite (for a reasonable time frame that is) and their limitations are relaxed somewhat. This means you still can extend invites to people you don’t trust all that much, and they would end up having to display their trustworthiness, or you can shortcut that mechanism and allow someone you already trust onto the platform.

                                              1. 12

                                                Why would you invite somebody you don’t trust? Two levels of that and we’re back to where we started.

                                                I’m not totally sold on a time-based “newness” metric. Something more informed by usage would be good–are they submitting new content, are they actively commenting, are they helping suggest tags and whatnot. And sure, those are all gameable, but if we can trick the growth droids into performing vital community service why not?

                                                1. 31

                                                  I was invited by @flyingfisch because I asked on IRC. He invited me in good faith but doesn’t trust me as a personal friend. If I was banned he might get told “hey be more careful” but that’s about it. There are a couple of people I invited like that. I also invited @rwhaling because he’s someone I trust. If he got banned, I’d feel obligated to apologize to the lobsters community, because I personally “vouched” for him and was wrong.

                                                  That’s how I see this. I’d come in as a “standard” newbie and would have all the restrictions at first. @rwhaling would come in as a “vouched-for” user and would have fewer restrictions. But if he got banned, I’d be suspended or put on probation or something.

                                                  1. 6

                                                    Nice explanation. As a newbie who’s not enitrely sure how the whole community “breathes”, I’m constantly afraid of posting something so bad that my inviter has to feel bad about me. And they only gave me invite because I saw on Mastodon that they are a user here, we have low interraction otherwise.

                                                    1. 5

                                                      Thanks for your explanation!

                                                      But if he got banned, I’d be suspended or put on probation or something.

                                                      I like this approach for taking responsibility for downtree users.

                                                      1. 5

                                                        Suspend future invitations for some time.

                                                      2. 1

                                                        I think leaning into the social network/web of trust is a good idea. I think it may be useful to express beliefs and confidences, about users you do not invite.

                                                        What reward you get to balance the risk ventured, I don’t know. Maybe just the knowledge that you’re helping the anti-spam network.

                                                        1. 1

                                                          This is exactly the mechanics I was thinking about. The punishments and rules of it would need to be hashed out, but you are spot on with the idea.

                                                      3. 9

                                                        I think this will just make the spammers much more difficult to notice as they will create dormant accounts waiting for the timer to expire while maybe posting a low-effort comment here and there.

                                                        This is certainly existentially possible, but not actually true in my experience. One kind of abuse I deal with is fraudulent activity in my billing system. One surprising aspect of these behaviors is how impatient the people engaging in them are. Instead of waiting for the ‘right’ opportunity, they go to where there is an immediate ‘return’ on their effort. One explanation for this is that it reduces the evidence of the behavior, lowering legal risk. I think part of it is high time preference, however.

                                                        It is true that there are innovations in parasitism (e.g., spamming), just as there are innovations in productive and positive behaviors. What happened here was “innovative” in the sense that we had not seen it before. Since it provided an unearned benefit, the behavior was repeated until discovered and suppressed. That will happen again, perhaps even in the manner you articulate but probably in a more novel way–but that is going to be true every time we suppress an unwelcome behavior. Incremental suppression increases the cost of imposing on us–requiring more effort for the same reward is a feature, regardless of whether it fully eliminates the unproductive behavior or not.

                                                        1. 7

                                                          This also happens with SMTP servers, interestingly. One of postfix’s most basic spam-prevention settings is just waiting a small amount of time at the beginning of each SMTP session and canning it if the client talks first. Apparently, the server is meant to talk first, but most spambots are so impatient (because they have to spam as much as possible before they get blacklisted) that they send their HELO before the server has sent them anything.

                                                        2. 4

                                                          I wonder if it would be possible to take the max between 70 days and an arbitrary karma count (maybe the median user karma level?). New accounts that genuinely want to join the community and actively participate shouldn’t be tagged as potential spammers for over 2 months.

                                                          When I was invited 5 years ago, the person sending the invite was responsible for the new users that they invited and could lose their account/run into trouble if they abused the invite feature. It is my understanding that that was the main reason for showing the invite tree back then. Does anyone know if that policy has changed or if I just misremember the “good old times”?

                                                          1. 5

                                                            In practice “upstream” users have only been banned for downstream user’s indiscretions once or twice. It basically doesn’t happen.

                                                            1. 1

                                                              Off the top of my head, I only know of one user banned because of behavior by someone they invited, and they wrote the code to disable invites, so I don’t think there have been any since then.

                                                          2. 2

                                                            Expect owners of older accounts that aren’t used that much to start getting cash offers for them…

                                                            1. 2

                                                              Thank you @gerikson, I have merged the stories regarding CVE-2020-7247.

                                                              1. 1

                                                                I don’t think the post-mortem should be merged into this.

                                                                1. 2

                                                                  Will you explain why?

                                                                  1. 2

                                                                    It is now buried here with older posts. It also contains more information on how it happened, why it happened, what was done to fix it, and future plans. It’s more recent than the others and potential discussions from a detailed post-mortem seem worthwhile to me and they’re less likely to happen here now.

                                                                    1. 4

                                                                      The reason I merged story 4gd1oz (“OpenSMTPD advisory dissected”) in to story wcgwqk (“LPE and RCE in OpenSMTPD (CVE-2020-7247)”) was that both stories covered the same topic, and were submitted within two weeks of each other. This has been how story merging has been used since it was implemented in August 2014:

                                                                      Similar stories such as multiple sites reporting about the same news topic, or duplicates not found by the duplicate detection code should be able to be merged into one story.

                                                                      To determine whether a two stories cover the same topic, I use the following tests:

                                                                      A) Is the article for the newly submitted story a near-duplicate of the article for the previously submitted story? i.e., was the material republished or rebroadcast?

                                                                      B) Does the article for the newly submitted story reference or link to the article for the previously submitted story? i.e., is it a response or follow-up? (Occasionally described as a hot take.)

                                                                      C) Does the article for the newly submitted story discuss the same situation or event as the article for the previously submitted story link? i.e., are there multiple sources?

                                                                      D) Does the article for the newly submitted story cover the same subject matter as the article for the previously submitted story link? e.g., is it a source code repository for a project that was the subject of a blog post?

                                                                      E) In all cases, is the newly submitted story submitted no later than two weeks after the previously submitted story?

                                                                      Any one of tests A-D are sufficient to merge, so long as test E holds.

                                                                      Here, I merged story 4gd1oz because it passed test C: the topic (in this case the situation under discussion) for both articles being the “Qualys Security Advisory for OpenSMTPD (CVE-2020-7247)”, and test E: story wcgwqk was submitted on or about Wed, 29 Jan 2020 and story 4gd1oz was submitted on or about Fri, 31 Jan 2020. Approximately two days apart.

                                                                      It is a near-certainty that later published stories will contain more information (“It also contains more information on how it happened, why it happened, what was done to fix it, and future plans”) due to the straightforward fact that more time was available to communicate with others. Variation in information content of an article doesn’t pertain to topicality, however. Stories are merged when they cover the same topic.

                                                                      There has been at least one experiment to address your first reason (“It is now buried here with older posts”) due to similar report in issue 300. It was eventually reverted in commit c602b01 having been deployed less than a month.

                                                                      If you’re able to describe an improvement to the hotness calculation for merged stories that you think would substantively address your last reason (“potential discussions from a detailed post-mortem seem worthwhile to me and they’re less likely to happen here now”) I’d encourage you or anyone reading to submit a PR for review. An advantage of the current hotness behavior is that a story cannot be kept alive via “trickle” of newly submitted, merged stories–a story submission behavior we do see with multiple part blog posts. Changes to how hotness is calculated on merged stories need to account for all reasons a story is merged (i.e., the merge tests articulated here). A significant majority of story merges are unremarkable and a PR should aim to incrementally make more of them so.

                                                                      If you or anyone reading is able to improve the series of tests I use to decide whether a story should be merged, please voice it. Note however that where possible, I have removed discretion from the decision to merge a story via use of these tests. I’m not interested in adding discretion back in to the process. Doing so would not be an improvement. More decidability, not less.

                                                                      I hope this explanation adequately describes the trade-offs involved in merging stories, why story 4gd1oz was merged, and can serve as a guide to understanding how this feature as currently implemented is and will be used.

                                                                      1. 1

                                                                        Stories are merged when they cover the same topic.

                                                                        Does that only happen by request? I see other stories about the same topic that are not merged.

                                                                        1. 1

                                                                          I merge those stories I notice that other folks haven’t already suggested. If you see one you’re welcome to suggest it get merged–gerikson highlighted me for story n9ttxa here.

                                                                          1. 1

                                                                            I just wanted to make sure I was understanding this all correctly. Thanks for the very detailed explanation of everything.

                                                                      2. 2

                                                                        I fully agree with @fro here.

                                                                        The CVE was “am I affected? no? ignore. yes? patch.”

                                                                        This is potentially interesting for anyone who writes software :)

                                                                1. 3

                                                                  Another good video is, but I don’t want to spam.

                                                                  1. 1

                                                                    Thank you Bystroushaak, I’ve merged your submission here in to story v2gahh. To your follow-up comment about not wanting to spam submitting another link: there is an open ticket to make story merging available as an edit suggestion, which would make submitting material related to previous story submissions less manual than it is now.

                                                                    1. 2

                                                                      Thank you Pistos, I’ve merged the source code repository story submission in to story dwugf8, the release announcement.

                                                                      1. 2

                                                                        Thank you @gerikson, I’ve merged the home page story in to the previous submission of the source code repository.

                                                                      1. 1

                                                                        @tedu, I think you’re missing an <h4> tag around your “shambles” heading.

                                                                        I would like to particularly commend you for this expressive yet succinct sentence:

                                                                        Spectre v1 might be more accurately described as the existence of speculative execution.

                                                                        The slides to that talk do a fair job of showing what it means to “identify all possible branches,” and the link at the end to the presenter’s Speculative Load Hardening show what it takes to find a “better approach.”

                                                                        Decades (40 years) indeed.

                                                                        1. 4

                                                                          The comment search uses the MATCH AGAINST syntax, explaining the behavior you describe here.

                                                                          The search function has a peculiar and interesting history. @355E3B has PR 579 to use ElasticSearch. At the time that PR was submitted search was slow and would produce frequent 500 errors. We tested and then loaded production data in to ElasticSearch–the change is essentially ready to deploy to production.

                                                                          However, while working on deploying this middleware, @pushcx found a memory leak in the search code path (with an assist from Scout APM) which dramatically lowered the memory overhead of running the site. It’s using just north of 3GiB momently–prior to fixing this memory leak the site would use over 8GiB. Nearly 3x more memory. That single fix decoupled site growth from memory utilization and changed if not eliminated the architectural plans we had to accommodate the site’s growth.

                                                                          That fix also took a lot of pressure off improving search, which now runs faster and doesn’t produce 500 errors. While using ElasticSearch does improve the search UX, it also adds a new and large daemon process to manage–including needing to continuously update and from time to time reconcile the search database with the SQL database. Reconciling the two requires another daemon, beanstalk–more overhead yet.

                                                                          Before committing to maintaining a separate search database, we’re going to experiment with the PostgreSQL full text search which would preserve our having a single database.

                                                                          We’d welcome improvements (pull requests) to search that are consistent with these goals and accommodating of the history here.

                                                                          1. 4

                                                                            Postgres full-text search is finicky to configure, but quite capable of driving search for a site of this type. The four main ways of doing it are:

                                                                            • Add a generated always column (requires PG 12), which is probably simplest.
                                                                            • Add a regular tsvector column to comments and populate it in a before_save hook (similar but works on pg < 12).
                                                                            • Create a materialized view (queryable like a table from rails) containing (bigint comment_id, ts_vector search_content). This is awkward since new comments don’t show up until you refresh the view from cron.
                                                                            • Use an expression index (but if for any reason postgres decides the index is unsuitable it’ll generate enough load to take the site down instead).
                                                                            1. 2

                                                                              OK, thanks for the response.

                                                                              Is there a reason that “your threads” doesn’t paginate? What I do on Hacker News to find comments is generally to scroll through in my browser and hit Ctrl-F. That’s good enough for many cases. Is it just because that query is expensive?

                                                                              Hacker News seems to outsource their indexed search to which has a free tier, but I don’t know if fits within that.

                                                                              edit: probably not since the limit is 50K operations 10K records!

                                                                              1. 2

                                                                                Is there a reason that “your threads” doesn’t paginate?

                                                                                @danielrheath is correct here: the feature is unimplemented and pull requests adding pagination to the Your Threads page are welcome. As pushcx said a few months ago: lack of pagination is not considered a feature. For those interested in doing so it’s worth reading over that thread–and feel free to drop in to #lobsters if you need any help or want to talk about it.

                                                                                1. 2

                                                                                  OK I solved my problem for now, but if it continues to annoy, I will return to this thread :)

                                                                                2. 0

                                                                                  Is there a reason that “your threads” doesn’t paginate?

                                                                                  I’d wager that’s because nobody has volunteered to implement it yet.