A year or so ago I bought a Hisense 65U88KM, which comes with Google TV. During the setup procedure it asked me if I wanted to enable the "smart" features, such as Google TV, the camera and microphone, or connect it to a network. I said no to all of them, and that was that.
Now it just acts as a dumb screen for my Apple TV box.
I did the same with a Sony A80L, which also runs Google TV. I even uninstalled the bundled streaming apps for good measure, although I never see the home screen.
It behaves like a monitor. I never see the TV UI unless I ask for it.
My LG could be configured to behave like this (and believe me, I am thinking about going that way).
I have a cheap FireTV which cannot be made to behave this way. If you disconnect it from the internet, it will still require you to interact with the (slow-ass clunky) OS in order to select a different input.
Your best case scenario with some of these smart TV's is the ones which run Android to replace the launcher. Possibly, this gets reset periodically, meaning you have to keep doing it.
Apparently there's a few Fire devices which can be flashed with LineageOS - I might try researching that and see if it is doable. A FireTV stick with LineageOS would be the best case scenario.
I find that most of those reset to some nonsense occasionally or whenever the power goes out. I make sure they have no internet connectuon, but I usually have to dig up the remote to get back to hdmi1 so my device interface will come back up. I accept the annoyance because I accepted the discount that they give to have all of the spyware crap on there that I am blocking. I wish they could sell something cheaper that is just a display, buy product managers will be product managers.
Brian Haidet (Alpha Phoenix) shows how he made a video of a laser beam travelling across his garage. From his description:
I'm using the technique from the electricity waves video where I used repeated oscilloscope measurements synced after the fact to produce "videos" of electricity moving down a wire. The only difference is that instead of measuring electricity waves, I'm measuring light emitted by a laser, bouncing off the wall, traveling to my camera, and landing in the window of a photomultiplier tube.
The January 16, 2024 edition of the CBC radio show "As It Happens" has an interview with Gerry Vogrincic, the doctor who bought the book in 2007 and just sold it.
There's a transcript of the interview here [1]. Search for "Old Anatomy Book".
The audio for the entire episode is here [2]. I don't recall how far into it this interview occurs. (I've sometimes found their interviews split into separate clips, but if that's the case here I don't know where to find it.)
I write and review medical software. When I'm reviewing code the most important question is, "Is it correct?" If it's not, then the review simply isn't approved (obviously).
Anything that makes it harder to determine correctness is a strike against the code. This can include anything from high level organization, to comments, to the naming of variables, to the use of whitespace. For example, with respect to variable names, if you're implementing something that has to conform to the DICOM standard, then you should consider following their nomenclature, even if it may not be what you'd normally use in other contexts.
Aside from correctness issues, I'll make anything from "strong recommendations" to "mild suggestions". (In theory, any of these could cause me not to approve a change, but the closer we get to "mild suggestion" the less likely that is.) Examples might include:
- You're trying to do something with X. I'm a domain expert in X and while your code is technically correct it's not idiomatic. I suggest doing it this other way instead.
- You added a public function to a library, but it will fail if the String argument isn't a valid Photometric Interpretation. Yes, I see that you only call it with valid values, but since it's public anybody can now call it, and they may not be so diligent. How about making it an Enum?
- You have a loop that, superficially, looks like it's calculating Bar, but upon closer examination it's (correctly) calculating Bar'. How about adding a comment stating this, so that no one is tempted to (incorrectly) "fix" it?
- You've implemented a function that does Y. All our code links with the Foo library, which happens to have a function that does Y. How about using that instead?
- Your log message makes sense if you're reading the surrounding code, but someone from support seeing it in the log file won't know what to make of it. How about including this contextual information in it?
- In the loop that you added, your indentation is inconsistent with the rest of the function. How about making it the same?
- Why do you have four blanks lines in the middle of your function?
In my own code I'm pretty anal about formatting, comments, log messages, use of whitespace, etc. I'm definitely less harsh when reviewing other people's code, but I have to admit that when I see sloppy formatting, grammatical errors or gratuitous use of whitespace, I'm on the alert for sloppiness in other areas, such as design and implementation.
Now it just acts as a dumb screen for my Apple TV box.