• 0 Posts
  • 120 Comments
Joined 2 years ago
cake
Cake day: June 21st, 2023

help-circle
  • The history of large phones, from a technical standpoint:

    • LTE required a lot more power than 2G/3G until efficiencies were improved, this required a larger battery to have comparable battery life, doubly so on the phones that ran two modems (mostly Verizon) one for 3G, one for 4G
    • LTE required larger antennas as their low band frequencies were lower than previous cellular tech. (750MHz and later 600MHz vs 850MHz being the old lowest)
    • Handset manufacturers then stopped making smaller product lines even after efficiencies improved
    • People (“consumers”) realized they’d rather not buy a phone, tablet, watch, computer, anal implant, and preferred to just buy one device, settling on an oversized phone was enough between phone/tablet that they only needed to waste money on one device
    • The market then went, “people prefer larger phones,” even though smaller phones were waning/outliers
    • Tablets outside of Apple’s ostensibly died, although there are a few more choices these days that aren’t Apple
    • Now phones have so many antennae
      • WiFi/BT (which are often shared)
      • WiFi 6 new band
      • NFC
      • Wireless charging coil
      • Ultra Wideband
      • 20 or 30 various cellular bands with 4x antennae for MIMO
      • mmWave (in America)
    • Phones also have gigantic camera systems (although since Samsung gave up on 10x optical, they shrunk slightly on that platform)
    • The cycle repeated itself a bit with 5G, the channels are so wide and huge, they can suck a lot of power when doing large data transfers, and also the addition of needing a separate amp/chip for 5G above sub6 as well as additional cooling
    • “AI” stuff that requires more ML compute, and thus cooling and battery capacity, even though again, nobody wanted it
    • All the metrics and analytics handset manufacturers constantly run on users, disabling all this alone would probably make your average phone last 3+ days

    Since then, more and more people are trying to get flip phones, dumbphones, imported small phones, or giving up on phones entirely and switching to devices like the Lilygo T-Deck LoRaWAN device that has…dun dun dunnnnn…a literal BlackBerry keyboard, as people are sick of that fabled market deciding for them.







  • Season 1 still feels great. 2 gets a bit weird and feels more like a B show. 3 is like shark-jumping, but seeing a timeline jump that shows the now-very-near future is good for some “whoa” moments like, “this is what the continents will look like with sea rise,” but probably feels more like having to work your way through season 1 of TNG.

    Didn’t mind spending exercise time watching all three though.


  • He also apparently watched a lot of SeaQuest DSV, and is trying to make it a reality. Hyperloop: SeaQuest. Electric cars: SeaQuest. Big car dashboard screens: SeaQuest. Magic Space Science: SeaQuest. CyberTruck…Apple Mouse ADB gen 1-ish wrapped in aluminum foil. I guess what I find most fascinating is that I have similar mental maladies to him, but I learned instead of just being perpetually dumb. It is actually disappointing that he chose to not learn and just ride the walrus instead. No idea why anyone worships him.









  • Oh, apologies for my suggestion before seeing this comment hahaha!

    CAN devices I have limited experience with, but I know at least in the automotive industry, vehicles often have various CAN devices that have various sleep states. Like, shut car off, it holds brake system for a few minutes and then unlocks the brakes and that ECU shuts down. Later on, an emissions ECU may run a self-diagnostic. After a few days being powered off, the security ECU goes into low power and turns off wireless doorlocks. After the voltage drops too low, the ECU in the head unit ostensibly shuts down, and the next time the car is started, the head unit has to do a cold-reboot and takes a fortnight.

    Could be one of those CAN devices takes some time to get into the “off-adjacent” state to manifest the bug?


  • Could the time delay in being able to reproduce relate to some piece of code that has a timeout (thinking login timeout, cookie expiration, auth timeout, that sort of thing.) Or likewise, if the computer in question has multiple shutdown phases, like how many computers today “sleep” to RAM, and then an hour later sleep to disk in a more hibernatey fashion and fully power off? (Or some weirdness like how Windows shutdown now is ostensibly a hibernate, but a reboot is actually a full “power down power up” without shutting off power.)

    I like @Buddahriffic@lemmy.world 's take on being wall-clock-based. I once had a bug with some software that would just go belly-up on certain days for no reason whatsoever in a datacenter 2000 miles away. After having worked on some bare metal servers in the past and learned all about thermal issues firsthand, I checked the weather in that region. It only seemed to happen on extremely hot summer days, at the day’s temperature peak. Turns out the datacenter vendor had a cooling problem in that section of the DC and they were unaware of it…

    Crazy sometimes how bugs manifest.


  • There’s a weird obscure bug in M$ Remote Desktop in Windows 11 Pro I spent entirely too much time trying to track down, as a user. (Yes, the first mistake was ever getting near Windows, but anyway.)

    It looks like there is some kind of counter that now exists in number of logged in sessions, and each RDP session counts as a one-time-use session. The local user does too.

    • If you log in locally on first boot, there’s a 25% chance you’ll be able to log in remotely from one machine once or twice.
    • If you log in as a remote user from boot, you’re more free to log in remotely, possibly from two different machines about 75% of the time, but if you just use one other machine, pretty much forever.
    • Rebooting always solves the login issues, so much so that a terrible terrible workaround was employed. Enable OpenSSH server (now included in Windows) on Windows, to SSH into the box (which, reliably works every time no matter what) and reboot it.
    • So many Internets on the topics, including using their old RDP driver, that the new driver may be cranky, that the host graphics drivers may have an impact, that the BIOS OOB management may have an effect. Nothing ever fixed it consistently.

    Thankfully, my life means too much to me to go further down the rabbit hole and I don’t have to use Windows as much anymore, and hopefully soon never, but…its like they took a whole team of engineers to break something that has worked amazing since the early aughts and just firehosed pigeon turds all over it.

    They obviously care enough to keep it working as they renamed the RDP app to “Windows App” in the last year, but don’t care enough to make it work correctly?



  • Now if only Docker could solve the “hey I’m caching a layer that I think didn’t change” (Narrator: it did) problem, that even setting the “don’t fucking cache” flag doesn’t always work. So many debug issues come up when devs don’t realize this and they’re like, “but I changed the file, and the change doesn’t work!”

    docker system prune -a and beat that SSD into submission until it dies, alas.