I have been using a 55" 8K QE55QN700BT ($1400) at home since Jan. 2023 and a 55" 8K QE55QN700C ($1100 on sale) at the office since August 2023.
I can tell you that I will never go back, but there is definitely room for improvement.
Biggest negative: Sitting close (~12"), the far areas are probably at >45° angle (and TV colors are not great at angles)
Eye strain is ok (lowest brightness & low contrast), but neck strain is a thing (which I never had before, but now I think my neck muscles start to be trained and it's getting better).
Price is amazing, compared to 4x 4K
Refresh rate 60Hz: not for ego shooters (but great for work)
I didn't think it was possible, but at work I operate an 8k, 4k, and a full HD screen from the same graphics card (i need the other screens for UI testing)
Glossy is not great (no matte TVs on the market)
Even at 12", I operate Windows at 175% scaling, so I still have pixels to spare. Next TV will be 65" :)
At the beginning I thought it was a failure, until I found the correct settings combination: TV Gaming Mode, disable all AI image gimmicks, set the correct refresh rate in the NVidia driver options (at first everything was extremely sluggish, until by chance I saw that the refresh rate was set to 30Hz by default). I also remember playing with the V-Sync settings until finally I didn't see visual pixel artifacts anymore. Now the quality is the same as my 4k monitor.
Work colleagues just can't see it... (just like they laughed at the 2nd monitor, and then at the 3rd, and now most use 3 monitors).
No hassle with monitor arms. Such set it on the table and done.
Microsoft PowerToys FancyZones is amazing to divide the screen into areas
Next: TCL unveiled the first curved 8k 65" TV, that's where I'm going :)
I saw your reddit comment, but I couldn't find the source for the TCL 65 inch? For me im tempted to go from 43" 4k to 55" 8k, my only concern is the edges being too far away unless its curved.
12" viewing distance?! It sounds like you should be spending more at the optometrist and less at Best Buy. I cannot even imagine sitting that close to a screen--don't you have to turn your head just to see both sides of a document?
It's probably more like 18" currently. I don't know, what's your reading distance to a book page? I use FancyZones to dividede the screen into 3 vertical areas (like having 3 monitors). For coding and longer reading periods I use the middle area. But yes, to look at the side areas I have to turn my head or even slide the chair a little. The angle could be better, like I said.
Regarding reading distance: For me the important part is to sit straight and avoid hunching. Choose a combination of distance and screen scaling factor that works for you...
> In my career, I have taken a particular approach based on building new systems from scratch
= Software consultants and free lancers. I don't like them because I am jealous that they get to do greenfield projects and make all the architectural decisions but never actually have to maintain their own creations (and therefore never really learn how to design a system for changeability and maintainability).
> What can we do about this state of affairs?
1st: be aware of these laws and that keeping a 20 year old system in production is a non-trivial task and to be proud of every additional year I can keep it running.
2nd: Instead of seeing it as a 'DoS attack on myself by previous developers', I try to see it as a neverending Sudoku that challenges and stimulates and pays me every day.
"2nd: Instead of seeing it as a 'DoS attack on myself by previous developers', I try to see it as a neverending Sudoku that challenges and stimulates and pays me every day."
This is how it is for me, I've had a great time with several business systems initiated by amateurs or mediocre developers that took hold and had been going for 5-10 years when I arrived. Yes, the WTF:s are everywhere, changing these systems is really hard and takes a lot of discipline and care, but every time you put something in production you'll also have made other parts of the application better, more robust and faster.
To me that is really rewarding, and not even noisy, butterfingered management can stop you from littering the commit log with lovely little improvements that incrementally turns the turd into a much more stable income for them, and possibly yourself (and if not you jump jobs after a while and get the raise then). I don't care whether they appreciate my work, first I care about practicing my craft well, second I care about how it is perceived by my peers in the craft.
Of course, this isn't a reason to make crappy software on purpose, but this kind of just happens when you on the cheap test an idea against a market and it flies really well and customers flow in.
Agreed. Many years ago I spent two years on a greenfield project that got slowly but surely worse, which was very frustrating. Now I'm working on something that's seven years old and has been through a lot of hands, but every small improvement feels good, and when I need to do the occasional hack, I don't feel bad because on the whole it's better than it used to be.
If I can extend it a bit: sometimes when you start a new job, the board state you inherit is actually subtly invalid (i.e. it will lead to an unsolvable solution), and you have to figure out the smallest number of numbers to "erase" to end up with a valid board state.
You get to realistically use the eraser maybe once per year, because nobody likes erasers. So you just compensate for it with lots of notes!
Re money systems: I have found that problems arise no matter whether floats are used or something else: The system can be too exact.
My current approach is that I try to guess (or ask) how a customer understands or checks a statement/invoice. The customer usually takes a calculator and enters the rounded numbers they see. I then try to do all programmatic calculations exactly the same way: Operation - round - operation - round etc, with rounding-steps at exactly the same places where these values will be visible to the customer, and with the same number of decimal places (can vary). Sometimes that is not possible of course, which is usually solved with a final row called 'rounding errors in the customer's favor').
For my (smaller) systems I find floats sufficient and easier to work with compared to the alternatives, which tend to make code very verbose and annoying to read.
I thought "money systems" always worked in whole units of some fraction of your currency, e.g. "millicents" or similar, and shunned floating point arithmetic like the plague.
> The system can be too exact
Indeed, high precision, low accuracy! Fixed-point arithmetic can be both precise and accurate if everyone agrees on the same system. Maybe we don't, and that's the problem?
IBM partially has a hold on banking because they have supported decimal floating point. By switching binary floating-point from radix 2 to radix 10 (decimal exponents) they get rid of some of the problems.
IEEE has had these Decimal types for a while, but IBM is the only company shipping CPUs with them.
Fixed decimal is still used where appropriate, but Decimal floating point is a critical feature for some processes.
While personal taxes typically drop the cents, tariffs and other taxes are often small percentages as an example.
There are software implementations if you don't need performance.
But Decimal64 has a lot more represented values and it is easier to trap on some edge cases.
As Decimal floating point types were added into C23 we will see if hardware support follows.
Note this is also why HP calculators were more accurate for a given bit size, because the engineering ones used radix 10 floats.
What does radix 10 floating point bring to the table in terms of precision other than a whole new set of rounding problems?
As far as I know, all accounting systems use 'round to nearest cent' integers (or whatever the lowest denomination is in a given currency). Is there a case where calculations using integer cents is in any way inferior to radix-ten fixed point?
In Europe, after MIFID II, equities are priced with tick sizes (i.e. the minium whole unit) that depend on the magnitude of the price, i.e are de-jure (decimal) floating points that behave weirdly.
money systems work with whatever tool is convenient to the operations staff which these days is typically Microsoft Excel and Visual Basic, neither of which come with a built in Decimal type.
this will typically get transmuted through multiple layers of javascript, xml, back end java, cobol, SQL, python, some domain specific language, and back again.
reply