epcoa

> Honestly, maybe there's some truth to that, but it sure flies in the face of the sanctity of voting and "democracy."

Although some choose or have to squawk loudly about it, the sanctity of “democracy” is not universally or even widely accepted.

To extend the Winston Churchill quote, it’s mostly a charade but it’s the best one we have (in my opinion).

You mean the pads? Those are the connection points for the wires that connect to the external package pins.

The fallacy is it’s a leap from logic to go from “average error is x” is the same as “is x late”. Seeing the exact transition is often if not more useful than minimizing average displayed error.

The DC had double the VRAM (and 4MB on the PS2 was paltry) and hardware texture compression, texture quality was better, and the analog video output path was better and most games run 480p vs 480i. 480p on the Dreamcast looks better (an advantage that most North American consumers using the included composite cable would not have been able to appreciate). All said, indeed it was not vastly superior.

Correct, it's E1M9, the shareware secret level, on Nightmare difficulty.

You can strafe with the old-school chording of Alt.

The sound was fucked up for me, high pitched, no idea why (fits the ridiculousness of this experience though, so NBD).

The PS2 released more than a year later in Japan, and while only a few months after the DC in North America, but straddling the holiday season, so essentially the following year. But the announcement seriously gimped the DC launch.

I love the Dreamcast, own multiple, started hacking with KallistiOS back in the day, it has much more significance to me than the PS2, but it’s just not the case that the hardware was vastly superior. It’s no slouch, there are aspects that are better. The GPU had some neat tricks and more VRAM+HWTC was nice, you get better image quality, but it was plainly bested in most of the metrics that mattered more, geometry, lighting and fill rate, and most people did not use VGA out at the time. The “Emotion Engine” is absolutely ungainly compared to the elegance of the SH-4 simply tied to the PowerVR and AICA, but you simply can get more out of it both in raw FP/SIMD (geometry) and DMA. Simplicity of architecture doesn’t matter to the vast majority of gamers. Some of the early titles looked like shit due to the difficulty of leveraging the hardware, but look at the longevity and late stage PS2 games (especially Konami), quite beyond DC capabilities. And a DVD was objectively superior to GDROM (and it made a good movie player).

The Xbox was released after Sega already shitcanned the Dreamcast, its fate was sealed before.

Sony overstated the PS2 capabilities, but it did have DVD drive and the graphics were better after developer learned how to use it, it had strong franchises and simply more S tier ones. The Dreamcast was too arcade port heavy. The Dreamcast simply got fucked in the winner take all market at the time. Maybe if they released in 1998 with a larger library they might have had enough run way.

Well I would be very interested in some of this, but it all seems theoretical and mythical. Seriously, what terminal is giving 20% better battery life (or whatever number that people will notice) than kitty.

How can I observe any of these claims in practice? You’ve put some down some bold claims about how things should be done but no way to verify or validate them at all. Put up with some real power benchmarks or this is just crack pot.

> To get over 12 hours of battery life out of a 60 Wh battery - which isn't impressive nowadays with laptops rocking 20+ hours

I used 12 hours to be nice. The sell of getting another 10 minutes or so out of 20 hours is even more stark.

The cases where you push a line and scroll, you're repainting most of it anyway. The cases where you're not are end up being infrequent enough that optimizing them in the ways suggested makes an unnoticeable impact. Build it and they will come maybe?

> Bigger GPUs than your iGPU (or even just later iGPUs) will also likely see even bigger impacts.

In most cases people can get by with an iGPU for a battery laptop cases. If you're in a must pull down more graphical power case, you're often plugged in and few care about 10s of milliwatts then.

> (As an aside, I am not a fan of kitty - they have really weird frame management and terrible recommendations on their wiki. Foot, alacritty or if ghostty turns out good, maybe even that would be better suggestions. Note that comparing to foot can give a wrong image, as CPU-based rendering pushes work to the display server and gives the illusion of being faster and more efficient than it really is.)

Once again, what is the exemplar of an efficient terminal then. We've already established ghostty doesn't operate the way you think it should so how can it turn out good?

> The issue is that you keep the power-hungry shader units on, whereas when truly idle their power is cut.

