HN user

nephyrin

331 karma
Posts0
Comments35
View on HN
No posts found.

<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.

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.

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.

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.

So:

- Anyone with this extension installed could be trivially owned by any website.

- AVG's initial fix was to incorrectly whitelist their own domains without requiring SSL.

- The follow up fix (after more harsh words from google) whitelists the AVG domain with SSL. Google engineer points out a obvious XSS on the domain that would again allow any chrome user to get owned.

This is a security extension from a security vendor. No words.

Rewriting public branch history is not generally used by any major project except in extreme circumstances. This reads like an attempt at satire by someone who doesn't understand the actual utility of history rewriting in git, which is generally for extending version control to your development changes (e.g. what is more formally codified in Mercurial as the draft phase).

Emacs is Sexy 12 years ago

My config is the repo vdm linked. Minimap "works" in that it can be opened, but terminals don't allow for variable font sizes or images, so it is significantly less useful.

Gecko plugin peer here: Unfortunately, no. NPAPI has two modes: windowed and windowless. In windowless mode (roughly): we proxy input to flash, and flash renders into a buffer we provide it. In windowed mode, we create a native OS child window for flash and let it handle input and rendering directly. In this mode, without a way for flash to pass "unused" keys back to us, it will require some ugly hacks to steal hotkeys from it reliably.

Most sites run flash in windowed mode, and for good reason - flash's performance sucks in windowless mode, and it cannot make use of hardware acceleration (IIRC). Since Adobe's NPAPI flash seems to be essentially in stability mode, it's unlikely this will be improved :(

Now, in current multiprocess mode, we actually force flash to use windowless mode -- because support for windowed mode isn't finished yet (bug 923746). But the aforementioned performance issues mean that we'll probably remove that restriction once we support windowed mode in multiprocess.