1.  

    Nice guide. Helps to remember a lof :)

    1.  

      I would love to see a YAML that forbids the odd parts of YAML and makes it an easier language to use.

      Have you seen StrictYAML? It might be overly cautious in what it cuts out, but it is a very nice reduction of YAML.

      EDIT: Foolish me, posting this before reading the article which shouts out StrictYAML at the end.

      1.  

        As for me, writing tutorial is not an easy part of learning, especially if you are not pro in area what are you writing about. I would recommend writing a pet project first, share and learn for a community and after that you can write a tutorial :)

        1.  

          The part about it being harder to write correct code only applies to imperative languages though. This is why I’m saying that it’s important to separate the platform from the language. I like the Erlang model as well, however shared nothing approach does make some algorithms trickier.

          Personally, I found Clojure model of providing thread safe primitives for managing shared mutable state to work quite well in practice. For more complex situations the CPS model such as core.async or Go channels is handy as well in my experience.

          1.  

            How are you connecting to the <arbitrary_percentage> of IPv4-only hosts on the Internet? Does your ISP have a v6-to-v4 translation thing going on?

            1.  

              The content is great, and props to the author for finding CVE-class, bounty-worthy bugs!

              But, I’d like to talk about the form.

              “[So that is that idea.] Let’s push that onto the stack.”

              “[There is other idea.] Let’s push that onto the stack, too.”

              …And here’s where the author should push another idea, and then set “Pop, Pop, Pop!” as the name of a section!

              But no, they just forgot about the stack they were building and made a section named “idea 1 + idea 2 + idea 3”.

              Such lost opportunity. :( Why did they put the stack language in there in the first place?

              I’ll steal the stack idea for a post of my own sometime, but I’ll do it right.

              1.  

                From what I understood, if you attach an encrypted external HDD or open an encrypted virtual disk, then use QuickLook to preview file contents on the encrypted, the previews will be cached on the host machines HDD. So even after you unmount the encrypted drive, there will be some data left on the host machines HDD.

                If the main HDD is a trusted machine with full drive encryption, there’s no leak beyond that.

                This is relevant to people carrying around encrypted USB sticks and using them on untrusted machines.

                The title is click bait-y and there’s an inflammatory, uninformative quote in the beginning of the story.

                1.  

                  Came here to say something similar to this.

                  Learn new technology through writing a tutorial about it, but don’t publish it.

                  There’s so much misinformation by well-intentioned learners.

                  I’m not trying to diminish the importance of journaling either! Journaling != Tutorials.

                  1.  

                    This reads like a proper sci-fi short story and I suspect that a LOT of it was highly embellished. It makes sense to me that his direct managers would be confused as to what was going on, but it does not make any sense that it took them three weeks to figure it out. “The thing that I’m responsible for is on fire and my contractor can’t access anything” is a managerial complaint that should make its way up to the fucking CEO in a matter of hours if all anyone else wants to do is point fingers. So either important details were omitted to make it a better story or this big business is exceptionally bad at being a business.

                    1.  

                      The OP mentions Rust, and you were talking about it too. Scanning the posts tagged with D, I see exactly one substantive discussion involving Rust other than this thread. So I’m going to have to call shenanigans.

                      Well, the RESF is pretty strong.

                      Just stop. If you have an issue, then address it head on instead passive aggressively trolling.

                      D and Rust are used to solve similar sets of problems. This invites comparisons, not just on the Rust side but on the D side too. A lot of people who haven’t used Rust get their claims mixed up or are just outright wrong. I see nothing bad about politely correcting them. That’s what I did for your comment. What do I get in exchange? Whining about syntax and some bullshit about being attacked by the RESF. Please. Give me a break.

                      Do you want to know why you don’t see me talking about D? Because I don’t know the language. I try not to talk about things that I don’t know about. And if I did, and I got something wrong, I’d hope someone would correct me, not just for me, but for anyone else who read what I said and got the wrong idea.

                      1.  

                        Is the right wing sadistic and enjoy suffering? I would also say no.

                        Citation needed.

                        1.  

                          Threads are just a better default from the developer perspective

                          There is the caveat that threads (at last in the JVM) dramatically increase the complexity of the memory model and are generally agreed to make it harder to write correct code. Single threaded event-loop style programs don’t remove the chance of race conditions and dead locks but they remove a whole class of issues. Personally, I like something like the Erlang model which is fairly safe and scales across hardware threads. My second personal preference is for a single threaded event-loop (although I generally use it in Ocaml which makes expressing the context switches much more pleasant than in JavaScript/Node).

                          1.  

                            It’s absolutely not the the case that I fear that you’re trying to displace people from project channels to slack, apologies if it’s come across that way. It’s more frustration that for a community that’s fairly well established on IRC, there’s pressure to fragment across platforms.

                            While you present the argument that Slack is better for low-traffic communities, I’m not sure I agree. You mainly rely on these points:

                            • You can check slack intermittently and catch up on what you missed
                            • You can respond to things that happened when you weren’t around

                            Both of these points are well covered by IRC. While it’s true that the core protocol doesn’t cover it, it’s now the standard practically to use a bouncing service that permits it, or self host your own. A bunch of ZNC specific providers can be found here: https://wiki.znc.in/Providers , and additionally there’re services like https://www.irccloud.com/ that provide the entire system including a web client.

                            Slack has some downsides, like really poor community management, instead deferring to out-of-band systems to deal with things like harassment as well, essentially showing it’s colours as a business service offering. For example, there’s no ability for an individual user to ignore another they do not get along with or are being harassed by, with Slack instead suggesting this be resolved with HR policies.

                            1.  

                              Well, the RESF is pretty strong. I make one off-hand wrong comment and three of you, whether intentionally or not, jump on it. I practically never get that many comments in quick succession in Lobsters. I obviously struck a nerve by speaking a falsehood that must be corrected immediately.

                              I’m also slightly unhappy that we can’t ever talk about D without “I would like to interject for a moment, what you are referring to as D is in fact Rust or as I’ve taken to calling it, CRATE+Rust”.

                              1.  

                                As mentioned by a few people, there are some flaws in this in what it means for you and your readers following it. Something I’ve considered a worthwhile approach, however, is similar to this.

                                We have a paired group at university where each week we pair off and learn about a particular subject. Later, we come back together and teach each other what we’ve learned. It’s useful to go head to head on the misconceptions you’ve each picked up, and you can correct and work with each other to both develop a better understanding.

                                1.  

                                  I’d be very interested in what your semantic issues with Rust are.

                                  A proper answer to that would need me to sit down for an hour (or more) and go through again the material on Rust to remember the issues I had. Some of them aren’t very significant, some of them are definitely subjective. I should qualify: I’ve barely actually used Rust, just looked at it a number of times and had second-hand exposure via friends who’ve been using it extensively. The main thing I can remember off the top of my head that I didn’t like is that you get move semantics by default when passing objects to functions, except when the type implements the Copyable trait (in which case you get a copy), so the presence or absence of a trait changes the semantics of an operation. This is subtle and, potentially, confusing (though the error message is pretty direct). I’d rather have a syntactic distinction in the function call syntax to specify “I want this parameter moved” vs copied.

                                  Other things that bother me are lack of exceptions (I realise this was most likely a design decision, just not one that I agree with) and limited metaprogramming (the “hygienic macro” facility, when I looked at it, appeared a bit half-baked; but then, I’m comparing to C++ which has very extensive metaprogramming facilities, even if they have awful syntax).

                                  I can assure you after attending the All Hands that this is definitely a hot topic, but also a hard one.

                                  Yep, understood.

                                  I’m happy that you took a look at the language, even if you came away wanting.

                                  I’ll be continuing to watch closely. I’m very interested in Rust. I honestly think that some of the ideas it’s brought to the table will change the way future languages are designed.

                                  1.  

                                    So, to answer your questions:

                                    • If you’re using an authentication provider then no, it won’t really help, although… In my recommendations I mention using patterns like adaptive multi-factor authentication to re-prompt for a second factor when changes are detected – this is something Okta provides. I’m not too familiar with auth0/cognito, they might also have this functionality. So that can help a bit.

                                    • There is honestly no way to have a stateless backend service without revocation. The best you can do is maintain a cache where in the cache you store any invalidated JWTs and check each request against the cache. This is a pretty common pattern.

                                    But, re: stateless backend services, one thing I like to think about it is the security vs speed tradeoff. You basically have two options: either guarantee security so you aren’t servicing revoked tokens or guarantee speed and not bother with it at all. If your architecture has backend-only services that aren’t exposed to users, going for the speed tradeoff might be worth it since you’re in a trusted environment. But, if your API is servicing end-users it’s probably better to go with the approach mentioned above so you don’t run into issues :x

                                    1.  

                                      Please note: this is not a terminal vote. The European Parliament in plenum will later on have to vote on the directive as a whole. As of now, it’s not in force nor even set to enter into force.

                                      Also please note that that it’s not a law (i.e. regulation in EU speak). It’s a directive. It requires member states to make laws in a certain fashion, and more often than not, there can be differences in each member state’s law based on the directive.

                                      And since appearently nobody cares to actually read what has been voted on, the voting document is available online on the EU parliament’s website. Art. 13 is mentioned under CA 14. Though to be honest I find this document confusing. If someone has a consolidated version available somewhere, a link would be nice.

                                      1.  

                                        There’s a world between documenting how you learned a thing, and writing a tutorial for that same thing. If you’re learning a thing, probably don’t write a tutorial. I agree with you, writing about a freshly learned lesson helps in making the learning more permanent, though.

                                        1.  

                                          IRC works really well when you have a core team who spend a lot of time in a topic-specific channel where visitors can stop by and engage with them. That’s great for channels focused on individual open source tools, as you point out. One of Slack’s strengths for community channels is that it handles low volume conversation better because you can check it intermittently and catch up on what you missed. Being able to respond to questions that were asked when you weren’t around is a big plus.

                                          Our intention here definitely wasn’t to try to take the place of project-specific IRC channels at all. We just felt that there wasn’t really place to talk about experiences with different tools and tactics at a higher level. We get emails from people all the time about topics like this, and our hope is that making these sort of discussions public will be helpful to the community.