HN Simulatornew | past | comments | lists | submit | derf_'s commentslogin

Here are the options I have found, targeted at roughly 85" (because that is what I am looking for):

Sceptre U860CV-UMRD: 4k HDR @ 60 Hz(8 ms), 300 nits LCD(DLED), 3xHDMI 2.0 (HDCP 2.2) ACR, OS: None?

Samsung QB85C-N: 4k HDR @ 75 Hz(10 ms), 350 nits LCD(VA), 3xHDMI 2.0 (HDCP ?) 1xACR, OS: Tizen 7.0, AV1 support

LG 86UR340C9UD: 4k HDR @ 120 Hz (5 ms), 330 nits LCD(DLED), 2xHDMI ? (HDCP 2.0) 1xACR, OS: webOS 6.0

ViewSonic CDE86G3: 4k (not HDR) @ 60 Hz(?? ms), 500 nits LCD(VA), 3xHDMI 2.0 (HCDP 2.2) 1xACR, OS: None?

And, because this is HN, even though it is only 65":

Flanders Scientific: XMP651: 4k HDR @ 60 Hz (?? ms), up to 4000 nits QD-OLED, 1xHDMI ? (no HDCP) 4xSDI, OS: None?

I believe none of these have Wifi. None of them is perfect. Only the Flanders Scientific model has an OLED display, but it is roughly 10x the price of the others (this is a reference monitor, which is very much not targeted at consumers). It also only comes in sizes up to 65" and only has one HDMI port, which does not support HDCP at all. If you only need 55", they have a 2000 nit display (V550) that supports regular HDMI inputs (but is still quite expensive).

Of the remaining displays, the ViewSonic is the brightest, but does not have HDR support. The LG display supports the highest refresh rate and is probably the cheapest, but only has HDCP 2.0 (I think?), and runs webOS, which I view as the least trustworthy of the options. The Samsung display is the only one with built-in AV1 support (if that matters to you). They also have some older models (e.g., BE85FX-H), which may still be available somewhat cheaper, but I can find very little information on them. None of the displays appear to support HDMI 2.1 or 2.2, so 4k HDR is limited 4:2:0 chroma at 60 Hz. The ones labeled "OS: None?" clearly have an OS (the ViewSonic one advertises a 7 second boot time, for example, despite being labeled "OS-Free"), but it does not appear to be any of the major known-problematic ones.

I have no direct experience with any of these, so I cannot prove that they are not still spying on you.


Another dimension to consider might just be displays which are easily opened and the wireless hardware removed.

Unfortunately a lot of large displays really aren't safe to open -- you're likely to break the screen doing it. But I have seen some results on LG tvs that have the wireless hardware on a separate removable board that the TV runs fine without.

If the alternative is a commercial signboard display or a reference monitor though one might be better off buying N consumer TVs and accidentally destroying a couple. ... and the question of giving money to companies bundling spyware might be better addressed by spending the price difference funding efforts to stop the practice via other means (e.g. outlawing it... to the extent that its not already unlawful, lobbying state AGs to take action to the extent that it is...).


Just buy a consumer TV and don't connect it to the internet. Remove the WiFi board or desolder the chip if you must. It's better than paying five times as much for a worse display.

I have a Sceptre display, they no longer make or sell TVs.

> I can tell you for certain that when I was connecting to my own website, there was no attacker trying to "steal my credit card."

Of course, no one can actually be certain of this, because any MITM could have injected anything they wanted into the website, including something asking for your credit card (which they would then steal). Plain http is commonly MITM'd to inject tracking and ads, even on an ISP you pay for with money, and has been for decades at this point.

Just because you own the website does not mean you get to choose the threat model your visitors have to operate under.


Does this threat model include knowing where to put credit card numbers and when to refrain from doing so?

If you posted your credit card number to someone's blog over HTTPS, is that any more secure?


Yes, since the set of people who can mitm/steal it is strictly smaller.

Blog operator Vs blog operator + network operator.

It's still not 100% secure.


My point was that if it's a website that doesn't take payments or any personal info then it doesn't really matter if it's HTTPS or not; not that TLS or HTTPS has no use case in absolute.

I guess a better way to rephrase would be, if you go to a random GitHub issue and post your credit card number + details publicly, would it matter if you posted them over HTTP or HTTPS?


Payement is only one of the reason why encryption is important: most people don't want their ISP to know what kind of porn they watch, for instance.

It's not just about the information you supply. You can find accounts of hotel wifi services injecting ads into pages loaded over insecure connections. A MitM lets you inject content including arbitrary malicious JS. With ad networks being what they are, that might already have happened with those injected ads.

why would tom 7 ask you for your credit card number?

This has already been studied in the context of Moore's law [0]. The answer is that if you assume a doubling every 18 months, then any project that takes less than (18 / ln 2) ~= 26 months (assuming a fixed hardware budget) will finish fastest if begun immediately. For a project that takes longer, you should wait until your project will take 26 months to complete with current hardware, and buy your new hardware and start it then.

You can plug in whatever numbers you want for the growth rate, but I don't think there are many uses of LLMs that require anything like months' worth of tokens to generate results at this point. Feel free to slack off if you are one of the exceptions.

[0] https://arxiv.org/abs/astro-ph/9912202


Pro-tip (for both unmarried men and women): You can sign a pre-nup even if you never have any nuptials. It turns out that people can choose to enter into a contract with each other at any time. There are plenty of reasons why people in a relationship may choose not to get legally married, but that does not mean you have to leave yourself at the mercy of the defaults in the law, which may or may not make sense for you.

