<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.
HN user
<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.
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.
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.
https://nemu.pointysoftware.net/sink/nephscreen-1456332101.p...
At one frame per minute, I'm looking forward to where this goes
Edit: Progress report (~1h): https://nemu.pointysoftware.net/sink/nephscreen-1456335941.p...
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.
Mozilla's DXR deserves a look as well
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.
Are there specific advantages to using this pattern over e.g. just having a service factory with reference counting?
I think I was Poe's Law'd by his last paragraph
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).
This door?
http://nextcity.org/images/made/images/daily/_resized/img_mo...
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?
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.
DejaVu Sans Mono: http://dejavu-fonts.org/
(Full hinting, greyscale AA)
Not sure about sexy, but you can definitely make emacs easier on the eyes than its default Xt-in-1994 style:
This is a link to a yahoo news scrape of a bgr.com story about a tweet about a picture. Seriously?
Mozilla intends to implement srcset/picture, but it hasn't landed yet. Relevant bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=870021 https://bugzilla.mozilla.org/show_bug.cgi?id=870022
Mozilla (along with most everyone else) took issue with Google's intent to ship Shadow DOM. See e.g. this exchange:
http://lists.w3.org/Archives/Public/www-style/2014Feb/0152.h...
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.
Gecko exposes a large number of its interfaces to JS, and the entire Firefox frontend is written as such: http://dxr.mozilla.org/mozilla-central/source/browser/base/c...
git grep -E '\brout|outer\b'
"Added to HTML5" is misleading. More specifically, the bitcoin scheme was added as a valid scheme that websites may register themselves as handlers for via navigator.registerProtocolHandler, a list that already includes mms: xmpp: webcal: tel: and other misc schemes. It doesn't specify any kind of support for the scheme for the browser.
See http://www.whatwg.org/specs/web-apps/current-work/#whitelist...