Low-voltage detection is usually implemented as simple comparator which should trigger instantly, but often only on a single Vcc pin, and due to the decoupling caps found on a typical circuit design there is effectively an RC circuit that filters short fluctuations of supply voltage. So most low-voltage detection implementations only trigger on 'longer' periods of low voltage.

Traditionally low-voltage detection features (like brown-out detection) are there to guarantee functionality of the uC itself or the device the uC controls. It is typically not intended as a defence measure against these types of attacks. In fact, 15 years ago it may not have been much of a concern.

[0] https://www.youtube.com/watch?v=MhJoJRqJ0Wc

I recommended them giving this employee a larger monitor, not only would that be much cheaper than having me rebuild the entire UI, it would also boost this employee's productivity. Not to mention that swapping a monitor takes 10 minutes, changing a UI probably weeks.

Customer insisted to change the UI, because "if we give him a new monitor, everyone in the office will want one". I nearly got fired for responding with "Great! Then everyone can benefit from more productivity!".

In the end we did change the UI, I believe the total cost was something like 30k. The customer had maybe 15 employees, so new monitors would still have been much cheaper.

A few months later their offices were remodelled with expensive designer furniture, wooden floors and custom artwork on the walls. Must have cost a fortune. In the end, the employees still worked on ancient computers with 15" monitors, because new computers didn't fit the budget.

It is my understanding that the A18 CPU is pretty well understood already. AFAIK it doesn't have the new architecture that is keeping the Asahi team from supporting the M4 and M5 for example.

But I guess we'll have to wait for devs to get their hands on a Neo device

Also, FWIW: Hector/Lina is no longer associated with Asahi anymore.

How are they going to fund 7 years of support for a device that sells maybe a few thousand units? How are they going to guarantee they will still be around, and interested in maintaining the device drivers in 2033?

The Linux kernel project will remove the device drivers from the mainline kernel if they are no longer actively maintained and in use. So it is very likely that the support will be dropped from the mainline kernel way before 2033, as there probably won't be any users of this device remaining, and the original developers long gone.

Call me negative, but I expect that this company wil just vanish after some time. The team will just move on, maybe even start again under a different name, but there will be nobody to be held responsible for promises and claims they made in the past.

You don't even have to fully shut down you dev machine, you can allow it to go into stand-by. For that it needs to be wired by cable to LAN, and configured to leave the NIC powered on on stand-by. You can then wake up the device remotely via a WOL magic packet. Maybe this is possible with WLAN too, but I have never tried.

Also, you don't need a Tailscale or other VPN account. You can just use SSH + tunneling, or enable a VPN on your router (and usually enjoy hardware acceleration too!). I happen to have a static IP at home, but you can use a dynamic DNS client on your router to achieve the same effect.

One day I got a call from him saying that our 'mutual' customer had an urgency job. They were supposed to do a national roll-out of a new payment system, but seemed to have forgotten about a bunch of legacy PoS systems that were still operational and couldn't easily be replaced. Because I was seemingly the only one that was still familiar with this particular system (I worked on it once in the past), the end-customer approached my friend whether I would be available to do this quick. This was in late November, and the rollout was planned for Januari. Because this end-customer is a government org, I realised we'd be guaranteed they wouldn't be working during the holidays (which, in my country is typically 2 weeks for Christmas and new-year's), so really we had only 10 days or so to get it done in time for their team to test it before they holiday shutdown.

I didn't feel like doing such a complex job on such tight deadline. So, I quoted a much higher rate than normal. I also quoted for a multitude of hours that I thought was required, due to the typical overhead that this large end-customer would surely incur. Finally I also added a retainer fee, because I knew that if problems would occur (likely on the last day before the rollout), I'd have to drop anything I was doing and work for them.

I got the job.

I worked feverishly to meet the deadline. I cancelled commitments on other projects, paid an extortionate amount for testing hardware and overnight delivered to my office, bought very expensive testing gear, signed all the NDA's required to work on PoS card payment interfaces, etc. I then worked basically round the clock for 10 days straight to get it done. I did get it done in time, submitted the code to the repository and fired an email to the team-manager that it was in fact done a day early. ...I was greeted with an auto-reply the manager would be on holiday till mid-January, which was the week that entire new payment system had to be rolled out nation-wide.

I wasn't feeling great about it, but my friend urged me to send the invoice for the work I had done, and also the retainer for the rest of December and January. This would allow the customer to write of the expenses in the current calendar-year. I sent the invoice, it was the most amount of money I'd ever invoiced, and I'd normally invoiced per month, this was for a mere 10 days.

December passed, no response from the supposed review team. I stayed on stand-by, declined any other work, stayed sober during the various new-year's office parties, always brought my laptop along, etc.

