Yes, because http/2 or http/3 will improve the reliability of the connection between the client and the reverse proxy. The connection between the reverse proxy and the underlying web server is usually much faster and more reliable, so that part would benefit much less from being upgraded to http/2 or http/3.
MacOS has been phasing out support for third-party kernel extensions and CrowdStrike doesn't use a kernel extension there according to some other posts.
I’m convinced that one reason for this move by Apple was poor quality kernel extensions written by enterprise security companies. I had our enterprise virus/firewall program crash my Mac all the time. I eventually had to switch to a different computer (Linux) for that work.
It wasn’t Crowdstrike, but quality kernel level engineering isn’t was I think of when I think of security IT companies.
But, also credit Apple here. They’ve made it possible for these programs to still run and do their jobs without needing to run in kernel mode and be susceptible to crashes.
Not only security software, but really any 3rd party drivers have caused issues on Windows for years. Building better interfaces less likely to crash the kernel was a smart move
When I started doing driver development on MacOS X in the early 2000s, there were a number of questions on the kernel/driver dev mailing lists for darwin from AV vendors implementing kernel extensions. Most of them were embarrassing questions like "Our kernel extension calls out to our user level application, and sometimes the system deadlocks" that made me resolve to never run 3rd party AV on any system.
Whether you like macOS or not, they definitely are innovating in this space. They (afaik) are the only OS with more granular data access for permissions as well (no unfettered filesystem access by default, for instance)
It's also a shame CrowdStrike doesn't take kernel reliability seriously
The user can change anything they want, but a process launched by your user doesn't inherit every user access by default. You (the user) can give a process full disk access, or just access to your documents, or just access to your contacts, etc. It's maximizing user control, not minimizing it.
You say they're planning to add a feature in the next release, but what you linked to is merely an uncompleted to-do item for creating a UI switch to toggle a feature that hasn't been written yet. I think you win the prize for the most ridiculous exaggeration in this thread. Unless you can link to something that actually comes anywhere close to supporting your claim, you're just recklessly lying.
The linked Issue #8553 is "just" about creating a toggle for GPU acceleration. It's blocked by Issue #8552 [0], which is the actual Issue about the acceleration and originally belonged to Milestone "Release 4.3". It seems to have been removed later, which I didn't expect or know about. Accusation of lying was completely unnecessary in your comment.
Moreover, the Milestone was removed not because they changed their mind about the Release but for other reasons [1].
Ok, so your [0] shows that the real work has barely been started. The only indication it was ever planned for the next release was a misunderstanding on your part about the meaning of a tag that was applied to the issue for less than one day last fall, and they've stopped tagging issues with milestones to prevent such misunderstandings in the future. It still looks to me like your exaggerated claim was grounded in little more than wishful thinking.
Am I missing something? This is to add a toggle button and the developers say they are blocked because GPU acceleration feature doesn't exist so the button wouldn't be able to do anything.
I've already seen a few posts mentioning people running into worst-case issues like that. I wonder how many organizations are going to not be able to recover some or all of their existing systems.
Framesets still work as far as I know, they're just no longer recommended for a few reasons. Browsers already try very hard to never ever break anything, at least not anything that's been commonly supported for years or has made it into a standard. The main places browsers have broken compatibility with old content are related to plugins like Flash and Silverlight, which were always controlled by a single vendor instead of being open standards.
> at least not anything that's been commonly supported for years or has made it into a standard.
It's more: has made it into a standard and was commonly supported.
Sadly, the browsers aren't trying hard enough not to break anything. They are trying hard not to break anything standard, but the problem with that is that the standards can change, or that some things can be claimed to never have been standards all along. A bunch of IE/Netscape things have broken already such as BLINK and MARQUEE, despite being common enough to "feel" standard even though yes they were never actually standards. Also, as we've seen with the MathML battle in recent years, even standards aren't guaranteed to be kept in browsers if not "commonly supported".
The MDN deprecation warning on FRAMESET:
> Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes.
The browser support table says that every browser still currently supports FRAMESET with simple COLS and ROWS, but as I recall FRAMESET used to also support more complicated layout tools. My brain recalls it as being very similar to TABLE layout at one point in time that you could also have (limited) COLSPAN and ROWSPAN options. Such things may also have been IE/Netscape era "non-standards". If I had examples, they are probably lost to time. Similarly, with nearly no way to easily search in today's indexes for things specifically from the 1990s I can't think of a good way to find old examples either. It's also possibly my memory is just failing me on this and the crazy things I recall doing with framesets were just table layouts after all and maybe iframes, but I do recall doing some crazy things in the 90s that certainly aren't "standard" today and I know wouldn't work in today's framesets.
Yeah I don't really count Flash or Silverlight as parts of the "web platform" personally, though I will re-iterate that I am still very pleased with the Ruffle project nonetheless. From a practical standpoint, Ruffle does a lot of good even if Flash always was proprietary and not really a part of what the web platform really was at its core.
I hope <frameset> continues to work into the future. I'm sure eventually it will wind up on the chopping block, and personally I think that'll suck.
The weakest part of IPFS in my experience is how long it takes one node to find another with the requested data across the internet through the public DHTs. I imagine it might work much better in this system if they're limiting it to only do lookups and fetches within your own network of nodes.
Even with multithreaded WASM, the DOM will still only be usable from the page's (or iframe's) main thread, so if you want to do DOM operations not on the page's main thread you'll still need to do the same steps OP's project does (create an iframe and do stuff there).
A point of evidence in this direction is that RLHF was developed originally as an alignment technique and then it turned out to be a breakthrough that also made LLMs better and more useful. Alignment and capabilities work aren't necessarily at odds with each other.
As someone with a lot of experience in working on a Chrome extension that interacts with Gmail specifically, there are two reasons I'd expect an extension like OP's to integrate with the official Gmail API instead of poking the Gmail web app's internal API directly: 1) the official Gmail API is stable, documented, and doesn't take reverse-engineering to use, and 2) the Gmail web app's internal API is pretty strongly rate-limited for some actions.
If an extension only does actions involving the UI and data visible on screen within the Gmail webpage at a regular user pace, then I wouldn't expect it to strictly need the official Gmail API much. But this would mean the extension can't operate on emails that aren't on the current visible page, etc.
reply