flohofwoe

> to a PM who in my opinion was right to push back because for a non-technical person...

Ah and there's the rub. Why should a PM of a software project even be a 'non-technical person' (because tbh what's even the point, how would a 'non-technical' person even be able to evaluate technical decisions and their implementation?). And even for multi-disciplinary projects like videogames it's not too much to expect that the project manager has at least a basic understanding of all crafts that work on a game.

E.g.. there's nothing more useless than a PM that's just pushing task bars around in JIRA to make them fit into the next sprint.

...and also: would you fly in a plane, or drive over a bridge that was built under supervision of a 'non-technical' PM? (I know I know... since the Boeing disasters that question is rhetorical, most people don't seem to care)

...exactly, and at some point you want to show inline animations or videos and all sorts of other media, show webpage previews, play audio snippets and all the other things things a webpage can do, and then you're back to either integrating a browser engine or attempt to write one from scratch (the browser engine can of course be provided by the system webview, e.g. what Tauri does).

Oh man... if you want to start a professional career as internet troll you have a really long road ahead of you.

It's still doing nothing that a 20 year old flight simulator wouldn't be able to do. The one potential performance problem on a laptop with HighDPI display might be the pixel fillrate to render at full resolution, but the pixel shaders in Google Earth should be extremely cheap, and if that's not enough it could drop down to half resolution with 4x MSAA without much quality loss (but an M1 GPU easily has enough oompfh per pixel on a Retina display for what Google Earth needs to render).

> Smooth, even on an M1...

Well, I would certainly excpect that an application that was already running smoothly on vanilla computers around 2005 also runs smoothly on a computer from 2020 ;)

Tbf, 'hardware accelerated' doesn't mean much when your text renderer is slow (which apparently seems to have been fixed after the 'Muratori drama': https://devblogs.microsoft.com/commandline/windows-terminal-...)

> The amount of times I've been sad that multiply or sum are longer than + or * is limited to long formulas and even then it's a non issue.

It depends on what things you work on. When I'm writing 'math-y' code (GPU shaders for renderng etc) then I want the expressions to look close to the reference paper and not artificially split them up into multiple lines of code with function calls instead of operators.

...and while at why not also dump the assignment and indexing operators!

    assign(result, add(b, mul(c, sub(d, e)), add(add(f, g), array_get(arr, i)));

(I bet I messed up the parentheses somewhere).

At that point, even assembly code is more readable. Also there's a reason why Lisp and Forth haven't exactly taken the world by storm ;)

macOS is just a bit behind the curve. For instance a couple of years ago macOS added Windows Vista style permission popups, and Apple really doesn't want you to install UI apps outside the App Store, which is essentially the equivalent of "Windows SmartScreen".

Windows Terminal doesn't support Kitty Graphics Protocol (yet?: https://github.com/microsoft/terminal/issues/8389).

That's the one thing I always check first in a terminal because I have this pet project to run emulators in a terminal ;)

https://github.com/floooh/chipz-kitty

(works fine in Kitty and Ghostty, wezterm theoretically also supports the Kitty protocol but at some point just freezes)

Maybe, but it reminds me of the bad old days when Microsoft called their applications 'cross-platform', and then they just meant different flavours of Windows ;)

Very similar, about the only difference from user perspective is that Kitty has a slight content 'wobble' on macOS when resizing the window (this typically happens when the content is rendered via an MTKView or CAMetalLayer and its parent view's 'layerContentsPlacement' isn't anchored to one side during window resizing). That would be trivial to fix though.

PS: another difference is installation size, on macOS Kitty is about 246 MB while Ghostty is 67 MB (and it looks like Kitty comes with a glslang shader compiler and python 3.14 frameworks, which together already take up 32 MB).

TL;DR: it feels like Ghostty is paying a bit more attention to platform-specific aspects than Kitty.

Also funny/sad: both call themselves 'cross-platform', but then don't support Windows (only various UNIX variants).

More like Windows running in browser running Rebirth 338 (at least going by all the 'wine' in filenames) ;)

The webpage is loading an incredible amount of .js files which all look identical (https://margeux.com/rb338/boxedwine-firefox-20261103.js, looks like Emscripten JS shims), but then also loads two massive blobs (one is 100 MB, the other 150 MB). I'd at least check what's up with all those .js file downloads, that looks like a bug tbh.

First start takes very long btw on a 50 MBit connection, most time seems to be spent with this same small JS file that's downloaded many times, I'm sure this could be massively optimized.

Last I checked Norway doesn't have a border with the US ;)

Hmm, IME at least in emulators the switch tables usually have enough 'structure' that GCC or Clang have no trouble turning them into jump tables.

Well you check the compiler output and profile of course. But "generalized" performance advice like "use reverse loops" hasn't been relevant for a long time, it's a similar myth like "pre-increment is faster than post-increment".

C doesn't have an opinion, it allows negative indexing just fine when the index is a signed type (indexing-syntax is just syntax-sugar for pointer arithmetic).

> ...counting backwards in a for loop is faster...

Maybe in 1990 ;)

(it's one of many cargo cult wisdom snippets that have become mostly obsolete once C compilers got proper optimizer passes and CPUs got all sorts of pipeling tricks)

Eh I don't know, the straightforward solution is still to use a signed loop counter (and signed indices) and only ever use unsigned integer types for bit twiddling. Also, enable `-Wsign-conversion` (it's not in -Wall -Wextra) to catch all the places where the compiler implicitly converts between signed and unsigned behind your back.

TL;DR: "alomost always signed!" :)

> The introduction of the mouse led to developers paying less attention to keyboard shortcuts and function keys, but I don’t see anyone seriously saying computers should not have mice.

Well, a lot of devs did move back to the terminal ;)

> But the safe decision would be no to enter the train.

You might just as well never leave your bed, that's even safer ;) Train travel is much safer than travelling on roads, and in the same ballpark as commercial flight.

Safety systems don't help much when they fail themselves. E.g. usually there are automatic systems in place that prevent that two trains are on the same rail network section at the same time, but this system apparently has failed. Details are in the article.

How early it gets dark in winter depends on how far up north you are of course. On my latitude (Germany) it gets dark around 4:30pm and 5:30pm in winter, which for me is late afternoon (6:00pm would then be early evening)

Yeah same here, I don't even noticed the time switch this time. I remember it was worse as teenager, so maybe it affects young people more than old farts ;)

What? No! I find it utterly depressing to get up in the morning and it's still completely dark outside. A dark late afternoon is much nicer IMHO.

It's often used for more immediate 'consequences', like "Ich muß los, sonst verpass ich meinen Zug" (I need to leave, otherwise I'll miss my train).

Yeah, but "wenn-dann-sonst" rolls better off the tongue ;)

Hmm, to me as native speaker, 'sonst' has pretty much only one meaning which is pretty much exactly 'or else'. There's a longer and 'more archaic' version 'ansonsten'.

The most likely German candidate would be 'sonst', which would be both in common use and short enough for a programming language keyword. E.g. the most likely option for 'if-then-else' is 'wenn-dann-sonst', assuming that German-origin theory is right of course.

One thing that's mostly forgotten today is that German had a very rich 'corpus' of wonderful nerdy computer science words up until the 1990s which unfortunately has fallen out of fashion. Nowadays it's a pretty terrible 'pidgin dialect' when Germans talk about programming and computers to each other (to a point where it's much less awkward to just speak English in the first place lol).

Maybe it comes and goes like the Touch Bar (yeah I know, quite unlikely, but one can dream) ;)