Even in the most perverse scenario of a single cell update the load for a terminal is still bursty enough that it's not like the GPU doesn't enter some power saving states. Running intel_gpu_top in kytty with a 100ms update is at least suggestive, it never drops below 90% RC6 (even at 50ms, which is a completely uselessly fast update rate we're still in the high 80s). If you're updating faster than 100ms legitimately, it's probably video or animation that is updating a large percentage of the display area anyway. The overall time my terminal is doing some animation while on battery is low enough that in practice it just doesn't matter.

https://en.wikipedia.org/wiki/Amdahl%27s_law

The problem you're up against is that, maybe if this was optimized most people would get 2 or 3 (or even 10) more minutes on a 12 hour battery life or something. No one really cares. Maybe they should, but they don't. And there's plenty of other suck in their power budget.

You make it sound like a binary power saving scenario, but it tends to be more nuanced in practice.

Most people run their terminal opaque, most display systems optimize this common case.

> Also, if you do damage tracking, make sure to report it to the display server

I'm not unsympathetic to your point of view. But I am skeptical that the power savings for most use cases ends up being much of a big deal in practice for most people (even accepting there may be some annoying edge cases that annoy some). I am interested in this topic, but I am still awaiting an example of a GPU accelerated terminal emulator that works this way to even make a real world comparison.

Perhaps that came across wrong, no shade intended, what was meant was that ghostty seems to be like all the other mature GPU based emulators. Which means there's no damage reporting to a display server or anything like that. I don't think it's quite the deal breaker the GGP implies.

While they’re only now coming out with even a 5GHz model there isn’t really much in Apple’s product line that needs a lowend primarily “IoT” WiFi. Maybe the HomePod, but they already have better chipsets for their flagship devices.

Well it sounds like ghostty is like all the other major GPU terminal emulators (unless you know of a counterexample) and does full redraw, though it appears to have some optimizations about how often that occurs.

The power issue might be true in some cases, but even as foot’s own benchmarks against alacritty demonstrate, it’s hyperbolic to say it “kills performance”.

> Missing damage tracking, always painting everything (even when the window is a full 4k monitor),

Out of curiosity, what GPU accelerated terminal does this.

“Recovering” an otherwise error free journaled or logged filesystem is considered a normal operation. Unclean just doesn’t mean an error. That’s how this works and I don’t see very many interested in changing this behavior.

It probably looks ok on HiDPI, unfortunately a lot of these hipster tools not supporting legacy but well trodden text rendering implementations are LoDPI unfriendly. https://github.com/zed-industries/zed/issues/7992

The commenter did not expound on any specific evidence that would suggest a bacterial lung infection. 2 weeks of malaise and non specific upper respiratory symptoms is not strong evidence of a bacterial pneumonia, sorry.

For external infections, observation by visible inspection is still evidence, a sign, not a symptom. So, not sure what your point is. Erysipelas is invariably diagnosed by signs, not symptoms. Very rarely are bacterial infections diagnosed by symptoms alone.

> get antibiotics unless you absolutely need them.

Yes that’s exactly how it should be. They are not at all benign misprescribed.

> Even when I had a lung issue for 2 weeks I had to beg to get antibiotics.

Was there any evidence of a bacterial infection or did they just give in? 2 weeks is not a long time for a viral respiratory illness either.

> I can afford to go to a nice doctor

If your doctor is giving you antibiotics for clearly viral illnesses they are doing a disservice to you, it isn’t actually nice. It’s not like I’ve ever seen some systemic withholding of antibiotics when they are clearly indicated - quite the opposite, some of the worst areas for resistance are the poorest. They aren’t without other side effects, resistance being only one.

Also you have it backwards, the racist thing to do is to just prescribe the antibiotics, since they are dirt cheap, cost me (the provider) nothing, and makes the person whose skin color I possibly don’t like get out of my office faster (if not racism, pragmatism to see too many patients). Racism alone is not necessarily the only explanation, but antibiotic over prescription/use tends to be associated with poverty.

Well run antibiotic stewardship is a conceit of the most affluent health systems.

Are those herbs actually evenly distributed though?

I do not understand, average wattage/power would be integration of wattage (joules) divided by time (so back to watts), it’s still watts? Under what implementation would you end up with joules that isn’t just oddly broken in general?

I guess I could see a naive implementation (confusing integration/sampling and discrete summation) going the other way, erroneously ending up with a nonsensical W/s.

Also don’t understand what it has to do with eponyms, which are just substitutes for base units, either your DA works or not, no? Average wattage is kg⋅m²⋅s⁻³ not kg⋅m²⋅s⁻² (joules) or kg⋅m²⋅s⁻⁴

Ok, until you can sue the AI you need to find a doctor ok putting their license behind saying “I have no idea how this shiny thing works”. There are indeed some that will, but not a consensus.

By smuggling and bias I meant in an ML model. Smuggling was a bit informal, but referring to models overfit on unintended features or artifacts.

> complex systems where lots of data exists

Not a lot of high quality data exists for human health. Clinical guidelines for many diseases are built around surprisingly scant evidence many times.

> even if they're so complex no human can understand them?

That’ll be wonderful to explain in court when they figure out it was just data smuggling or whatever other bias.

It really isn't that much though. A 1200x1200 DPI monochrome image on Letter size (not even considering margins) paper is on the order of 16 MiB uncompressed. And bitmaps of text and line art compress down heavily (and you can use a bitmap atlas or prerendered bitmap font technique as well). It’s also usually easier to upgrade RAM in a printer than a crappy firmware.

> most printers still render fonts and such internally.

Many printers have some scalable font rendering capability, but it is often not usable in practice for high fidelity. You absolutely can raster on the host to either a bitmap font, or make use of the PDL's native compression. Most lower end printers (which is pretty much the bulk of what is sold) do not have the capability to render arbitrary TrueType fonts, for instance. A consumer/SOHO level Canon laser using UFRII is going to rely on the host for rastering arbitrary fonts.

Oh I knew that was coming. This interesting but ancient piece of trivia just illustrates something about how slow micros were back then. It’s not like printer don’t have more and multiple CPUs today. Not like whatever poorly written outsourced to India “managed” shit and other features are going to run on a potato. Whatever is driving the color touch LCD on even the Walmart econoshit is many times more powerful then that 12 MHz 68k.

Still have no idea what the GPs point was. You can just as easily run a raster on the host, if it has bugs it has bugs, where it lives doesn’t matter.

Further rosetinting is of course that LaserWriter was $20k and it’d be a decade plus before a monochrome dropped under 1. I’m gonna guess the Canon with the shitty drivers is 10x cheaper and faster.

> Text layout doesn't need to be done when the source is a PDF.

PDF isn’t entirely a panacea, since it’s complex enough that printing any random PDF isn’t trivial at all, but sure, close enough, but before you were talking about Postscript.

> Make printers do the PDF and let Adobe control trademark access via conformity tests and life is good.

PDF printers aren’t all that uncommon. So why doesn’t your Canon do this? These aren’t technical issues at all. This is an economic/financial problem as mentioned (doing business with Adobe!). This isn’t about part cost, a CPU 100x more powerful than the one in the LaserWriter is nothing.

Text layout is hard and unfortunately drivers and firmware are often buggy (and as printing is lower and lower margin that doesn’t get better). But just throwing a weird language engine in doesn’t actually solve any of those problems.

Unless you were using anything from that tiny obscure Hewlett Packard operation and didn’t want to shell out for a module. HP never promoted Postscript. It was far from universal as an embedded PDL.

> that throwing a real CPU in the printer was a mistake.

The CPU in any decently modern printer is still many times more powerful than what was in an original LaserWriter (30ppm and up needs power, even if it’s simple transforms and not running wankery). It’s not just about CPU power and modern laser printers still support PDL and vector languages like PCL and PDF (and many have some half assed often buggy PS “compatibility” eg BRScript), the bigger mistake is using general purpose Turing tarpit that is “powerful” rather than a true high level built for purpose PDL. PostScript just isn’t very good and was always a hack.

> Send PostScript, done.

The other problem of course being that raw PostScript as a target for most applications is not at all elegant and ironically too low level. So even if you wanted postscript, an OS that didn’t provide something more useful to most applications was missing core functionality. The jwz quote about regexes applies just as well.

It's just an ugly ass syscall extension mechanism (so it has no direct equivalent in Linux lets say), it definitely looks bizarre in modern times.

Int 2F is initially handled by DOS as a stub, but additional programs (like drivers and TSRs) can override INT 2F, put their bucket of functionality and then fallback to whatever the previous installed handler was (called chaining) for whatever they don't handle.

This gives a glimpse into how much various crap could end up installed as an Int 2F handler: https://www.minuszerodegrees.net/websitecopies/Linux.old/doc...

It was often used for feature/presence checks and usually nothing time critical as that chaining setup was most definitely not timing friendly.

What do you mean by “HAOS on docker”. HAOS is a standalone complete Linux system with its own fully managed kernel, not meant to be containerized. It uses docker internally itself though and “pass through” works transparently.

If you’re talking about running home assistant in a docker container, sure you’re more on your own, but since official home assistant in HAOS must run in docker, none of this is terribly difficult to configure.

The dongles are usually exposed as tty devices and I’ve been running zigbee2mqtt and Zwavejs addons in docker containers for years with no issue. HAOS takes care of stable naming (based on default udev rules) out of the box.

Unlike system virtualization, there isn’t really anything that needs passing through, it’s a naming and permissions issue - the container just needs an appropriately permissioned dev node ideally with a stable name. If you are using official addons it is effectively zero-config, and if you’re not, sorry but I don’t find the configuration to ensure a dev node to be anything but straightforward container config.

As someone else mentioned it may be as simple as:

  devices:
      - /dev/ttyUSB0:/dev/ttyUSB0

But you can just as easily use the /dev/serial tree to have stable names. Those names come out of the box with udev. You can always make your own too, I’ve done it, it’s not hard.

HAOS uses docker to containerize everything, so it can’t be that difficult, and it really is not. Docker has a —-device flag for this purpose, udev makes it easy enough to assign stable names.