I absolutely hate it, can't understand how that's all they offer (or Google SSO). It's bad enough when the password option is just really hidden and non-obvious (like Notion iirc), not having it at all is ridiculous.
I don't have that email account on my phone. So to log in, I have to open my laptop, get the 'magic' link, find a way to send it to myself on my phone that doesn't make a request (e.g. for an unfurl) expiring it, and then open it on my phone to log in. So magic.
If you open login form and link on different devices, you'll get code to type, no need to send link.
So basically you start login on phone, keep page open. Open laptop, click on link on laptop and you'll get a code. You type that code on your phone and that's all.
There are a number of clipboard sync apps, but personally I swear by simply having an E2E encrypted chat app on both your desktop and phone that lets you send messages to yourself. Serves both the clipboard usecase and as a general "notes to self" space.
I requested Mythos access and was granted it. But now apparently I need to use Google Sign In on my account instead of email link, as email link is not secure enough. But my email is not google, it's my custom domain. Now I don't even know what to do. I don't want to buy google apps or whatever it's called just to be able to use Google SSO with my custom domain; and I don't want to register completely new account for gmail either. It's a mess.
Usually it is the weakest link in the chain, and you are encouraged to switch to proper 2FA or Passkey instead. So even if the email is compromised, other accounts are not compromised.
It's better they don't because considering how Claude reacts when you give it a meaningless SSH login password for a local box, the moment it learns your CC# and CVV2 it will probably call your bank and cancel the card instead of ordering any food.
OpenMP is arguably in a better place today than it was ten years ago. For instance, MSVC added support for newer OpenMP standards and implementations now support genuine device offloading. Indeed, OpenMP is probably the most popular parallel programming interface for C/C++/Fortran in use today.
Sure, OpenMP is not a pretty API, nor is it likely to yield best-in-class performance. But OpenMP is highly portable, it enjoys first-class support GCC and LLVM/clang, and it’s very straightforward to get “good enough” performance with minimal code changes. Personally, I think it’s wonderful.
Others want to nitpick but generally yes, before we had AI, the last craze was cloud, so they shuffled things around to the point that everything was "cloud". This is also how Oracle got to be the biggest "cloud" in the world!
I mean, a lot of people before them were "not in the model business" (Cursor et al) and it seems they got disintermediated by the model companies. Step 1 is still to have the best model, or hope for model progress to taper out.
Vertical integration is hugely valuable, but revenue comes from the top of the stack, not the bottom.
Apple makes great margins on hardware. They are 100% not in the CNC milling business. But their investments at that low level and vertical integration allow for higher margins at the top.
Cursor had... nothing. A minor, indefensible value add to a much larger and wealthier supplier.
As the evidence from software programming shows, a lot of white collar workers spend most of their time talking frankly because they are inept at execution.
Good and bad moments, honestly. GitLab would benefit massively if they went back and deleted all of the crap they added during their "feature checkbox craze" years.
Just looking at the left menu, "Secure" "Deploy" "Operate" "Monitor" "Analyze" "Auto Devops" and all this crap urgently needs to go and get out of peoples way.
And, dare I say it? There is a place for GitLab in a world where most development happens with coding agents. Its perfectly fine to be the version control & CI place. But they got stupid management (just like Atlassian or GitHub) that have convinced themselves they must be the orchestrator, the middleman, the gatekeeper to inference. They neither are nor will be that and if they go down the path of Copilot trying to ruin their product to make it happen, it will be the end.
Unless you plan to assign your Ethernet expander a domain name, how do you expect it to participate in WebPKI? The vendor similarly has no interest in explaining its buyers how to do that so it can connect "securely" to their particular alarm monitoring service.
There are some goodish options for how we could secure communications with local network devices hosting simple configuration WebUIs, but the browser vendors have overwhelmingly demonstrated that they have no interest in any of them. So what you ship is HTTP, not even the self-signed certificate, that just gets scary messages.
(What the browser vendors seem to want, to be clear, is that your gadget reaches out securely to the Vendor Cloud^TM, and you similarly use your Google and Apple notarized smartphone to reach out to that same Cloud, so you can talk to the hardware sitting a meter away from you)
> Unless you plan to assign your Ethernet expander a domain name, how do you expect it to participate in WebPKI?
Well, it does support DDNS, [1] so presumably some people do assign it a domain name. But I don't expect it to participate in WebPKI necessarily. That's not the only way to secure communication from the config program to the device, e.g.:
* The routers I worked on in 2006 had baked-in keys/certs signed by our own CA with cn based on serial number rather than reachable customer-chosen FQDN. That's not WebPKI but it actually works. Elk's configuration software knows the expected serial number and could use a similar approach. The configuration is not http-based (much less browser-based) anyway.
* It'd be better to just punt and say the communication should be secured by proxy or VPN or something than to offer TLS in a misleading way and suggest it should be directly exposed to the Internet.
As for the Ethernet expander to the central station, that totally could use TLS and WebPKI.
reply