It's because as soon as one country forces it on their citizens the others can say "it can't be that crazy - Australia and the UK have already done it!"
No, generally people are annoyed that you're spending time paying off tech debt instead of piling on more.
I mean, it would be great if this succeeded... ffmpeg is nice and all but its interface is clearly terrible and there's absolutely no way it is remotely secure. Anyone that uses it on a server basically has to run it in its own VM, or a severely locked down sandbox.
But good luck supporting all the codecs people expect. I'm not even talking the obscure ones ffmpeg supports; just the ones "normal" people use will be a life's work.
Also you have to change the name!
Interesting idea, but your trick is never really going to help (you can store up to 255 bytes instead of 254). Also always using 256 bytes for every string seems wasteful.
I think LLVM's small string optimisation is always going to be a better option: https://joellaity.com/2020/01/31/string.html
Yeah there's a huge difference between "works 98% of the time" and "works 99.8%" of the time, even though they are both "works most of the time".
Yeah I agree. It's often easier to start from something that's wrong than a blank page.
Honestly I think the complaints about the job market are overblown. If you are good then there will always be a job for you somewhere.
If you've already tried programming and you enjoy it then it is a really great career. Crazy money (especially in the US) for low effort and low responsibility.
Just be aware that CS is usually a lot more theoretical than most programming. You'll be learning about things like Hoare logic and category theory. Tons of stuff you only really need in the real world if you're doing formal verification or compiler design.
Still, I kind of wish I did have that theoretical background now I am doing formal verification and compiler design! (I did a mechanical engineering degree.)
Also you don't need a CS degree to get a programming job. I did a survey of colleagues once to see what degree they had and while CS was the most common, fewer than half had one. Most had some kind of technical degree (maths, physics, etc.), but some had done humanities and one guy (who was very good!) didn't have a degree at all.
I wouldn't worry about the market. Maybe take a look at the syllabus for places you might apply to, e.g. here's the one for Cambridge. Also I guess an important question is what's the alternative? What would you do otherwise?
No, they're inherently optional in Git. There's no way to "check in" a git hook. You have to put in your README
Clone the repo and then please run
pre-commit install! Oh and whatever you do don'tgit commit --no-verify!
You definitely need to actually check the lints in CI. It's very easy though, just add pre-commit run -a to your CI script.
Normally when I merge a PR I put the long PR message (if there is one) in the merge commit (again if there is one), rather than shitty Merge PR from patch1 that people seem to use.
You can actually change the behaviour on GitHub to be sane: https://blog.mergify.com/how-to-change-the-default-commit-message-on-github/amp/
If I'm not keeping the branch (usually PRs are not big enough to make preserving multiple commits useful) then I squash & merge which gives you the chance to edit the commit message and copy details from the PR message in.
It requires you to sign into a Microsoft account (which I assume most non-nerds do, given how hard they make it to avoid) and have hardware that supports it... But yes Windows enables full disk encryption by default now.
When you first sign in or set up a device with a Microsoft account, or work or school account, Device Encryption is turned on and a recovery key is attached to that account.
If the build scripts were tiny and checked then the attack vector would have just been different, I’m not even too sure the language mattered.
I have to disagree here. Maybe they would have found another way, but it would have been a more obvious way, which is a very good thing.
Yes it would have still been compromised but it may have been detected earlier. So it's still pretty bad to have these incomprehensible build scripts.
FizzyOrange
0 post score0 comment score
joined 3 years ago
Yeah unfortunately these numbers don't really allow any conclusions to be drawn at all.
Also they're not really related to supply chain security which is more about deliberate subterfuge. I think the interesting stat there would be how many authors are being trusted typically for each crate.