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.
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.
Note that this isn't for github's copilot, but rather for running your own LLM engine locally. It's going to quickly get confused with the unofficial copilot-for-emacs plugin pretty quickly: https://github.com/zerolfx/copilot.el
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.
> 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.
Up to about 1fps. The DOM tree continues to gather its factions together under one banner. Meanwhile, the smaller but more easily organized devtools and webidl factions are making an early power play.
- 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).
I agree, it's outrageous that a door that opens onto the embarcadero be locked when the room is unoccupied, or that the building has a security camera near that door, which happens to be the corner of the building facing the street! Do they expect everyone to go to the main entrance to talk to someone or something?
Like iframe, it "includes" a full subdocument as a block element, which isn't quite what the OP is hinting at.