- ansgriIn general I agree, but too much resilience can lead to worse infrastructure. Where I live, a couple hours of unannounced electricity outage every week is a non-event, so wires are patched in more and more points. And there's little motivation to invest significant money and time once to replace them by something more robust.
- Probably the one type of PHEV that should survive is basically a BEV with builtin backup generator. One that's not necessarily powerful enough to drive you directly at full speed, but enough to basically eliminate range limitation of a (cheaper and smaller) battery by continuously charging it when needed. Maybe this 'backup generator' can even be made as a removable option.
I'm thinking of a semi-rural use case, when your typical daily trip is 20-50 km, but the charging infrastructure is poor and occasionally you do need to drive 200-300 km in winter.
- There are now quite a few options for wifi APs with cellular backup. I use TP-Link, and it's ok for the price, I guess, and supports adding OneMesh range extenders.
The problem with this setup for me is that it doesn't work with uplink that sometimes becomes unstable yet nominally working, and in general LTE fallback triggers slowly.
Are there any prosumer-friendly options for connection bundling, which can balance uplinks continuously?
- Probably has more to do with responsibility outsourcing: if SaaS has security breach AND they tell in the contract that they’re secure, then you’re not responsible. Sure, there may be reputational damage for you, but it’s a gamble with good odds in most cases.
Storing lots of legal data doesn’t seem to be one of these cases though.
- For me the most annoying would be a technically correct solution that completely ignores the “higher-level style” of the surrounding code, at the same time defending the chosen solution by referencing some “best practices” that are not really applicable there for some higher-level reasons, or by insignificant performance concerns. Incidentally, LLMs often produce similar problems, only one doesn’t need to politely argue with them.
- Compressed jsonlines with strong schema seems to cover most cases where you aren't severely constrained by CPU or small message size (i.e., mostly embedded stuff).
- There should be two dark modes: a simple dark mode, like most dark themes today, to work in dimmed lighting, and an actual night mode, designed to be legible but not mess with adaptation in total darkness. I don't know the research on this (and I'm sure military and aviation have lots of data here), but intuitively it should use mostly thin red and green lines.
- Typical web image quality is like it is partly because of lack of support. It’s literally more difficult to show a static HDR photo than a whole video!
- Mint/Cinnamon has been my favorite for at least 5 years, after an assortment of KDE/Gnome distros. Basically the only argument for me being on Mac now is full Adobe graphics software support. (I dislike their business practices as anybody, but Lightroom CC is genuinely good tech, and gets useful updates at least yearly).
- This is probably due to most software working with graphics somewhere (GUI, printing), and font sizes and resolutions are predominantly imperial (pt/dpi).
- Luckily there are still the extra snouty breeds like Belgian shepherds and various sighthounds.
- A bit off-topic, but denoise in LR is like 3 years behind the purpose-built products like Topaz, so a bad example. They've added any ML-based denoise to it when, like a year ago?
- from cursory reading of the article I don’t see that author’s problems are specifically with Grafana in its best use case (metrics), but with other products from Grafana company, for which are a lot of alternatives.
Grafana dashboards itself (paired with VictoriaMetrics and occasionally Clickhouse) is one of the most pleasant web apps IMO. Especially when you don’t try to push the constraints of its display model, which are sometimes annoying but understandable.
- In abstract case, you'd probably want to use xy color coordinates from xyY color space to specify LED color. Or even wavelength + spread, as you've tried. Those were the models that were used in one microLED-related research project I was part of.
Using those in images however would be another can of worms, you'll need some kind of physics-based rendering with good HDR tone mapping, as the human perception of light-emitting object against reflective background is highly non-linear.
For your use case it would probably be better to develop a standardized testing setup and just take RGB or XYZ coordinates from an image taken with a calibrated camera. Something like this:
* "standard gray" material surface
* a hole for LED with some kind of light pipe of standard shape
* uniform diffuse lighting of intensity computed to be proportional to your LED power measured in a standard way.
In this way it should be possible to create a catalog of LEDs useful for designing products.
- One of the problems seems to be that most moderately complex companies where any one system would be fine with Compose would want to unify their operations, thus going to a complex distributed system with k8s. And then either your unified IT/DevOps team is responsible for supporting all systems on k8s, or all individual dev teams have to be competent with k8s. Worst case, both.
- For certain definition of realtime, certainly (as would any system with bounded ingestion latency), but it’s not low-latency streaming realtime. Tens of seconds or more can pass before new data becomes visible in queries in normal operation. There’s batching, there’s merging, and its overall architecture prioritizes throughput over latency.
- Isn't the Online part here about getting results immediately after query, as opposed to overnight batch reports? So if you don't completely overwhelm DuckDB with writes, it still qualifies. The quality you're describing is something like "realtime analytics", and is a whole another category: Clickhouse doesn't qualify (batching updates, merging etc. — but it's clearly OLAP), Druid does.
- I wouldn’t be surprised if many construction sites have no way to get reliable internet connection without adding complex infrastructure: think of an underground parking with poor cellular coverage even on surface (in a country without Starlink support for extra difficulty).
- The issue with color to grayscale conversion for human consumption is in most cases there is no well-defined ground truth. People don’t see in grayscale, so the appearance preservation approach doesn’t work. And the source image was most likely heavily color corrected to match certain aesthetic. So the problem becomes “to preserve as much information, both content and aesthetic, within constraints of the target grayscale medium”.
The bottom line is, use some standardized conversion (like described here — just to avoid surprising users) if images don’t actually matter, some contrast-preserving method if content matters, and edit creatively otherwise.
- Also it has a proper builtin flashlight which is surprisingly useful. Amazing watch, especially if you get a comfortable aftermarket strap e.g. from Hemsut.