Cool. In the meantime Google Assistant still fails to reliably call my contacts via voice command.
And trying to use Google's AI offering as a paying customer of Google apps for work is a giant shitshow. So much so that I'm finally contemplating of dropping the Google ecosystem all together.
The developer time required to learn and properly use nix makes it unattractive to most teams.
The benefits don't outweigh the costs of adoption.
Instead of debugging code, the team would have to spend significant time maintaining the build system for the build systems sake.
Don't get me wrong, I want something nix-like in my toolbox.
I want to love nix.
But I wouldn't dare to argue my team to commit to the world of pain that comes with it.
There's a good reason that nix didn't see wide adoption in the industry.
The vaccination campaign has solely been target at girls and women. Which is crazy, since boys and men can get cancer from HPV too.
I really don't understand the bias in public health communication here.
OWID is making the same mistake again.
How are boys supposed to know that they should get the shot, if everybody public health professional fails to tell them?
> HPV is also thought to cause about 95% of anal cancers, 75% of oropharyngeal cancers, 75% of vaginal cancers, 70% of vulvar cancers, and 60% of penile cancers.2 Low-risk or non-oncogenic genotypes (eg, types 6 and 11) cause anogenital warts, low-grade cervical disease, and recurrent respiratory papillomatosis. In the USA, the incidence of oropharyngeal cancer in men now exceeds that of cervical cancer in women, and by 2020 the annual number of HPV-associated oropharyngeal cancers will exceed that of cervical cancers. As a result, it is important to consider ways to expand our HPV prevention efforts to boys and men.
If you don't need the pinouts, it's likely cheaper to get a used thin client or a N100 based machine.
You'd get similar power draw, plus a case and a PSU.
Gladwell is known for citing junk science and twisting reality by adding his own unfounded interpretations to research he's basing his theories on.
There's a host of criticisms of his work.
[Wikipedia](https://en.m.wikipedia.org/wiki/Malcolm_Gladwell#Reception) is a good starting point.
The main attack vector IMHO is the simple fact that one can sneak in new packages with malicious intent by simply contributing a new formula.
The team of maintainers is too small to audit all of the newly contributed formulae.
I'm suprised that this attack vector wasn't part of the audit.
There is an observable and testable probability that an LLMs output is correct or false.
There is an observable and testable probability that code created by humans is erroneous.
There is a third category where human code is malicious.
You will need to guard against all three cases.
Guarding against a possibly faulty LLM output that is passed to ffmpeg is significantly easier to realise through defensive prompting and simple sanitization techniques, than to protect against a malicious state actor that is capable of crafting sophisticated supply chain attacks that took years to develop and roll out (again see the xz backdoor).
The idea that you can blindly trust an open source project just because "their development happens collaboratively and in the open" is naive.
Some open source projects people are building their whole infrastructure on are maintained by a single developer in their spare time.
The attack surface is huge and has been exploited time and time again.
Just because a project like Debian has signed packages and a security team doesn't guarantee that the underlying code doesn't have some malicious backdoor or some grave bug that creates a big attack surface.
There have been many documented cases of supply chain attacks of various degrees of sophistication.
Some of them successful, some of them almost successful.
May I remind you of the recent xz vulnerability was discovered by a single dev by mere chance.
As an end user it is nearly impossible to guard against such an attack.
It can be problematic to run something like `curl foo.com | bash` without inspection of the script first.
But even here it makes a difference if you are curling from a project like brew.sh that delivers such script from a TLS protected endpoint or some random script you find somewhere in a gist.
Same goes for output from an LLM. You can simply investigate the generated command before executing it.
Another strategy might be to only generate the parameters and just pass those to the ffmpeg executable.
This was not a 737 Max, but a widely deployed model that is in use for decades.
The likelihood that Boeing is at fault here is extremely slim.
It is very likely that this was a piloting error or a maintenance issue, or a combination of both.
Ok, even after reading the initial announcement for Mojo on their blog, I still have no clue what this is.
A python like language but closed source?A language to build prompts? Something else?
If I were on a PC I would have to ask GPT4 to summarize it for me.
How is it so difficult to write a two sentence elevator pitch that anyone outside of your bubble can understand?
If Feynman could do it, you should be able to do it too.
My dream is that pebble eventually becomes a beautiful time piece. Maybe teenage engineering could be convinced to give the pebble a design refresh.