If it’s any consolation, this is the first issue of its kind in the multiple years we’ve been using CS. Still unacceptable, but historically the program has been stable and effective for us. Hopefully this reminds higher ups the importance of proper testing before releases
This occurred overnight around 5am UTC/1am EDT. CS checks in once an hour, so some machines escaped the bad update. If your machines were totally off overnight, consider yourself lucky
I’ve never had Rosemary chips but now I desperately want to try some
https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/DOS/CTRLC.ASM
; The user has returned to us.
So ominous.
; Well... time to abort the user.
Goodbye
Mine is already talking about this news in a negative light. Makes my life easier to bring in opentofu
I saw Windows subsystem and panicked thinking it was the Linux version. Did not know an Android variant existed, that’s a bummer
If there’s an option on the AP to not permit link local routing within a vlan/ssid, that will force all traffic up to the firewall. Then you can block intrazone traffic at the firewall level for that vlan.
I’ve seen this in Meraki hardware where it’s referred to as “client isolation”. Ubiquiti might be able to do this too.
This is what I use for clips that I need to upload to friends. The Windows Xbox DVR saves the last 3 mins of gameplay, but I only need 15-30s of it.
This trailer and the feelings it evokes will always be in my mind. It may just be a bunch of clips and speeches overlaid with amazing music but damn is it perfect.
You do have to add flathub to the discover store, but that’s a one time thing and you’re good afterwards
Even better if you can get into a family plan with friends
Robit, mimicking how Zoidberg calls Bender sometimes
It’s the same kind of deprecation you get with apps requiring a newer Android version. If Google adds new features to Android Auto that Android Nougat (7.x) can’t handle, then your apps won’t have any better time either. Likewise, if Google updates Android Auto but an app stops supporting 7.x and earlier, then that app will certainly break down the road.
Are you using a phone from 2017 or earlier? If not, you have nothing to worry about. If so, I’m surprised it still works.
The article topic only affects phones with Android Nougat and earlier. If you’re on Oreo or later (8.0+), you’re fine. This has nothing to do with the car and everything to do with the phone doing the screen projection.
Adding on to a bit from your comment that I missed, it’s not affecting the car itself. The article should have used the word “phone” instead of “device”.
All Android Auto is a screen for your phone that also hooks into car buttons. Your phone does all the hard work with projecting data to the screen. If your phone is too old, Android Auto might not work because apps don’t work properly with the base framework by Google.
You can use a new phone on an older car that officially supports Auto/CarPlay. That’s never been a problem.
If you don’t update Android Auto, maybe. Apps still rely on the framework that makes it work, so you are likely to have those break if they use features that Android Auto didn’t have at the update freeze.
The version they’re cutting off is really old, relatively speaking. You have to be on Oreo or later (8.0+), which came out in 2017.
Many apps you would use Android Auto will likely bump up to this break point soon. Waze, for example, is 7.0+. You’re bound to run into issues being on Nougat or earlier soon, if not already.
This looks to be Google ending support for the Android Auto framework on older Android versions, that’s all. It’s not about the car, it’s about the phone.
Judging by the article and the code snippets found, it’s more about updating your phone rather than the car infotainment hub. Nougat is getting the axe, have to be on Oreo or later.
It would have been better if the headline said “phones” and not “devices”, but that’s not as panic inducing :P
Short answer, likely yes. It’s not definitive, you could still slip by after sending enough mail, but you are also very likely to get whacked because that VPS IP doesn’t have an email sending reputation.
Longer answer, email gateways like Google, Microsoft, and Proofpoint don’t really care who owns what IP. Well, they might, but they’re more concerned about the sending habits of an IP. While you might send good mail from that IP, there’s no reputation for it, so you could be whacked for having a neutral reputation (the ol’ credit score dilemma but for email).
In order to have a good reputation, you have to send a large volume of messages very gradually over several weeks to “warm” your IP as a reputable sender. I went over this slightly more in detail in another reply, but this article is pretty concise on how an enterprise accomplishes this with a dedicated IP at a provider like SendGrid: https://docs.sendgrid.com/ui/sending-email/warming-up-an-ip-address
There is nothing you can do about the unsuccessful logins to your email address. My original email address has been in so many hacks and it’s always being brute forced by hackers outside the US.
You already have MFA, so the only other thing I can think of is to have an incredibly long random password on your account and make sure the “forgot my password” recovery flows don’t have any easy way to bypass. Things like another email address as a backup that’s less secure, being able to guess your personal details based on past hacks, easily guessable/researchable security questions (make these random or nonsensical if possible, or don’t put details from security questions in social media) could be used to gain access, even with MFA. And finally, secure your password manager in a similar manner.