What we do currently is we lock everything to an explicit version - even libraries.
At least it's possible to get deterministic builds if you are willing to do a bit of work carefully / manually updating all of your dependencies at once.
You shouldn't have that happen with Cargo, given that we have a lockfile. Even when you specify version ranges, you're locked to a single, specific version.
If you follow the best practices for using Cargo you don't have a Cargo.lock file for libraries.
This means your library tests will not be deterministic.
Using the Cargo.lock file for libraries does solve this, but then every binary package you build that references your library will have to be specifically tied to the versions in the library.
We do this internally because it's the only way to provide deterministic builds over time.
Over time I suspect it will get harder and harder to keep this rigid web of dependencies working.
One thing we might try is to enforce the rule 'no library will contain any tests'. At first glance this kinda makes my skin crawl, but maybe if we could find a way where every project that used a library could somehow share the tests for that library it could actually work.
git submodules might actually be able to provide these tests for each binary package. If only git submodules would stop corrupting our git repos... :-(
Care to share what your setup looks like? Posture is something I think about a lot while computing. I've got a great sit/stand desk at my office now and I really only use stand if I'm having a funny numb leg or something. I've found doing yoga and weight training much more useful than exotic desks.
The attack was ongoing when Akami gave Brian Krebs 2 hours to find alternate hosting.
The attack showed no signs of waning as the day wore on. Some indications suggest it may have grown stronger. At 4 pm, Akamai gave Krebs two hours' notice that it would no longer assume the considerable cost of defending KrebsOnSecurity.
The first day in radar class the instructor put a piece of steel wool in front of a small dish and it instantly melted white and dropped molten metal onto the floor.
It always made me nervous when the class goofballs turned the horns on other people so you could feel the microwaves.
Goofball 1: 'accidentally' radiates goofball 2
Goofball 2: What? What are you doing? Oh, I'll show you - just watch me increase the power on this baby...
It turns out your testicles and eyes are a bad place to receive microwaves.
I submit to anyone thinking of attempting this: you are probably going to get the power calculations wrong and cooking human cells is not fun at all.
Yeah, there's definitely dangerous ways to use microwave emitters. But my point is that your instructor thought that it was relatively safe to give them out in radar class. If they were x-ray emitters, on the other hand...
2 people bet each other a dollar they could take a fundamentally simple concept and wax poetic insanity around it until the text was so insane no one could actually read through it - so people just shrug, wash the virtual slime off and move on. Their will power so drained by reading the BS they can't even be bothered to complain.
Then comes the fake accounts to gush how 'serverless' and 'function-as-a-service' are completely new and different and awesomer bra.
The next bet will probably be "mathematicsless": how we solve collision detection without math - and you should too!
That's like losing at counterstrike to a 12yrold. At that point they have the knowledge of how to play and will out-class your reflexes by miles. I don't play competitive twitch games anymore (am in early 30s).
As part of a recent project I had to:
- build an AST from a large and complicated DSL
- transform the AST into something that could be compiled into a DSO.
I chose to write both parts in Rust. Fwiw the semantics of the language really didn't match Rust at all (though, I suspect you weren't thinking of DSLs when you wrote your paragraph).
In the end I had all the benefits of _safe_ Rust when compiling the transformed code into the DSO.
This DSO is a critical component and can not fail. I can't imagine transforming the AST into C or LLVM - I wouldn't be able to sleep at night. I'm only human; I know I'd fall into a number of traps that humans fall into when coding in C - especially when I am _generating_ C from an AST...
Where I work client auth is used for a good (and growing) number of internal services.
Client auth is simple to use - our internal services are given the username from the CN, which they use to perform authorization checks. For a lot of simple internal services that don't require two-factor auth it works great.
Am I missing something better?
(We already have the infrastructure in place to deal with client keys)
What we do currently is we lock everything to an explicit version - even libraries.
At least it's possible to get deterministic builds if you are willing to do a bit of work carefully / manually updating all of your dependencies at once.