January came and went. Still no response from the code review team. The new payment system was due to be rolled out mid-january, but nothing had happened. The company had done extensive ad-campaigns beforehand announcing the new payment convenience for their end-users, so the only 'feedback' I saw were frustrated users on Twitter. I still felt bad about charging for the retainer.

This kept going. At some point I did stop sending invoices for the retainer. My friend always paid me in advance (the end-customer was notoriously slow to pay, though did always pay in the end), and I didn't want to cause him too much exposure.

To my knowledge, the software I wrote was never used in the end. To the public it was stated that the PoS systems were simply too old to be upgraded (not true, obv) and that they'd replace them 'soon'. It is now 4 or 5 years laters, the old PoS terminals are still there, sans the functionality I added.

By pure coincidence, years after the job I found out that an old friend of mine, who was also a freelancer at the time, was tasked around that same time by the same customer to do a code-review of a supposed PoS system upgrade. Without realising, he reviewed my code! He was under the same time pressure, and did the code review during Christmas to deliver the results on time before the national rollout in mid-January. He also charged a huge amount of money for it, was also paid, and also never heard about it again. At least he said he remembered being impressed by the quality of the code, and didn't find any defects. So that's about the best outcome of the project I guess.

My takeaway from this: If you are a freelancer, and a large customer wants something done in a hurry, charge more than you ever dared, don't feel bad about it. You'll find that suddenly there isn't as much of a deadline anymore. If the customer declines due to the price, you should be happy for dodging a bullet.

Eventually every smart TV becomes dumb when they inevitably shut down the backend services.

I've had a very similar problem with my cable internet circa 2010. It must have been DOCSIS 3.0. Multiple times a day my connection would stop working completely. The modem's 'connected' and 'carrier up' and 'carrier down' lights were on, and I had LAN communication with the modem, but no data would pass though on the WAN side.