This is especially important if there are children involved in your situation.


Are you saying there's effectively a pre-commonlaw agreement mechanism available to curtail fallout from even just a drfault commonlaw arrangement?

Pro tip: in Scotland (where the UK gov is taking inspiration from), that likely doesn't override rights in statutes

The law isn't simply a "default" in this matter that you can opt out of AIUI


People on HN are comically unaware of how frequently pre-nups get tossed out in court.

> Once they are a public company this will be actual value taken away from existing public shareholders so they are legit losses not to be ignored.

They reported a loss here because they sold notes convertible into shares and their valuation went up. Normally shareholders do not lose money when the stock price goes up.

It's weird that they had to report it like this because they are technically derivatives, and if they had just given out actual shares (as with stock-based comp), they wouldn't. Yes, giving people stock is a real cost, but what happens to the price afterwards is not, and when the price goes up shareholders are definitely making money, not losing it.

Either way, they did report it. It is up to you to decide how you interpret that information.


I love to see this kind of optimization, of course, but there are other cases where Robison division is great, just because it has basically the same form for every divisor:

1. The divisor is not actually a compile-time constant, but comes from a small set. You can compute a table of corresponding constants and use the same code for every divisor.

2. You want to do many divisions by many different divisors (whether known at compile-time or drawn from a small set, like above, or pre-computable and applied many times... think of something like a quantization matrix for image coding, for example). Here Robison easily SIMDifies, whereas an algorithm that needs different code paths for every divisor is going to be much more difficult.

Regarding the lack of native signed-unsigned multiplies, as someone who does a lot of multimedia processing, I find the set of available multiplication instructions on x86 and ARM to be rather shamefully limited (especially x86). I recall a colleague who used to optimize for VideoCore (the GPU in a Raspberry Pi) saying that when he first started he was astounded that it had 80 different multiply instructions, but within a year or two he had used basically all of them.


I would also add: anyone who started 4...5 years ago. These people received options grants as the market was in its 2022 slump. Since then the stock is up 1.5x...2.4x (depending on exactly when they received their grant), and those grants are reaching the end of their vest. Yes, there are refresher grants, but realistically these employees' total compensation is about to drop off a cliff, if it hasn't already.

That is not the kind of thing that inspires a person to stick around.


> Previously, in C89, left shift on signed integers was completely undefined...

No, it was implementation defined, which is very different. Every implementation you were ever likely to encounter defined it reasonably. Making some of it undefined now has created a bunch of code that uses macros to cast back and forth between unsigned to get the expected behavior (or, for cases where it is provable that the result is representable, to replace the left shift with a multiplication and hope the optimizing compiler translates it back, because compilers now warn on any left shift of a negative value, despite the fact that the semantics are supposed to be the same as the corresponding multiplication now).

In other words, it created a mess for basically no reason.


This is the complete definition of the behavior of left shift operators in C89:

> The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an unsigned type, the value of the result is E1 multiplied by the quantity, 2 raised to the power E2, reduced modulo ULONG_MAX+l if E1 has type unsigned long, UINT_MAX+1 otherwise. (The constants ULONG_MAX and UINT_MAX are defined in the header .)

You notice what's not mentioned there? What happens if E1 is signed. The standard says nothing. And when the standard says nothing, it's undefined behavior.


The behavior at the bit level seems very well defined based on that excerpt. You would need to know how signed integers are defined to know what the numeric value of the result would be. That sounds like it would be implementation dependent, but also completely predictable. Am I missing something?


From the beginning of Section 3.3 (several pages before the text you quoted in Section 3.3.7):

      Some operators (the unary operator ~ , and the binary operators << ,
  >> , & , ^ , and | , collectively described as bitwise operators)
  shall have operands that have integral type.  These operators return
  values that depend on the internal representations of integers, and
  thus have implementation-defined aspects for signed types.


this only warn that there is some implementation-defined stuff coming next, not that all these operator are free of undefined behaviour


> That sounds like shifting the property tax burden from homeowners to renters...

This is all obviously very specific to the locality where you live, but at least where I live, property values were recently reassessed to account for the large post-pandemic increases. Individual homeowners were generally stuck with these reassessments, while commercial properties, especially those managed by large property management groups, were organized and successfully petitioned to reduce those assessments in disproportionate numbers. So the balance of power was not equal to start with.


And, commercial activity tends see revenue follow inflation. And, a business offset expenses.

An individual, could go bankrupt just because the property tax follows its' property value which itself changes nothing with regards to that owner's income.


I don't think it's correct to say "rates were kept low" as if the Fed had a choice in the matter. All the Fed can really do is respond to market conditions. It can be slow to react, and it could in theory be wrong about the market in a way that causes economic damage (in one direction or the other), but it can't really do better than the implied market rate.

Interest rates were kept at historic lows for a decade because the 2008 crisis caused available credit to absolutely implode, which destroyed a huge swath of the effective money supply. Leverage ratios at banks went from north of 40:1 to closer to 10:1. Without ZIRP and QE and all of the rest, we would have had outright deflation, kicking off the kind of deflationary debt spiral that made the Great Depression so bad.

That kind of dramatic destruction of credit did not happen during the pandemic. The banks were fine [0]. What happened was that the economic output of actual goods and services collapsed. So high levels of stimulus led to more money chasing fewer real resources, and you got inflation instead.

This should not have been a surprise.

[0] Modulo a few like SVB that blew up a couple of years later because they had forgotten that interest rates could also go up.


Well also at some point QE would have to unwind, and no one had ever attempted an unwinding of such loose balance sheets before


Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: