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.
> These laws can, and almost certainly will, get worse. New York's proposed Senate Bill S8102A explicitly forbids self-reporting. The state Attorney General will decide how to enforce it. For example, to use Linux, you might need to submit a driver's license.
> The real problem is this hodgepodge of laws; it's the growth of the surveillance state. From voting rights in the United States, facing Trump's Orwellian-named SAVE America Act, to Ring's doggie tracking system that can also be used to follow people, to Trump booting Anthropic to the side for refusing to allow its AI tools to be used for mass surveillance, privacy is on the decline.
I understand it is popular to pick on the current administration, and there are plenty of rightful reasons to, but let's not forget this has been happening way before either of Trump's terms (see: KYC laws). The only difference between then and now is that current administration has essentially taken a mask-off approach, so we get to see this discussion finally brought up by mainstream media outlets.
I don't think it's unique to America either. It's just the ebb and flow of the envelope of possibilities for central governance as technology and culture changes. FATF has managed to implement KYC worldwide, even in banana republics at least for the peasant without connections.
You're not wrong, but there is a huge difference between moving US government regulated currency to (possibly) foreign and (possibly) nefarious actors, and this.
Ever since KYC was extended to cover cryptocurrency exchanges, I have given up any faith in that this is solely about regulated currencies, or money laundering at all.
I don't understand this position. Cryptocurrency exchanges are the primary legal touch point (fiat offramp) for a lot of criminal activity. Of course they will get attention for AML.
I can understand the regulation of fiat/crypto exchanges, but the verification extends to centralized exchanges that merely facilitate exchanges one kind of purely virtual currency for another, neither of which have to be recognized as legal tender.
I didn't know those existed, and so I kind of see your point.
The counterpoint is that if your job was to prevent/punish financial crimes that affect consumers, would it make sense to ignore these exchanges?
Heck, if M:TG cards were the medium, and they could be moved across international borders with a few keystrokes, then surely those would be watched too.
I won't argue that it's not privacy-invading for legitimate customers, but if the legal structure allows it, regulators have an obligation to look where the problems are expected to be.
If my job was to promote open source software it would make sense to ban proprietary software. That doesn't mean I should actually be allowed to do that.
reply