From the management page of the modem (I later learned you weren't supposed to know about) I could see the upstream and downstream carriers were correctly established and still operational, but on the IP (PPPoE) level the TX (upstream) packet counter was increasing, but the RX (downstream) packet counter did not. Releasing the IP on my router (remember, it was PPPoE), then waiting 10 minutes or so before renewing the IP via DHCP would bring connectivity back.

I would call to my ISP (the largest ISP in my country) to try to resolve the issue. Every. Single. Time. I had to explain to the support employee that yes, I did disconnect and reconnect power, yes, my computer's software was up to date, yes, I did try connecting via LAN directly to the modem to eliminate any possible router issues, etc.

Now, at this point in the story I should point out that I held a degree in electrical engineering, specialising in embedded systems and high-speed data transmission and also had just about all Cisco networking certifications. I was more than qualified to design cable modems myself, imagine the frustration wasn't able to fix this issue.

One night I came home to the same problem, called customer service again, fully prepared to do the 'dance' of answering every basic troubleshooting question. But to my surprise, the guy on the phone seemed legit knowledgable. When I described him the symptoms I saw from the modem's management page he was rather surprised that I managed to discover that functionality, but said he knew what the problem would be then.

The support employee was quickly to confirm that someone in my neighbourhood hard-coded his IP-address instead of allowing DHCP (a common trick back in the day to get a static IP on a residential cable connection), and that that IP was clashing with the IP their DHCP would assign to my router's MAC address. He asked me what brand of router I had, and had to explain to him that it was a self-built OpenBSD box. His response was: "great! then you probably know how to spoof the MAC on your WAN interface then?". I did, I changed my MAC to a value he gave me, and immediately my connection came back up. He explained me that any MAC address starting with AB:BA (named after the band) was reserved for a special block of customers with this kind of issue.

We continued chatting a bit about DOCSIS, networking technology, modulation types, OpenBSD (it was also his favourite OS) and much more nerdy stuff. At some point I asked him, respectfully, how someone with his knowledge ended up at the support helpdesk of an ISP. He then told me he was the ISP's CTO, in charge of all network operations, and that he was just manning the helpdesk while his colleagues were on a diner break...

Nothing against Bind9, but it is almost exclusively maintained by the ISC, so the DNS's future used to depend heavily on the ISC getting the funding needed to continue operating.

Cloudflare also delivers a rather large portion of said public infrastructure free of charge. They also released a few of their own projects as FOSS, and regularly contribute.

Granted, the centralisation part worries me too, but it feels like a bit of a cheap shot against CF just because they are a large player.

My Lenovo X1E regularly burns 20% of its CPU cycles on some high frequency recurring interrupt. I did get pretty far with debugging it, but eventually gave up since I can't justify spending so much time on fixing a 'professional' laptop that I paid top dollar for.

It also has a multi-GPU setup that has never worked reliably under Linux, which is ironic as I opted for Lenovo due to its supposedly good Linux compatibility.

Switching between GPU modes is a hit or mis, waking up from stand-by often results in a blank screen, screen flickering, sporadic high fan speeds, etc. And then there's the coil whine, which seems to be fixed in some BIOS versions, then returns in the next. Supposedly it has something to do with power-saving measures.

Since I owned it there have been at least 20 BIOS version releases for 'improved performance and security', but none seem to actually fix anything. It's such a mess.

/rant

I'm not familiar with the formal account takeover process at Google, but my best guess is that the attacker simply requested an account takeover via the official Google process, which triggered this email to be sent by Google legitimately. By reading back the code in that email, the attacker was able to claim the Google account as theirs, thus access the Gmail inbox to reset the Coinbase password and access the authenticator backups from the Google Drive.

I would be very curious to see the original message headers of the email though.

Yes, SPF (the original design) is horribly broken and trivially bypassed. The most prominent design flaw is that the inbound SMTP service uses the SMTP (rfc5321) MailFrom address for SPF validation, which is not the same sender address shown to the recipient, they can only see the the message (rfc5321) 'From' header address. SPF originally didn't require the domains in the MailFrom and From addresses to match, so an attacker would simply use a domain they control in the MailFrom address, and the 'spoofed' domain in the From header.

That was in 10 years ago though. DMARC fixed this by adding the alignment requirement, meaning that the domains in the MailFrom and From address must match. By default the alignment policy is 'relaxed', meaning that the MailFrom and From domains can differ in subdomain, as long as they share the same organizational domain. Setting the SPF alignment to strict (aspf=s) like you mention in your post requires the domains to match exactly, with no subdomain differences allowed.

So, it doesn't matter that Google doesn't use strict SPF alignment in the DMARC policy, the fact that they have DMARC already adds the requirement to SPF validation that the domains must match.

Yes, google.com and gmail.com use the same IP ranges in the respective SPF policies, but Gmail will never allow you to send email addresses from a domain that you do not own. This is why domain validation is required when you set up Gmail with a custom domain.

The only scenario where your explanation would hold up, is if the attacker was able to gain control of the DNS of a subdomain of the google.com domain, and successfully validated it as a custom domain in Gmail, then send emails from that subdomain in rfc5321.MailFrom address and the google.com domain itself as the rfc5322.From domain.

Example: I once convinced my employer to donate to some open source projects we relied on. They did, then few months later they got slapped on the wrist by the authorities for not being able to prove where these overseas payments were going to, and that these payments weren't used for funding terrorist activities.

Similarly, I used to contribute to an OSS project, we did get asked by some corps to do paid work like bug fixes or features. The problem was that they required invoices in order for them to be allowed to pay us, so we needed to register as a company, get a tax number, etc. I was a freelancer at the time, so I offered to use my business registration to be able to invoice, then split the profit amongst the contributors. Then the very first paying 'customer' immediately hit us with a 20-page vendor assessment form asking about my SOC2 or ISO27001 certifications, data security policies, background checks of my 'employees' etc. Then I got confronted by my accountant that distributing the payment amongst other people would be seen as disguised wages and could get me into serious legal problems.

Granted, this was some years ago, things have gotten better now with initiatives as Github Sponsors, KoFi and Patreon. But at the same time legislation has gotten more restrictive, doing business with large corps is difficult, expensive and very time consuming. It's not worth it for most OSS maintainers, and similarly it isn't worth the legal headache for the large corps to make these kind of donations.

I politely refused, of course, but I did ask why we'd even want that. The reason was simple: we receive government funding to do 'educational stuff', and kids like computer games, right?

Having employees (or volunteers in our case) to educate visitors during all opening hours is a massive challenge for most museums, so an interactive screen/game sounds like the logical solution to ensure the funding is approved each year again.

I hear the same thing from other musea that we collaborate with. Reality is that these systems are broken more often than not. Typically designed on a budget by an external developer, who is no longer employed or paid to maintain it. Employees/volunteers don't understand how the system works, so the screen just stays off.

https://github.com/openbsd/src/commit/ee2db53800abe0382657ec...

I think that is where the difference is.

The buy-vs-rent discussion is more aimed at first-time buyers. If you already own a property that is largely paid off and has had the benefit of appreciation over the time you owned it, then yes, it may be more beneficial to keep the property, as you have seen from the calculator.

If the answer was always that rent would be cheaper, then the calculators wouldn't have to exist ;-)

> housing cost would almost DOUBLE

Except that you will now have the profits from selling your previous property, which you can invest. That investment payout can partially or even completely offset the cost of renting, which means your monthly costs will be much lower.

Say you make 500k by selling your house, and invest that against 6% ROI, then you make 30k/year passive income, thats 2.5k/month. So deduct that from the rent you'd pay and compare again.

You mean the backslash? What's wrong with that?