I noticed that there's a developing trend of "who manages to use the most CSS filters" among web developers, and it was there even before LLMs. Now that most of the web is slop in one form or another, and LLMs seem to have been trained on the worst of the worst, every other website uses an obscene amount of CSS backdrop-filter blur, which slows down software renderers and systems with older GPUs to a crawl.
When it comes to DeepL specifically, I once opened their main page and left my laptop for an hour, only to come back to it being steaming hot. Turns out there's a video around the bottom of the page (the "DeepL AI Labs" section) that got stuck in a SEEKING state, repeatedly triggering a pile of NextJS/React crap which would seek the video back, causing the SEEKING event and thus itself to be triggered again.
I wish Google would add client-side resource use to Web Vitals and start demoting poorly performing pages. I'm afraid this isn't going to change otherwise; with first complaints dating back to mid-2010s, browsers and Electron apps hogging RAM are far from new and yet web developers have only been getting increasingly disconnected from reality.
To me, this discontinuation is less about the product and more about making a statement. The M2 Mac Pro was a dysfunctional product of an internal conflict of interests, but it cast a ray of hope that the M series would develop past the current scaled-up-but-still-disposable phone/embedded SoCs and that Apple had some interest in bringing them closer to the offerings of the competitors from the workstation/server market. Now, with this move, they've made it clear that they would rather give up an entire segment than make at least a narrow part of their ecosystem open enough for the PCIe slots of the Mac Pro to find any serious use.
Do you happen to be from the western US or Canada? They tend to lower the /ɪ/ monophthong (i of tip, pit, sit, etc.) there, making it sound pretty close to /e/ (French é, German eh). It's one of those things that, combined with regionalisms and other accent features, give away where you grew up :) I noticed a lot of Londoners do this too, though this is just my experience.
Letting any GUI application capture all input and take full control of the desktop completely defeats the point of sandboxing and X11 does exactly that.
Sandboxing defeats the point of said applications. If you want your computer to have no functionality, check out Figma. A clickable prototype sounds like precisely the security the world needs right now.
So accordingly, ActiveX was a brilliant idea and any web page should be able to execute code in the kernel context, otherwise no meaningful functionality can be provided
Yawn, X11 (and similar "unsecure" desktop environments) existed for half a century and the sky hasn't fallen. I'm tired of that "will somebody think of the children/grandparents" scare mongering.
It hasn't, but Windows has had its fair share of keyloggers, RATs, and so on, and I think we can all agree that anti-virus software is an inherently flawed concept.
The only thing keeping those away from Linux was its market share. With npm malware on the rise, this is no longer enough of a protection.
I agree that the lack of standardization around the "insecure" things is a bad idea. Insecure operations don't have to be available by default, or even universally supported, but a central registry of interfaces for e.g. retrieving all windows on a desktop would certainly help preventing fragmentation.
At the same time, most of this post really is just a rant essentially saying that a low-level library is so flexible that using it directly results in code so verbose it can hardly be read. Yes, that's how good low-level designs always are.
You can turn a generic portable asynchronous ANSI C interface into a simple, blocking and platform-specific one with an abstraction layer. You can integrate it with all sorts of existing event loops and programming frameworks. You can customize it all you like but using it directly in an application will cost you a lot of patience. At the same time, you can't go in the opposite direction; from a "simple" blocking black-box interface to something that can reasonably host a complex GUI toolkit. If you're after simplicity, go higher-level.
There is really no excuse for a low-level API to be hard to use. It's just poor API design, plain and simple.
At the very least there should be a standardized (and centralized) client library on top of Wayland but below widget frameworks like GTK or Qt which implements the missing "desktop window system features": opening, moving, sizing windows (with decorations please), mouse and keyboard input events, clipboard, drag-and-drop. Non-GTK/Qt applications should never have to talk directly to the asynchronous Wayland APIs, only to this wrapper library.
Such a library should be designed to make programmers want to move on from X11 (because writing code against Xlib is horrible, but somehow Wayland managed to be even worse) - and tbh, this new window system client library (at first on top of X11) should have been the top priority of the Wayland project before starting to work on the actual X11 replacement, and it should have shipped on all desktop Linux distros at least a decade ago so that application programmers could have been won over (and for collecting feedback) even before Wayland shipped its first version.
I might be mistaken, but isn't this what libraries like winit exist for? It might not be just for wayland, but it seems like it supports everything you mentioned other than drag and drop.
Generally yes (or GLFW, or SDL), but the Wayland project shouldn't delegate the job to burned out hobbyists (who will think twice before wasting their time with bad APIs). This client library should really be a mandatory part of each Wayland install as a system library, not part of the application. And most importantly, the Wayland project needs to start eating their own dogfood, or things will never improve.
"Generally yes (or GLFW, or SDL), but the Wayland project shouldn't delegate the job to burned out hobbyists (who will think twice before wasting their time with bad APIs)."
Who do you think work on the various parts in Wayland if not "burned out hobbyists"?
Whenever people complain about Wayland being hard to program in, I think about how Xlib was largely replaced by XCB, and OpenGL is increasingly marginalized in comparison to Vulkan.
Not to draw any specific analogy, but sometimes a fussy low-level interface is just important to have.
> and OpenGL is increasingly marginalized in comparison to Vulkan
Vulkan's "API design deficits" (to put it mildly) have been recognized by Khronos though, and turning that mess around and making the API a "joy to use" is one of Khronos' main priorities at the moment (kudos to them for doing that).
Maybe the technical politics have changed, but I feel like I remember there was some push in the late 2000s to rewrite libraries that were using Xlib to instead use XCB.
Regardless, that's sort of my point: having a lower level fiddly layer is a desirable quality, and Xlib being rebased on top of it isn't exactly a counterexample.
The API design has nothing to do with security. The Posix API is completely secure. MS has been able to bolt on exactly this kind of security to Win32.
This submission leads to a generic press release about the anti-feature from 6 months ago, when it was first announced. There's absolutely no mention of the information that has been revealed and posted here since, not even that regarding the 24-hour wait from the submission's title.
If this is what the other submissions of this account look like, it's no wonder they're being taken down.
The thing is, Bitcoin, at least before cryptocurrencies were picked up by "tech bros", was originally a way to disconnect from the corrupt, centralized banking system.
LLMs, at the moment, are all about giving up your own brain and becoming fully dependent on a subscription-based online service.
Depends on the VPN, I remember Nord had a private p2p network that allowed users of their VPN service to communicate directly with each other without exposing their p2p services to the greater internet.
Granted, its been a lomg time since I used Nord, not sure if they still offer that service.
Well, only some of them actually offer full VPN service. Most of them are still just traffic-forwarding proxies, just not limited to HTTP. NordVPN used to offer full VPN service under the name "Meshnet", but actually discontinued it last year.
> You can use them for whatever protocol you want.
the two most commons protocols used for proxying traffic support arbitrary tcp traffic.
socks is quite self explanatory but http is not limited to https either!
Of course most providers might block non https traffic by doing DPI or (more realistically) refusing to proxy ports other than 80/443 but nothing is inherent to the protocol.
> Aside from enabling secure access to websites behind proxies, a HTTP tunnel provides a way to allow traffic that would otherwise be restricted (SSH or FTP) over the HTTP(S) protocol.
> If you are running a proxy that supports CONNECT, restrict its use to a set of known ports or a configurable list of safe request targets
> A loosely-configured proxy may be abused to forward traffic such as SMTP to relay spam email, for example.
IMO if it requires a new network interface to be created on the machine, then it's a VPN. But an application-level tunnel (such as SOCKS) would just be a proxy.
A lot of it looks like people trying to be helpful but it must be infuriating handling issues for a big project like this. I'm going to guess that the infrastructure team for Pandas don't actually need random men on the internet informing them that such obscure hosting options as Vercel and Netlify exist.
When it comes to DeepL specifically, I once opened their main page and left my laptop for an hour, only to come back to it being steaming hot. Turns out there's a video around the bottom of the page (the "DeepL AI Labs" section) that got stuck in a SEEKING state, repeatedly triggering a pile of NextJS/React crap which would seek the video back, causing the SEEKING event and thus itself to be triggered again.
I wish Google would add client-side resource use to Web Vitals and start demoting poorly performing pages. I'm afraid this isn't going to change otherwise; with first complaints dating back to mid-2010s, browsers and Electron apps hogging RAM are far from new and yet web developers have only been getting increasingly disconnected from reality.
reply