I feel exactly the same. Switchting to GLM for Le Chat without an option to prefer a Mixtral model leaves a bad taste. I hope this is temporary while the new model rolls out, but this is not filling me with confidence in either the model or the judegement of the company.
I have absolutely no problem with them hosting and selling GLM as an offering, it just makes sense for them to do this as an option. As a long time subscriber however, I don't like at all that they have started using GLM as the default model in the Vibe app (formerly Le Chat), with seemingly no way to switch to Mistral's own model. I'm paying a monthly subscription to Mistral explicitly to use a European tool in my daily non technical LLM needs. This feels off and I'm reconsidering my subscription. If all they are giving me is a hosted Chinese model, I can probably get that cheaper elsewhere.
Exactly this. And there are few bigger targets than Chrome when it comes to finding exploits (OSes and network equipment are probably on par). I'm sure they have devoted large compute resources and human staffing at making sure that they find and fix these issues before anyone else does.
I completely agree. With everything from Out-Of-Order execution, deep pipelines, SIMD, huge CPU cache, etc... I would be surprised if the performance increase is not considerably more than 1024x.
Exactly - or encrypted payloads hiding inside standard image file formats. Basically steganography. If all you want to send is a small encrypted text message, it should be possible to hide that in a large image (encoding in the LSB or whatever) in just a small percentage of pixels so that it doesn't fail statistical tests and is indistinguishable from real noise.
I see this slightly differently. Before, if I wanted to be able to do something like flash firmware onto some device I would have to download some random C++ application and install and run it on my local machine. As well as having access to all of my USB devices, it also had access to everything else on my system's user context. I didn't have a way of running that code and only giving it access to a single USB device and nothing else. Now, I can avoid installing anything at all. I visit the project page and opt-in to some flashing flow that's running in a sandboxed env. When the app requests it, the browser asks me for permission and I get to choose exactly which USB device I want to give it access too. That's picking exactly the minimum "outside" access I want to give it, nothing more. It doesnt get to read/write other USB devices I didnt choose. I doesnt get to read/write to my filesystem. It doesnt get to call system APIs. It doesnt get to set itself to start at startup. It doesnt get to install an auto-updater. For me, this is a better security posture than installing random win32 apps.
I really like the minimal approach you've taken here - it's refreshing to see this built completely from the ground up and it's clearly readable and for me, very educational.
But help me understand something. BarraCuda does its own codegen and therefore has to implement its own optimisation layer? It's increbibly impressive to get "working" binaries, but will it ever become a "viable" alternative to nvidia's CUDA if it has to re-invent decades of optimisation techniques? Is there a performance comparison between the binaries produced by this compiler and the nvidia one? Is this something you working on as an interesting technical project to learn from and prove that this "can be done"? Or are you trying to create something that can make CUDA a realistic option on AMD GPUs?
So, this certainly was a valid argument. But it seems to me that the whole value proposition behind these agentic AI coding tools is to be able to move beyond this. Are we very far from being able to define some Figmas and technical specs and have Codex generate the UIs in 5 different stacks? If that isn't a reality in the near future, then why should we buy AI Tools?
It's possible to build an identity system that can assert certain properties about a person (eg. "older than 16") without revealing any other details about that person. Similarly, it's also possible to build such a system where the identity system can attest these details without knowing which website is being accessed. That way, the social media site (or whatever other "adult" service) can validate the user is old enough, while the identity system doesnt track who is using what.
Doesn't Apple have an ARM "Architectural License" arising from being one of the original founding firms behind ARM, which they helped create back in the 90s for the Apple Newton. That license allows them to design their own ARM-compatible chips. The companies they bought more recently gave them the talent to use their existing license, but they always had the right to design their own chips.
It's interesting to think that Google's Antigravity is a forked version of MSFT's VS Code, which uses a browser engine built by Google, which they forked from Apple, which they forked from KHTML.
I would have expected that consumer GPUs still have higher volume, but that Datacenter GPUs have much, much higher margin and therefore significantly higher revenue and profit. Is that not the case?
It also seems like a really bad decision from Slack's POV.
1) They should know that this is unaffordable for a nonprofit like this. By doing this, they will almost certainly lose them and their thousands of aspiring teenage developers as users. The chance of actually booking that 200K are next to 0.
2) Microsoft learned a long time ago the value of getting young developers using your software to learn. Once those teens start working, maybe starting their own companies or choosing which tools to use at their future empoyers, if they know Slack they are very likely to pick Slack. This is a very short sighted shakedown attempt that wont work in the short term but will drive people away in the medium term.
JSON Web Tokens are part of the JSON Object Signing and Encryption (JOSE) family of standards which are really just containers for cryptographic primitives in a web-friendly representation. Most people are aware of JWS (signed payloads) but there are also JWE (encrypted payloads) and JWK (key payloads). If you're building any sort of cryptographic system that needs to represent encrypted/signed values or keys, you can use JOSE to represent these primitives without having to reinvent the wheel. By far the biggest use of JOSE is in authentication systems where JWS are used as signed bearer tokens but that's just one application and there are many others. They arent perfect, but they filled an important gap when they were created and made it much easier to deal with crypto at an application layer compared with all of hte binary formats that are used in things like TLS.
Enterprise customers often have split tunnel VPNs or proxies (with PAC configs) where part of the traffic may go through a VPN and another part goes directly. So for example a customer admin might configure an app that does email and webRTC so that the real time traffic (media and the associated signalling) goes directly and the email traffic goes via some TLS intercepting proxy for some compliance reason or DLP. This can result in one application having multiple public IPs for different network requests, even while they are on one internal network (not even jumping between networks like you say). That isnt something that the application author can control, it's the customer admin that decides to do that.
Whenever they have, they have been bought by larger and richer (mostloy US) tech companies. Look at Deepmind, Skype, Nokia, Tandberg, etc... Arm is another (although Japanese rather than US-owned). There are also many cases where European founders base their companies out the States for access to higher funding (eg Stripe, Spotify). Another factor is that US multinationals have a large presence across Europe in terms of employment - if a large component of the top tech talent of Europe is employed by US companies then they are less likely to build large European companies.
I agree on a level that SQLIte is a master class in testing and quality. However, considering how widely used it is (essentially every client application on the planet) and that it does get several memory safety CVEs every year there is some merit in a rewrite in a memory safe language.
I don't think dual core was that rare in 2007. Conroe was released the year before. For gamers, dual core was the standard at that point (at least from what I remember of the time).
Apart from various nuts and bolts optimizations (eg not using locales, better cache friendless, etc...) it also uses a novel algorithm which is an order of magnitude quicker for many floating points tasks (https://github.com/ulfjack/ryu).
If you actually want to learn about this, then watch the video I linked earlier.
> Not all pieces of software are created equal. A desktop CAD application that doesn't do any networking and doesn't manipulate sensitive user data isn't worthy of binary exploitation. If there is adequate security at the system OS layer, at worst it will corrupt a user's file.
That software is almost certainly running on a network-connected machine though and likely has email access etc.. A spear-phising attack with a CAD file that contains an RCE exploit would be an excellent way to compromise that user and machine leading to attacks like industrial espionage, ransomwear, etc...
Well, maybe at an API and prompt level. But if Google pull ahead in this space then you may become dependent on what it alone can do functionally. Even if you can trivially switch LLM and prompt, if the others aren't able to do something equivalent (or at the same level of quality) then you're still locked in. Until now we've basically had this situation with OpenAI.
Sure, but what's the point on building a product on top of a stable API that exposes a technology that won't evolve because it's actual creators have imploded? It remains to be seen whether OpenAI will implode, but at this point it seems the dream team is t getting back together.