> ² With S/MIME you need to keep your old certificates around to decrypt old mails, so having a new one frequently is not practical
You don't need to change your decryption key - the new certificate can use the same decryption keys as the old one (certbot even has a flag: --reuse-key). Whether this is a good idea or not is a separate question.
I think the biggest benefit would be ACME-like automatic certificate issuance. Currently getting a new certificate is just too much friction.
The other thing I would hope for is wildcard certificates. I stopped using S/MIME because I usually create a new email (based on the same domain) for each vendor that I deal with. I would find it useful to be able to get a single certificate covering all email with that domain. Obviously that does mean that anyone else using an email from that domain would have to share the certificate, but for private use that can be acceptable - I don't worry about my wife reading my currently unencrypted email!
I think parsing there depends on the actual value of the current token. So if you assign send to another variable and use that the "parser" will still recognize that it takes 2 parameters.
It's an interesting design, definitely not something one sees frequently.
> That section briefly described that, broadly speaking, using unwrap() is okay if it’s in test/example code or when panicking indicates a bug.
I've come to the conclusion that even in tests unwraps look ugly. Especially in doc tests which serve as examples the code is better off using regular "?" that one would see in other parts of code. (that is: don't treat test code as a "worse" kind of code)
I always felt unwrap is preferable for diagnosing issues, which makes it useful in tests. A failed unwrap will point you directly to the line of code which panics, which is much simpler than trying to trace an issue through many layers of Results.
If you use `assert` in tests, I don't understand why you wouldn't also prefer unwrap in this context.
I think it's also perfectly reasonable to use in a context like binary you run locally for private consumption, or for instance a serverless function which allows you to pinpoint the source of errors more easily in the logs.
It's not a good fit for cases where you do expect cases where the unwrap will fail, but it's a great fit for cases where you believe the unwrap should always succeed, as it allows you to pinpoint the cases where it fails.
I call unwrap a lot in unit tests where it feels obvious to me that this succeeds, so, if it doesn't that's a huge mistake and should definitely fail the test but I have no pre-existing description of what's wrong, it's just a big red flag that I'm wrong.
Fallible conversions that never fail in the tested scenario are an example - parsing "15/7" as a Rational is never going to fail, so unwrap(). Converting 0.125 into a Real is never going to fail, so unwrap(). In a doctest I would write at least the expect call, because in many contexts you should handle errors and this shows the reader what they ought to do, but in the unit test these errors should never happen, there's no value in extensive handling code for this case.
> I always felt unwrap is preferable for diagnosing issues, which makes it useful in tests. A failed unwrap will point you directly to the line of code which panics, which is much simpler than trying to trace an issue through many layers of Results.
Take a closer look at testresult since it also points directly at the exact line of failure (due to panics being used under hood) but looks nicer.
I agree that unwrap looks ugly. Sometimes I wish Rust had a ! operator like Swift and TypeScript do. But then that would encourage bad practises in non-test code, so…
Key IDs are based on fingerprints and fingerprints are calculated by SHA-1 hashing the primary key's public key and the creation timestamp. A computationally easy way to influence the fingerprint is to tweak the creation timestamp which is a 32 bit Unix epoch value. Of course it needs to be in the past so the range is limited but it's faster to do it this way instead of recomputing the cryptographic key.
RFC 1991 only gives them 4 bytes (32bit); not sure if there have been any later additions to rectify this but I don’t think so since even the latest RFC (9580) has them listed as 4 bytes…
It was the Ubuntu 16.04 desktop running in a LXD container. It crashed when the tablet went in out of memory, so I had to be careful with what I was running.
Corps are separate legal entities so individuals are generally protected from personal liability. There can be exceptions in criminal and civil liability instances but even then there things like D&O. Until we stop giving corporations so much legal cover we’re hosed.
>Corps are separate legal entities so individuals are generally protected from personal liability.
not really.
corps have the defining feature that their passive shareholders are protected from personal liability, but not their officers, directors, nor employees.
they are "entities" so they can sign contracts and you can sue them and bring them to court. they are entities so the entire body of preexisting laws about suing and bringing to court would not need to be rewritten from scratch for corporations, it slots them into the rights and responsibilities that individuals have.
That's true, but in general it's easy to archive games from Steam and (as long as the publisher doesn't use any 3rd-party DRM) they're trivial to crack.
I buy my games from Steam because of the convenience and to support the developers, but if, say, Gaben kicks the bucket and Steam suddenly closes/turns evil I can just as easily pirate all of my games back. So from a game preservation standpoint Steam isn't that bad compared to the locked down consoles and their walled gardens.
> I buy my games from Steam because of the convenience and to support the developers, but if, say, Gaben kicks the bucket and Steam suddenly closes/turns evil I can just as easily pirate all of my games back.
I'd recommend pirating copies now to keep as backups while it's still easy. You can't be sure you'll be able to find copies of less popular games in the future, having the control over our own computers to do things like run unauthorized software is being threatened all the time, the ever expanding surveillance over our lives makes it increasingly risky to do anything legally questionable, and the copyright regime is only getting more powerful. I don't think piracy is going to die out any time soon, but I do suspect it's only going to get more difficult as we're increasingly controlled and spied on.
Steam is always given an exception in these conversations because they’ve generally behaved - but that can easily change overnight from a black swan event.
Some future manager will look at a graph and think monetization can be improved X% while only losing an estimated Y% of users. It is guaranteed to happen. Question is only if most in the current generation will outlive free access to their entire Steam library or not.
This can easily be changed if Gabe Newell dies, commits a crime, or gets divorced, his estate or trust wants a change in direction, a lawsuit costs Steam a ton of money and they need to get cash quick, take your pick.
It does, but Steam outlives console e-shops and hardware which have limited lifecycle by design since they are deliberately generational.
GOG would be another example since you can get a DRM-free binary.
On the other hand, does it really matter that much? Probably not. It feels good from a hoarding stance to have a bunch of games I'll probably never play but I got for a "good deal", heh.
A counter-point to my comment is that the real goal should be to buy the game on the medium you want to play it on only if you're going to play it, finish as much as you want to, and not care if it goes away because it's all ephemeral in the end.
I barely play games anymore yet I still would get sucked into looking for deals on Switch e-shop and Steam, and that feeling of sheepishness is what I had in mind when I commented.
You don't need to change your decryption key - the new certificate can use the same decryption keys as the old one (certbot even has a flag: --reuse-key). Whether this is a good idea or not is a separate question.
I think the biggest benefit would be ACME-like automatic certificate issuance. Currently getting a new certificate is just too much friction.