That’s what lots of sites used to do in the late 90s and early aughts in order to have fixed elements.
It was really shit. Browser navigation cues disappear, minor errors will fuck up the entire thing by navigating fixed element frames instead of contents, design flexibility disappears (even as consistent styling requires more efforts), frames don’t content-size so will clip and show scroll bars all over, debugging is absolute ass, …
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.
Have you done any performance testing with btrfs compression?
I have a Legion Go. I don't have the specs handy now, but the SSD was rated fast enough that I suspected compression would harm my overall performance.
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
Yeah and there's already a well-known (at least I already knew about it and have been using it for a while) package started in 2022 called "copilot" for Emacs that is actually a client for GitHub Copilot: https://github.com/zerolfx/copilot.el
Given the lack of namespacing in Elisp (or, rather, the informal namespacing conventions by which these two packages collide) it's unfortunate that this package chose the same name.
If Microsoft is unhappy with 70 lines of LISP that I posted on their website, then I'm more than happy to change it. Ask them to reach out to jtunney@gmail.com
Please, never react just because a lawyer sends a single email (especially when you have no profit motive and do open source).
You have time to react to serious issues, including after accidentally deleting the first few emails. Trademarks are different from patents. Pre-grant and/or post-grant opposition for a single generic word is a relatively easy way to kill it.
With Perplexity copilot, Github copilot, MS Copilot and Office365 Copilot and all the other Copilots, it seems Copilot has become a generic term for AI assistant.
Copilot is a generic term that’s been used for AI for years (before Microsoft).
In trademark law that’s not going to hold up unless combined with other terms - ie GitHub copilot (trademark), copilot (not trademark)
Even combining generics is probably only valid for a trademark under certain circumstances. For instance, “flight copilot” is likely generic because it’s existed for years across products. However, “sandwich copilot” is likely not generic because no one has asserted it yet and thus you can potentially trademark protect it.
Ultimately, the question is simple “does this product confuse customers, such that they believe it’s made by another organization? AND does it intentionally do so, for monetary gain?” If you can’t say yes to both and prove both, you’re probably fine.
I say all of this as the founder of https://ipcopilot.ai and have spoken with attorneys extensively AND our product is directly assisting IP attorneys. That said, I’m not an attorney, and this isn’t advice :)
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.
Word on the street is that the government has had levitating giraffes (and maybe even bigger creatures) for years but it's all so locked up in the classified world that the tech will never see the light of day.
> 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.
Like iframe, it "includes" a full subdocument as a block element, which isn't quite what the OP is hinting at.