• 1 Post
  • 122 Comments
Joined 2 years ago
cake
Cake day: June 12th, 2023

help-circle



  • So first of, the part of my comment that you quoted doesn’t make sense because what I’m saying is that bluesky theoretically allows for decentralized relays but it’s impractical in practice. Your analogy doesn’t really apply to that.

    I do think that it’s misleading to call bluesky decentralized today (at least without any caveats). The goal of the project however is to eventually create a more meaningfully decentralized social network and they have tangible plans for moving in that direction so I think it’s unfair to dismiss this aspect of bluesky completely.


  • I think that it’s fair to want the interviewer to ask more critical questions and in general be more precise with their phrasing but

    repeat that PR talking point

    is a very cynical and uncharitable take on bluesky and decentralization. Cynical takes aren’t necessarily wrong but they’re not necessarily correct either.

    The AT protocol is by its own account an ongoing project with problems that still need be solved before it is able to provide a social network with all the properties that they’re interested in.

    I don’t think that it’s accurate to say that bluesky is “completely” centralized (it is less centralized than most social media) as much as it’s de-facto centralized. One reason for this is that it’s prohibitively expensive to self-host relays. This is something that the AT protocol devs have plans for addressing, so it’s possible that this de-facto centralization is a temporary stage in the evolution of bluesky and AT proto.

    It is of course possible that they are lying or that they will be unsuccessful despite best intentions but taking for granted that it’s just a “PR talking point” is, once again, very cynical in a way that I don’t think is completely motivated.







  • I don’t know that it’s the “algorithms”: a lot of people just use their following feed on twitter and although it changed a while back that was the default feed on bluesky for a long time. I think that there is a fairly large portion of bluesky users who mostly just look at following and still don’t really like mastodon.

    Imo, a big reason why bluesky has been a more successful twitter competitor than mastodon is cultural: mastodon has been around for years before musk bought twitter, and a big selling point was that it wasn’t like twitter, for example that its “less toxic”. A large part of mastodons userbase never liked pre-musk twitter that much and will tell you of for acting like you would there. Bluesky on the other hand has a large portion of users who liked pre-musk twitter and are happy to follow pretty similar social norms as they did in pre-musk twitter.

    This is to some extent reflected in the functions of the different sites as well, for example you can’t quote retweet on mastodon which iirc is deliberate because qrt dunking is “toxic”. Bluesky has quote retweets (although they allow you to untag yourself from a qrt).





  • This article uses the term “parsing” in a non-standard way - it’s not just about transforming text into structured data, it’s about transforming more general data in to more specific data. For example, you could have a function that “parses” valid dates into valid shipping dates, which returns an error if the input date is in the past for instance and returns a valid_shipping_date type. This type would likely be identical to a normal date, but it would carry extra semantic meaning and would help you to leverage the type checker to make sure that this check actually gets performed.

    Doing this would arguably be a bit overzealous, maybe it makes more sense to just parse strings into valid dates and merely validate that they also make sense as shipping dates. Still, any validation can be transformed into a “parse” by simply adding extra type-level information to the validation.





  • Putting the message in git puts the information closer to the code, since the pr isn’t in git itself but instead the git forge. You can for example search the text of git messages from the git cli, or come across the explanation when doing git blame. I sometimes write verbose commit messages and then use them as the basis for the text in the pr, that way the reviewer can see it easily, but it’s also available to anyone who might come across it when doing git archeology


  • It’s fine to want a gui debugger and I want to clarify that I’m not actually trying to persuade you to use gdb! My actual advice would be vscode (or other ide) with it’s gdb/lldb integration which allows you to debug from your ide in a gui-oriented way.

    I do however think that you’re wrong about how hard it is to learn gdb. I learned to use it not that long ago and it doesn’t take “1 month”. Using gdb on a basic level is actually not particularly hard, and I can recommend this talk for anyone actually curious about learning gdb. It’s just 15 minutes, but the same speaker has done a couple of other talks on the same theme that are longer if you want to learn even more, you can probably find them in the recommended videos sidebar.

    What I actually think is the case is that learning gdb takes a bit more mental effort because it’s a different paradigm than gui debuggers, and a lot of things aren’t intuitive. If you’re prepared to be a bit uncomfortable and lost for an afternoon, and maybe even flip through the official document for a bit you can be “good enough” at gdb in less than a day.

    Gdb is also more powerful than most gui-only editors, because you can do scripting in gdb. For example you can execute an arbitrary series of gdb commands when you hit a certain breakpoint which can be really useful in some circumstances. My preferred way of debugging in linux is actually to both have a gdb window that I can enter commands in so I can do more scripting stuff if I want to, and also some extra bells and whistles for viewing source code and setting breakpoints etc. I edit in vim so I use the termdebug plugin that comes bundled with vim, but use whatever exists for your editor if you don’t use vim yourself.