I heard it's been a difficult project to justify spending the research/computer time on at scale, because the models use an equivalent amount of compute for training and inference, but more parallelizable. So 5 times more compute units can be required and they get the work done 5 times faster. On a Google scale, that meant the hard internal sell of justifying burning through $25 million worth of compute units over 1 day instead of $5 million each day for 5 days. Something like that.
Technically Pixel 6 has the pKVM feature too (I have the terminal app from the feature drop when it was added). We're just missing DP alt mode introduced from Pixel 8 onwards
I do wonder if part of it is down to Android default animation speeds.... Pixel 6 here, Gboard snappy enough. Something I do on every android device I own though is go into developer settings and change all the animation durations to 0.5x. Makes stuff seem snappier. In reality I'm sure it's dropping just as many frames as it async loads garbage enterprise uncompressed asset icons or whatever, but hey it shows up on screen 2x as fast!!!!
Edit: oh, no, you have a point about the UI blocking stuff, it's fine when apps are loaded and active but "cold booting" a UI component definitely has lags in stupid places, android UX feels like a web perform sometimes due to that.... Tap button, go on holiday for a week, come back and it's responded to the button press (while you were trying to do something completely different and now you've pressed something else and you're not sure what because this time the button you pressed closed the activity overlay 1ms after)
I noticed that while the website says /kʊtʃ/, wikipedia's page on Welsh orthography suggests that it should be /kʊtχ/ or /kutχ/, Google Translate's automatic audio seems to produce /kotχ/ [not a typo], and the pages on Welsh orthography/phonology together suggest that /tʃ/ should be spelled "ti" [if a following vowel exists, which it doesn't here] or "ts" [regardless of whether a following vowel exists, with examples, both loanwords from English, of "tsips" [chips] and "wats" [watch]].
But I don't know anything more about Welsh than what wikipedia offers. Do you know what's going on with their suggested spelling/pronunciation?
(Wiktionary has /kʊtʃ/ for the pronunciation of the English word "cwtch"; the Welsh word is given with the same pronunciation, but the spelling "cwtsh", which is equally weird as far as the material above goes. The etymology does tend to support /tʃ/ in cwtsh - it's a loan of the English word "couch".)
> it's pronounced more like "cutch" (well, for me it is anyway)
I would have to pronounce "cutch" as /kʌtʃ/. /ʊ/ exists (put / foot / look / nook ...), but there isn't a conventional way to spell it so it's unlikely to be used for unfamiliar words. But /kutʃ/ "benefits" from not being unfamiliar to anyone... and one of the very few things I did know about Welsh is that "w" represents /u/.
> Do you know what's going on with their suggested spelling/pronunciation?
"Cwtch" was/is more common in casual conversation in South Wales (where fluent spoken Welsh is less common, but Welsh words are still used in both English and mixed language contexts). See: https://en.wikipedia.org/wiki/Cwtch for a summary of the cross-language context.
I'd expect English speakers to approximate it with /k/ in preference to /ʃ/. (That obviously can't be done when it's following a /t/, but in that case what I'd expect is to just elide the sound completely.)
I've been interested for a long time in the concept of speakers of different languages disagreeing on which sounds in one language match which sounds in the other language. I don't know of any examples, but do you think it's true that Welsh speakers find English /ʃ/ to be a better approximation of Welsh /χ/ than English /k/ is, while English speakers find /k/ to be a better approximation of Welsh /χ/ than /ʃ/ is?
You pose a great question, perhaps complicated by the fact that pretty much Welsh speakers will also have more-or-less native English (if somewhat Cambricised).
Unfortunately I am merely a Q-Celt and not qualified to comment, though I'd love to see an answer from someone else.
I would venture that if there is a difference it may arise from the relative differences in phoneme classifcation that result from the mother tongue (c.f. linguistic relativity of colour perception). It might even be possible to divine some of those differences by looking at tables of regional accents like those you can find on Wikipedia/Wiktionary, e.g. https://en.wiktionary.org/wiki/Appendix:Welsh_pronunciation
I’ve sometimes wondered if there are any welsh speakers who don’t speak any English at all. My welsh father didn’t learn English until he was about 8, and his mother’s English was extremely rudimentary when she used to speak to me when I visited as a child. This is in a village near Caernarfon where really nobody speaks English on a day to day basis, everything is done in welsh. Naturally nowadays the younger generation is completely native-level in English, just strange to think about that even 70 years ago there were a lot of British people who couldn’t speak English.
Reading through their guidance they don't really mention anything about password strength indicators being a good or bad idea. Sure, they list out a set of rules to verify passwords by and state no OTHER arbitrary rules should be included. But that doesn't prevent you from calculating password strength based on the rules they specify ie. minimum length and complexity.
But I get that "strength" is a poor metric. It shouldn't allow "weak" passwords. It should be binary - pass or fail.
The nicest thing about strength indicators - and I reckon this is why they are copied a lot - is that they are usually real-time feedback to the user with a nice red/orange/green invalid/weak/strong indicator that updates as the user types. The best ones even go as far as show you the list of rules your password is failing to meet, again updating as you type. Much much nicer than the server-side validation form submission loop imo.
So, remove the middle concept of "weak but allowed" passwords from the strength indicator widget, I think then you get good UX that meets NIST recommendations..?
That's inconsistent messaging from Corsair, then. Parent comment quotes the times they're like "ehh, they're same thing, don't worry about it" and then they go on to say "well TECHNICALLY there's a teeensy difference in conductor sizes"???
Either they are confident that the 0.25mm terminal difference is within tolerance enough that they consider 12VHPWR to be functionally equivalent to 12V-2x6, or they're getting themselves confused let alone the target audience of their article.
I think it's unfair this comment has been flagged or downvoted or whatever. It's pragmatic information!
The mobile hotspot thing... I have to do that to do anything involving Okta.
For some frustrating reason my IPv4 address, which I pay extra to my ISP to have, has been blocklisted by Okta. A login flow failure in one of the apps work uses triggered my address getting banned indefinitely is my best guess. My works Okta admins don't really understand how to unblock me on their Okta tenancy, and Okta support just directs me back to my local admins (even though it's any okta-using org I'm banned from logging into).
I get that misuse/abuse detection has to do its thing but it's so frustrating when there's basically zero way of a legitimate user from an IP of undoing a ban. My only recourse is to do all my using of okta from another IP.... If I was a legit spammer I wouldn't think twice about switching to another IP from my big pool, probably.
Thank you, I'm a bit surprised people took issue with my comment but I suppose I could have worded it better.
As for your case, I wonder if Okta is relying on an external service like IPQS to get a score, that could explain why they don't really have any control over it.
Thankyou! I checked with IPQS and my residential IP had been flagged for being "a proxy". I routinely SSH VPN (sshuttle) into my home network to do things so maybe that's why.
I'm in that boat. I'm watching all of Christoph Paar's cryptography lecture series on YouTube -- it was recorded in 2010, so I do wonder if it's missing any new state of the art / best practises.
I'm like 18 lectures in, two out of three semesters. And I still feel like I have only the vaguest ideas what the primitives are, how they work, what they're for, and their weaknesses. I'm having to follow all the mathematics as someone not mathematically inclined (Prof Paar did do a good job of making the mathematics fairly accessible though).
All of this so I can have a bit more confidence in proposing E2E for a project at some point in future (before somebody asks us to, too late).
And my use-case makes it difficult to follow the most trodden paths so I can't just plug in a handshake protocol and MACs and elliptic curves or "just use PGP" or whatever.
As a software dev, I have all these boxes I could use, that come with so many caveats "if you do this, but don't do this, no do that, don't do that"... It's very tricky trying to work out how to glue the pieces together without already being in the field of crypto. Feels like I'll always be missing some crucial piece of information I'd get if I pored over hundreds of textbooks and papers but I don't have the resources to do so!
I'd love if someone did like, a plain English recipe book for cryptography! Give the mathematical proof of stuff, but also explain the strengths/weaknesses/possible attacks to laypeople without the prerequisite that you need to understand ring modulus or Galois fields or whatever first. Or, like, flowcharts to follow!
>As a software dev, I have all these boxes I could use, that come with so many caveats "if you do this, but don't do this, no do that, don't do that"... It's very tricky trying to work out how to glue the pieces together without already being in the field of crypto
Until you know more, strongly consider suggesting the company just hires someone who knows that. Just because you're available to do it, doesn't mean you should just yet.
> Until you know more, strongly consider suggesting the company just hires someone who knows that. Just because you're available to do it, doesn't mean you should just yet.
This is a fair point. We'd always find it difficult to hire someone who was 100% specialising in software security / crypto etc, but a software eng who has some experience would probably be palatable... But funding for new hires could be a couple of years out. That, or we find a way to turn it into a research proposal we can sic a PhD on.
Still, I think it benefits us to have a strong baseline knowledge of crypto systems as a team, "bus factor" and all that. Maybe one day we have a colleague that can teach us that, but until then we may as well crack on with self-teaching :-)
