Apparently EWS which makes sense. ActiveSync is for mobile and EWS is newer compared to MAPI (which is an API technically), although there is a protocol that maps this to RPC for the Exchange case.
Are you sure it's not Microsoft Graph? (did you find this in the docs somewhere?) The end of life of EWS has been set in stone for 2026[0] (although it's been implied EoL for a few years) seems futile to invest in an expiring service.
What's the difference between an API and a protocol? From my understanding, if a developer publishes an API or a protocol spec, I can use that to retrieve data from their server either way
API is documentation for MAPI.DLL in this case. It is useless under non-windows system and requires this DLL, which is, effectively, Outlook backed.
Network protocol between MAPI.DLL and Exchange server newer was published (but partially revers-engineered).
And I've participated in project which uses MAPI.DLL, it was buggy as hell, and we delayed product release for whole year (!), trying to workaround all bugs. It was complete disaster and failed product too late to market.
I would expect an API is a set of things one could call, and a protocol is the sequence of things that one must, should, or can do in order to be in compliance with what the other party in the protocol is expecting to happen
HTTP is a protocol because one cannot just socket.write whatever bytes they want and have any good outcome, whereas socket.write is an API that is available in a hypothetical library
Yep, I was using MAPI as shorthand for both RPC MAPI (which was traditionally used inside corp networks, where port 35 would be open) and RPC-over-HTTP.
There's also a JSON-based web services API that is, as far as I know, unpublished (which OWA and I think the "next gen" Outlook uses).
It‘s not totally separate from MAPI because it inherits a large amount of the legacy baggage. A compliant implementation will need a very similar object model, in particular most of the properties, streams and encapsulated formats are also transported through EWS.
I wonder how it deals with things like MAPI (which still forms internals of Outlook and Exchange) not actually supporting HTML email[1] despite having a message for it (and Outlook being infamous for pushing HTML email in minds of many)
[1] If you include a HTML Email message part in a MAPI store, the MS MAPI library explodes and declares the store unreadable. You have to wrap HTML in RTF and include it in RTF message part... ¯ \ _ ಠ _ ಠ _ / ¯
Back when I had Comcast (and thus native IPv6 at home), this was a great way to expose a web server at home without resorting to either weird port forwarding or setting up a proxy + SNI. Both of those work, but this is super clean.
Even using something like Hurricane Electric, this is still a nice solution to get access to services hosted on a residential connection. Feels a lot cleaner to me than weird reverse tunnelling solutions.
“We consider any data received that helps inform an improved future build of starship a success. From a milestone standpoint, our main goal is to clear the pad. Every milestone beyond that is a bonus. The further we fly, the more data we can collect.”
False. Check the linked press release in my parent comment - the BTFP is available to all banks and allows them to use their under par assets as collateral for loans at par from the Federal Reserve.
“
Borrower Eligibility: Any U.S. federally insured depository institution (including a bank, savings association, or credit union) or U.S. branch or agency of a foreign bank that is eligible for primary credit (see 12 CFR 201.4(a)) is eligible to borrow under the Program.
“
I'd say it's bailout-y to value collateral above market value, but isn't totally free money and we haven't seen all the terms for it. At least the Fed is safer holding long term bonds than anyone else.
Fair. Thought you were talking about making SVB depositors whole.
I’d call the BTFP a mechanism to stabilize the banking system in the US, given rising interest rates. I guess I don’t care as much about the semantics, though.
It wipes out losses accrued up to March 12, 2023 on eligible securities, for one year. It's taxpayer funded. Terms are super generous: only a 10bp premium. It's at least a bailout for one year. It may or may not get extended.
I do think it's somewhat clever. It basically lets the private banking sector control the pace of QT. If liquidity dries up somewhere in the system it does a one-year targeted QE.
Unfortunately there are 2 serious drawback to this:
1. Non replaceable/rechargeable battery
2. No support for directional tracking using U1. It’s just the standard find my networks Bluetooth beacon and the ability to emit a sound. Not the local directional finding available with AirTags.
yes, it is 2.4 mm thick, vs an ordinary ccard that is about 0.8mm thick - so the thickness of three credit cards, not exactly meeting the no-bulge goal
The Cross-Border Listings team (within Amazon's Selling Partner Services group) is looking for qualified devs who want to work at scale on the core of Amazon's retail flywheel. We work on systems that have a huge, direct impact on Amazon's business, serving selling partners who sell on Amazon all over the world.
Our team values work-life balance, and we prioritize work that keeps that balance in place (e.g. automation, tech debt). Our standups are almost always less than 15 minutes, and we don't do meetings on Fridays.
Tech stack is Java, JS/TypeScript, AWS.
Location is preferably within reasonable driving distance to locations above, but willing to consider candidates anywhere in the US. Also: open to candidates who might want to commute to Detroit from Windsor (this is niche, I know!).
I am the direct hiring manager of these positions. If you're interested, apply to either of these positions:
Yeah, these job descriptions are pretty generic--I didn't write them! If you have questions, please reach out to me directly: first_3_letters_of_my_HN_username@amazon.com
EDIT: I mostly drive between Grand Rapids and Lansing, and I haven't looked in a while, but there are actually a lot of fixed cameras on major highways now, even outside metro areas:
The public information is an afterthought. Cameras on plows are a liability thing. Plows often hit things they simply cannot see, stuff covered in snow. But after a collision is is very hard to determine what if anything was under the snow prior to impact. There is no way to really avoid this problem while still plowing. So cameras protect the city/state/driver by showing what things looked like from the driver's perspective. That the streams are shared with the public is a bonus.
My city has two persons in the cab, one is the driver, one is the spotter. The spotter really just calls audibles on the stuff they see.
It's cheaper to hire that spotter than pay the insurance for single operator scenarios.
We can get some heavy snow days, the kind that make everything come to a standstill until things are cleared by these hulking beasts (kudos for naming one plow "hulk"). Having access to this information would be awesome.
Not surprising the home of the motor city would (appear) have their road clearing under control.
Most terrifying moment I ever had a car was passing a plow+sand trailer on the colloquial highway (BC). He was plowing the right lane and I was following semi trucks passing in the relatively clear left lane. Right as I got beside the plow's trailer it jackknifed 45 degrees away from me. I though we were all going to die in a huge pileup. But it turned out to be one of these. I had seen them many times. I had never seen one engage the second plow while going 60mph. I did not know they could do it on the move.
That's exactly it. The unfortunate truth about the operators is they're under intense pressure to perform under harsh time constraints.
They're out there before the snow falls, during the snowfall and until the snow is off the road operating essentially a multi-ton switchblade in darkness where everything is hidden beneath an opaque blanket of frozen water. And your vehicle (before the blade is attached) is as wide as the lane.
The visibility conditions are bad, the road surface is bad (that's why you're out there!) And your boss is remotely monitoring your every movement, questioning every work stoppage as if stopping for a coffee, or to take a dump is going to bankrupt the economy. Even operating 'just' the sidewalk plows seems super stressful.
I have had close friends who were the spotters for 40-year veteran operators, it seems like a huge rush that (despite all these challenges) could be kind of fun.
it being an afterthought is, imho, what makes it so excellent. the attitude of "we collected this data, might as well make it public" is exactly how governments should operate.
MnDOT offers similar services (plow and fixed cameras, along with lots of other traffic information) for Minnesota as well: https://511mn.org. If you're really bored, it can be fun to track incoming snowstorms across all of the fixed cameras in a certain direction!
Ehh, the RCOC speed cameras have been open since the early 2000's. I don't think they have the resolution nor the bandwidth for ALPR, but they're supremely useful for checking traffic. I get more from a visual than from colored streets on a map.
"because then the citizenry will know how surveilled they are and they might put pressure on politicians to curtail our ability to buy cool tech without voersight"
"we'll just downgrade it from 4k to 1080p and we'll only give them access to half of them"
the "Transportation" name for those fixed camera systems are "Rwis" (Road Weather Information System) stations. Definitely check them out before you highway drive but also be aware that changing weather conditions can make roads slippery or otherwise dangerous.
The plow cameras and sensors (plow position, salt/aggregate activity, etc) are more useful for transportation operations staff to know what's been plowed and what still needs plowing but technically do take pictures of the whole highway instead of just the rwis stations.
Worked on this one some time ago[0]. Webcams are a big reason folks come to the site. Clicking on the "Princeton" icon get you a popup of the current image and clicking on that gets you the detail page[1]. On the detail page there is a "Replay the day" button which will "card flip" the images for the last 24hrs to give you a sense of what conditions have been like (no time machine yet :-) ).
Site went live back in 2005 with the current look appearing around about 2009 (memory is getting fuzzy).
Baseline network activity on a typical day ran about 4 MByte/sec continuous; on "snow days"[2] the load increases an order of magnitude to 24 MByte/second. That was 5+ years ago - I expect there's been growth since then.
I actually used one recently. My wife was caught in a traffic jam due to an accident/car fire. I was able to actually find a visual of her car on the highway from my laptop. She had our baby in the car who was screaming and I was able to narrate what was happening with the accident - which gave her enough time to change a diaper while stopped and then get safely back in the driver seat before traffic started moving.
If you like tqdm, it's worth checking out pqdm, a parallelized version. If you have embarrassingly parallel work to process in a script, it makes it dead simple to parallelize and monitor the progress of something. Highly recommend:
+1 for PQDM, I use it a ton and most of the time it just works. I did have some rare cases where PQDM was much slower than a direct joblib implemention, but that could well be a fluke on my end. Either way, amazing package!
My current issue with tqdm is nested progress bars in multi-threading/processing causing dead locks + tqdm.write just being broken in those contexts, either deadlocking or the ui just being wrong. Does pqdm do a better job?
The app and car communicate directly over Bluetooth for a number of functions, like lock/unlock, popping the trunk, and starting the car. This outage didn’t affect that (I drove my Model 3 during this time period).
You can start the car over the internet, too, but this is not typical, and the app actually warns you when you try to to do this.
Finally, the Model 3/Y have backup keycards that Tesla encourages you to keep with you just in case your phone dies. The app tells you this when you first pair your phone.
Yeah this article is complete bullshit written for clicks, like most other modern journalism. I have an $83,000 Audi e-tron. The app to unlock and lock the car, as well as remote start has not worked since they did a “back end upgrade” in July and Audi engineers can not figure out how to fix it.
There are no articles written about how “Audi users locked out of cars since July” since that doesn’t pass the sniff test but when you bring up Tesla all logic goes out the window.
I use this for developing on linux/pi/jetsons, (need to test linking against real libs, and cross compiling for some reason still isnt a thing), but the compile times are terrible...
I wish this was even more modular so we could have a dumb compile farm, +local ide +run&debug on-device
(I've recently got 90% closer by remote sshing with vs code to a pi vm)
There is not one single “Exchange Protocol”. There’s MAPI, EWS, ActiveSync, and more. Anyone know what this uses?