nephyrin

I got as far as the table labeled

> What a write runs | Who finds the change

Good lord. If you are writing a thoughtful critique of something.. actually write it.

<object> used like this is just a poor iframe in a much shakier spot in the standards, mostly for backwards compatibility.

Like iframe, it "includes" a full subdocument as a block element, which isn't quite what the OP is hinting at.

For those that haven't bothered clicking the link, they add:

> Github was struggling with "malware" comment spam lately and we added several filter rules that block this stuff. Maybe this is what triggered disabling the repo?

The comments so far immediately jumping to conspiracy speculation is depressing.

It's already back up.

In a world of hot takes, this certainly is one of them.

I miss the n-gate guy.

Did they actually re-release 0125 as a retrained model with newer data, or was that an oversight? The date of Dec 2023 seems to suggest that was always the training time of the snapshot, rather than OpenAI silently re-revving the 0125 model with this doc update being their announcement. But it's a preview model, so maybe anything goes.

gpt-4-0125-preview has been out for about a month now

SteamOS dev here - lack of case folding is one (but solvable, we supported development on native case folding for ext4), but general stability issues are the main concern. Our testing with btrfs has not been promising for deploying it in a zero-maintenance manner to many users and finnicky SD cards and have it Just Work, but we're keeping an eye on things and weighing where we could contribute.

Agree, it feels like levitating a giraffe has been five years away for the last twenty years. The problem is private industry doesn't have a profit incentive to make the leap until it feels like a sure thing.

This whole thread is full of Dunning–Kruger victims misexplaining magnets to each other, this is pretty tame.

> if that person quits or the company discontinues a product, now we're left with useless crap in the kernel

Presumably deleting code is not very hard if it is unmaintained or a burden.

> Why can't these companies just build their own modules? Why is it everyone else's problem?

They're not upstreaming this so their own internal dev lives are easier. They'd rather just keep using whatever development repo they already are without dealing with upstream reviews and requirements. They were upstreaming this so that everyone could have support for the hardware upon release.

And, to that end, "corporations" upstreaming high quality support for their hardware, as intel has been doing, benefits linux. Throwing shade at them for preparing day-1 support for hardware they ended up canceling seems counter-intuitive.

UDP is not a privileged protocol. You don't need any capabilities to speak UDP. It's used by web browsers already for HTTP/3 as TFA mentions.

But also, apps needing additional capabilities is rather common and handled by most any package manager that's going to be providing you a browser. Chrome in various configurations ships with a `setuid` binary to implement their sandbox, for instance.

> Recently Firefox said they were moving away from threads to processes. I think that's a mistake. Killing Chrome was a pain at times because when it does hang all the child processes had to be killed independently. It was possible to restart Chrome with orphaned processes. What a mess.

Your argument against a multi-process architecture is you once encountered a process-reaping bug in chrome. Can't even.

> I refuse to use Chrome because it has crappy performance and usability.

I worked as a platform engineer at Mozilla for several years. I heard so many unfounded opinions about <browser>'s <performance/memory/whatever> consumption that ran contrary to every benchmark and defied every attempt to extract statistics from the user that you'd think I would be numb to it. But I still get chills.

The advice was always the same though. "Does this occur if you open a fresh profile without your 900 tabs or 50 addons?" -- "If I'm going to do that I might as well switch to Chrome!" -- Well, I mean, okay.

> Chrome developers are crap developers and they hide behind processes because they don't have the chops to do threads. I hate to see Firefox move in that direction. Maybe Firefox needs to since Firefox is adopting Chrome extensions. But I refuse to use Chrome because it has crappy performance and usability. Hopefully Firefox doesn't move in the same direction.

This is insulting to a lot of very smart people who spent an enormous amount of time working on these engines. You can't just infer two traits about random software, attribute it to the biggest technical difference you can see, and then state that as fact. A multi-process architecture is much more difficult to get right than a multi-threaded one, and every single modern browser is pursuing it because it is worthwhile on numerous axis. Citing nothing but a vague luddite sentiment, you assert the hundreds of engineers who have spent years working on chrome don't "have the chops" to "do threads". Wat.

Better hope your browser of choice has a regex JIT.

And GPU compositing, 'cause damn.