That may provide short term stability, but medium term (which in this field is a few months) how will Azure's offering move forward if OpenAI is in such crisis? I guess it really comes down to OpenAI's ability to continue without Altman and Co. I don't believe that Microsoft's license allows them to independently develop the models? Wouldn't this become a stale fork pretty quickly while the rest of the industry moves on (llama2 etc ..)?
A zip file on a web server that supports etags, that's polled every time access is required. When nothing has changed since last time, you get an empty HTTP 304 response and if it has changed then you simply download the <1MB Zip file again with the updated etag. What am I missing?
Anyone working on even a medium sized C++ project needs a very high end machine in order to compile. For large projects, 32 core work stations aren't crazy at all. Try building something like Firefox or Chromium on a quad core and you will see what I mean. The cost of the workstation is tiny compared to the cost of the engineer and you really don't want them to be waiting around for half their day (quite literally) because of a miserly equipment budget.
I think maybe you're paying too much heed to what you see in concentrated and very self selecting online communities. A lot of professional C++ programmers are more focussed on particular industries, and the domain problems to solve and less so on the language or specific tools. It just so happens that C++ has been the only game in town in a lot of industries until quite recently. At work we've been looking into trying out Rust in some modules where it would make sense. There has been zero objection based on it being Rust, from a team of senior C++ devs. Quite the opposite, most are keen to try it out. But those people don't spent their time on language message boards. Sure, you will find the type of person that you describe. They definitely exist. But it's not the typical case of senior C++ developer, in my experience. Most of us are domain experts in something (automotive, security, medical devices, games, OSes, networking, etc...) and the language comes secondary. If we can better solve our primary goals with a different language then we'd be fools not to have an open mind.
I'm not sure about that. I've spent 18 years programming in C++, for much of that time in a senior professional capacity and am excited to learn Rust for whatever my next project will be. Most of my colleagues and peers feel the same. I think the person you are characterising is quite rare. I like C++ but don't love all of the baggage and am delighted that things are moving forward.
> 3. It apparently doesn't stop people from getting or becoming transmissions vectors. So, if you get the vaccine and it makes you less sick, then you may take "riskier" actions than if you were to get it and actually have some symptoms. (IOW, why take it?)
From what I've seen this is not established at all. They are careful to say that they don't have conclusive proof that the people who were in their study were not ever contagious - but that doesn't mean that they were contagious either.
They have simply called out that further studies will be needed before we can say whether and to what degree.
And even if you fabricate your own hardware, you're still trusting the open source designs you download from the internet. Being able to audit them is much better than not being able to see them, but it's still very possible to have some incredibly subtle backdoor or vulnerability hiding in plain sight. This happens all the the time in complex systems.
There is zero chance that you can design a functioning and useful chip and OS, from scratch without trusting something else along the way. That goes all the way to compilers, toolchains etc... And even if you could, chances are you've created hundreds of accidental security vulnerabilities that can be exploited. Zero trust is a fantasy.
Yeah, this is what is jumping out at me. Not that the M1 isnt extremely impressive but a near future 5nm AMD will be a better "apples to apples" comparison. Intel is being left in the dust though.
But we've already established that these are meant for "the promotion of teaching basic computer science in schools and in developing countries". In these situations with young, untrained hands, durability and robustness are absolutely key criteria. It's not good value if it ends up discarded/broken due to additional complexity or a fault.
C++ error messages have been gradually improving over time. Clang really raised the bar when it came along, and the other two compilers have been catching up. Concepts in C++20 will really help to further improve things for template errors.
> So they're trading bandwidth for CPU load at either end
Given it's Nvidia I would imagine it's more likely going to be GPU load rather than CPU load. Don't underestimate the current computational overhead of existing lossy video compression.
The database key should be generated per encrypted database and then stored using something like the OSX keychain. The OS enforces that only a given application can retrieve that key (via application code signing).
I heard the exact same from a shark expert in the Great Barrier Reef. Rather than using a cage or anything we'd normally associate with shark diving, he puts a set of googly eyes on the back of his head and had been safely shark diving professionally for 2 decades.
On the flip side, it seems to me like having all of this friction may lose many folks early on. I absolutely agree that debugging and problem solving are core skills to master and fundamental for any programmer. As is understanding the system from first principles, and how all of the different sub systems interact. But in my opinion they shouldn't necessarily be the first thing someone encounters when they try to do X.
Exactly - I have huge respect for Bruce Schneier when it comes to matters relating to cryptography. But apart from commenting on the security, privacy and other technical aspects of these apps, I'm not sure on which authority he's giving these opinions on matters relating to epidemiology. At very least I'd like him to give some supporting scientific citations. But as it stands, Bruce's opinion on the medical and public health efficacy of these apps is no more valuable than yours or mine.
Right - this is just a way of helping to prioritizing who gets tested. Given that testing kits will always be a limited resource (you can't simply test everyone, everyday) it makes a lot of sense to find sub-populations who are more likely to be positive. That doesn't mean you don't test anyone else (eg. those with symptoms, those in sensitive jobs) - it just lets you use a certain percentage of your testing capacity one those people who have been in proximity with confirmed cases.
As you say, it's not a silver bullet but in combination with a slew of other approaches can help reduce the rate of transmission rate.
On Windows that currently means MSHTML which, depending on your OS version means some variant of IE. Not even Microsoft pages support IE properly anymore. Also, bloated here tends to mean runtime cost, RAM and CPU use, not disk use which is what you are solving for. Some browsers are definitely worse than others in this respect but running several instances of a full browser stack is not exactly light for any of the major browser engines.
There is, but it's Java - they would have to write JNI. I don't think there's anything wrong with using CURL. Should probably be a bit careful about calling it "native" though.
I just don't really see the point to how they've gone about this. Cpprestsdk is already structured in a way where writing different native client impls for each platform is part of the design. So, rather than adding more native implementations there, they've put another layer on top of cpprestsdk, and added some new client implementations in this new library, and for others it calls down and uses cpprestsdk's existing implementations.
This seems to fragment things more than if they had simply contributed to (or even forked) Microsoft's project.
Edit: Sorry, I misread your post. To add, cpprestsdk has 2 impls for Windows - one based on top of WinHTTP and the other based on WinRT APIs. On UWP, cpprestsdk uses the WinRT APIs and by extension so does NFHTTP.
I agree in general that using native HTTP stacks is a good idea for all sorts of reasons, but it's worth calling out that NFHTTP is actually using CURL under the hood on Linux & Android platforms so this just ultimately wraps the CURL C API in a C++ API. On OSX it is using NSURL which is great, and on Windows it's using Microsoft's cpprestsdk library in order to talk with WinHTTP and UWP.
This interested me too so I looked through the source to find out. NFHTTP seems to add 2 clients of its own, one that uses NSURL (for Apple) and another that uses CURL (for Linux). Everything else (WinHTTP, UWP, and the fallback Boost Asio client) simply call down and use the cpprestsdk implementations directly.
Seems like this library offers less itself than it says on the tin, given that 3/5 of its native impls just call down to cpprestsdk. It's a pity that spotify didn't simply add CURL and NSURL clients to cppressdk - that would have been far more useful IMO.
This library seems to add a HTTP client impl built on top of NSURL, and another on top of CURL. It looks to me like everything else here is provided by Microsoft's CPPRestSDK - WinHTTP, UWP & Boost Asio based clients simply use the CppRestSDK impls under the hood.
I'm sorry to hear that it's not multi-process. Ticked all of our boxes right up until that point. We have a use case to render our own UI, which from a threat modelling perspective can run in-proc, but also have another use case of running untrusted web content which absolutely needs to be out of proc. Do you have any plans to consider making it optional? I take it you've probably made architectural decisions that would make that extremely difficult?