nalyd

I don't think it's a far fetched statement, but I'm also not sure if it's true.

I know concrete has a pretty big carbon footprint, but, I don't know how that scales in relation to the carbon savings of nuclear power.

Oh for sure, but it'll be easier to cable manage if it's closer to the edge of the board like over by the 24-pin or something, which is probably the real W with this standard.

The party of compromise has been working hard to find middle ground and bipartisan support from people who dog whistle to neo nazis. It doesn't surprise me to hear someone eyeballing the 3rd party route.

Not that I think you're wrong about the math and who will ultimately win if it becomes a serious thing, I'm just not surprised people are getting heated and stoking some fires.

Now

Not surprising tbh, loads of mid-range Android phones do that. They'll implement USB4 in a year or 2 and maybe be the first to implement it in a phone, then talk the biggest game about it at their developer conference like they invented USB or something.

It's pretty cyclical at this point, they're saving a talking point for later

I originally had words about ahead of time compilers like GraalVM but got tired of looking at my own wall of text so I trimmed it down and left compiler to mean ahead of time compulers, which I see caused confusion, you're right on those points.

I know the JVM hardware exists also, but, it's specialty hardware even at the enterprise level. You could technically make an ASIC that executes QBASIC at hardware but I'm not sure I'd believe that makes it a compiled language since it would be neither wide spread nor the original use case for it. That's kind of a philosophical argument though

I think my use of compilers in interpretation may also be confusing, interpreters have an execution step, which at some point translates to a machine representation of your code. It's referred to as execution, but, it feels a lot like a compile+execute step

I think you're missing that all interpreters have a compilation step that produces machine code, that's a requirement to produce programs.

Java's JIT compiler is the final compilation step of Java's interpreting path running in a separate thread that turns the intermediate language to machine code. To be very clear though, the output of the standard javac compiler is not machine code that a processor understands. This is what makes Java not a compiled language. It depends on additional processes at runtime to turn the code you wrote into something a processor understands.

On the performance front, well written Java is fast enough as long as you have sufficient resources for the overhead of JVM and as long as you don't have strict latency requirements. That makes it good for a pretty wide variety of computing tasks, but, also not a good choice for a lot of others.

That's not really what people mean when they're talking about interpreted versus compiled languages. Java's compilation step produces an intermediate language that still has to be interpreted before it's executed.

It turns Java code into something that can be interpreted faster, but not into something your processor directly understands. The key here is that it doesn't produce an output that can be fed directly to the processor without additional work at runtime.

Wasn't there a Tom Scott video about this concept a while ago? I can't find it atm but I'm sure I've seen this one already

It's worth knowing as a fellow Surface owner that that is very nonstandard. My Surface Pro 6 (admittedly much newer) lasts days or weeks if I just slap the lid closed and leave it somewhere, I think you might be missing something in the linux-surface github.

To any non-surface owners reading this, it's a Microsoft problem because the whole laptop is a custom Microsoft product and only has ACPI drivers on Windows, though, there is some open source support with a kernel patch that hasn't cleared it's way to mainline support

I'm not sure either, fork bombs are a thing you could probably do in JavaScript, but I don't know of a thing called an Atomic Bomb in programming? I think if you put lots of atomic operations you've just reinvented single threaded programming but with more overhead

I hadn't considered the proprietary nature of snaps when I decided I didn't like them. I just figured out their startup activity was adding 5 seconds to a 10 second boot despite not having installed any snaps