I don't get the frustration with wayland (the protocol) in the comments. This project shows that having a separate window manager was always possible. First we got wlroots as a library that did most of the heavy lifting, and now we got river as an even higher level abstraction.
Sure I agree that wayland (the project) could have provided these abstractions much earlier. But anyone else could have done it, too. We get all of this for free, so we shouldn't complain if other people don't do the work that we could do just as well.
> I don't get the frustration with wayland (the protocol) in the comments.
They took a firm principled stance against screenshots to start with, which set them up for the COVID WFH wave. Then we've got this questionable design that seems hard to make accessible since accessibility is a security risk and we're heading right into Agentic AI which will be interesting. I've been avoiding the Wayland ecosystem for as long as I can after the initial burn and it'll be curious to see how well it supports bringing in new AI tooling. Maybe quite well, I gather that Pipewire is taking over the parts of the ecosystem that Wayland left for someone else and maybe the community has grown to the point where it has overcome the poor design of Wayland's security model by routing around it.
My guess is the frustration is coming from a similar perspective because it is a bit scary seeing Wayland getting picked up everywhere as a default and the evidence to date is they don't really consider a user-friendly system as a core design outcome. Realistically Wayland is 2 steps forward even if there is a step back here or there. The OSS world has never been defined by a clean and well designed graphics stack.
I think wayland is OK as a user. But Wayland is just not really that UNIX.
As ordinary user, I actually don't care about any of this. However, from another perspective, I think this is a bad thing—open source projects have become product-centered, defaulting to the assumption that users are ignorant fools. This isn't how community projects should behave, but those projects is not that community-driven anyway.
After all, for a long time, so-called security has only been a misused justification—never letting users make mistakes is just a pretty excuse, meant to keep users from being able to easily access something, and eventually from ever accessing it at all.
> Then we've got this questionable design that seems hard to make accessible
I'm not a fan of ADA ambulance chasers on principle, but I wouldn't shed a tear see them be able to go after the bigcos that made this mess (e.g. IBM).
ADA seems like bullshit until something happens that costs you sight, hearing, manual dexterity, etc. Then it is significantly less funny overall, I assure you.
This was not my experience. For example, it want until chromium 110 that you could use webrtc+pipewire without overriding settings, in 2023. So maybe in a strict sense you could do it with fiddling, I don't think you could install any Linux flavor and screen share over meet reliably.
We went through this during COVID. There were a lot of things that were supposedly technically achievable if you spent enough time setting it up right.
What really happened was most people gave up and either tried to avoid screen sharing or switched distributions.
And variable refresh rate, better fractional scaling (and per-monitor scaling), atomic updates, native touch & gestures. And the isolation/sandboxing is important. The problem is Wayland didn't have portals in the beginning (hence the screenshot issue).
Wayland isn't the problem. The pace at which distros (and GNOME, lets be real who is behind the push here) started stripping out X11 was too fast, and too early.
X11 was resolution-agnostic from the start, but the ‘desktop Linux’ crowd were so focused on imitating Windows that they ignored Unix lessons and made fixed-resolution toolkits like Windows'.
Color management (not just HDR which needs it) was also an afterthought. Calibration is still an issue.
> for reasons no one understands
Reasons are sadly typical for FOSS: from the start the devs were focused on their favorite use cases with no communication with end users to figure out theirs.
I'd guess it's because of the general attitude of the project's community, specifically GNOME people and their “my way or highway” style of answering questions e.g. about CSD or other non-critical stuff, not directly related to core protocol. If they were a bit more accommodating to reasonable requests from outside, they'd get less backlash in comments. There's plenty of exemplar behaviour elsewhere in adjacent communities, they could have taken hint multiple times.
That they provide this stuff for free would be a good argument if the stuff wasn't pushed down people's throats with no working alternative and Xorg being discontinued.
And how would they be able to "push stuff down people's throats" if people could walk away towards alternatives? When such alternatives don't exist, that's exactly how "they do stuff for free and nobody else is putting in the work to make something else" looks like.
The problem isn't they "pushing stuff down your throats", it's nobody else (including you) making alternatives that you like better. You are voluntarily ingesting their stuff because your only alternative is starving.
> And how would they be able to "push stuff down people's throats" if people could walk away towards alternatives?
It's a forcing of their narrow opinion on what should be allowed onto the ecosystem at large, because all of these things are connected. You can leave to a different DE/distro, but if every DE is doing its own thing for global hotkeys or whatever, then software in the ecosystem is going to be hacky/bespoke or have an unreasonable maintenance burden.
Even if you in particular can move elsewhere the ecosystem is still held back. We only recently got consensus on apps being able to request a window position on screen, which is something x11, macos, and windows all allow you to do. CSD and tray icons are other examples of things found everywhere else that they did not want to support. Some applications are just broken without tray icon support.
This bleeds over into work for folks releasing software for Linux in general. By not supporting SSD they were pushing the burden of drawing window decorations onto every single app author, and while most frameworks will handle this, it's not like everyone is using qt or gtk. App authors will get bug reports and the burden of releasing software on Linux needlessly climbs again.
Hard to convey how unreasonable I feel their stance was on tray icons / SSD. It should be the domain of the DE from a conceptual but also practical point of view, even from just the amount of work involved. It reminds me of LSP's enabling text editors to have great support for every language. And again, Gnome was the odd man out in this, they want extra attention and work when Linux is the lowest desktop marketshare by far, and they themselves are not the overwhelming majority but they are large enough that you really do need to make sure your software runs well on Gnome even if you want to support Linux.
People think Gnome push stuff down your throat because they have the power and influence to impact the ecosystem, and they use that power and influence to die on absolutely absurd hills.
I dunno, I think tray icons support is kind of the absurd hill to die on. They're a Windows 95-ism and generally extremely horrible in terms of usability. Apps use them and desktop environments support them mostly out of a lack of imagination, and they are frankly extremely overused.
I'm personally a KDE user, but I'm with the GNOME folks on this one.
They may have been introduced in Windows 95, but they didn't actually become particularly common until years later. They weren't originally intended as a long-term feature and, in Win 2000, Microsoft started recommending that people use custom Control Panel objects or MMC console snap-ins instead. But the MMC wasn't an option in Win98/Me and, by the time MS finally managed to produced a consumer variant of NT, use of the system tray had become entrenched.
I'm not sure what Windows is like these days, but in MacOS they're patently absurd. My corporate Mac laptop has twelve of the fucking things, and I've never actually had genuine need to click on any of them (and 5 of them are from Apple and so of course use 4 different corner radii between them - the 3rd party ones are at least a little more consistent).
> I don't get the frustration with wayland (the protocol) in the comments. This project shows that having a separate window manager was always possible.
Wayland is 17 years old. At this point, it's almost more frustrating to have one of its bigger architectural problems potentially addressed, precisely because it shows that it was always possible, and the people pushing for its adoption just... didn't bother doing the things that would make it easier to adopt.
I also find building apps for the web is much easier than any of the native frameworks. You can start by writing plain text in a file and then progressively add HTML, CSS, and JS. The app described in the article is trivial to implement in the web.
A lot of that comes down to the huge community and the shear amount of documentation that exists. OTOH, nowadays you will quickly be distracted by frameworks and build systems.
IMHO the biggest hurdle is hosting, but github pages makes even that somewhat easy.
The README talks a lot about crypto. But the interesting bit is how you can access the passwords. Is there an API? If yes, how does it protect your passwords from malicious software? If not -- are you sure? (Have you checked for example accessibility APIs by the platform?)
PassForgePro does not have any API for accessing passwords. It’s a local-only, offline-first project. There is no remote service, no API endpoint, no cloud sync, and no server communication at all.
All passwords are stored in an encrypted local SQLite vault with AES-256-GCM, and the key is derived using PBKDF2. Decryption happens only in memory after the vault is unlocked by the user.
There is no interface that exposes secrets outside the app. When I talk about cryptography and design in the README and FAQ, the focus is on local protection, not on a remote API.
As I mention in the FAQ, PassForgePro is an experimental learning project, not a production-grade password manager. It does not claim to defend against a fully compromised OS or malicious local software — that’s outside its threat model.
So if someone assumes there must be an API or external access, that assumption doesn’t match the actual architecture.
It is a Maneki-neko (beckoning cat / Winkekatze). The video team started putting them on podiums so they could see when a stream was frozen. So it became kind of a mascot.
This is probably a Linux issue. Mac OS and Windows implement the FIDO2 Platform API, which allows them to act as authenticators themselves. Linux does not. See https://github.com/linux-credentials.
With macOS and Windows I'm still stuck in corporate ecosystems though which was my point. I used to use Mac but I couldn't deal with the increasing iOSification and I only use windows now for gaming (VR) because it's such an awful OS.
But that's another point, I do use many OSes so being locked in to one ecosystem is not an option. I must also have the option to back up my credentials at all times (eg a cloud service will never suffice)
But yeah I should have mentioned Linux. I thought it was the norm here really especially among people advocating against corporate ecosystems.
I also think these are very similar. The main difference in my view is that the state parameter is checked by the client, while PKCE is checked by the server.
I run an authentication server and requiring PKCE allows me to make sure that XSS protection is handled for all clients.
> For coders, visual aesthetics don’t matter. For lawyers, they are a technical requirement. While this difference may seem arbitrary on the surface, it is downstream of a critical technical difference between the two fields. Machines interpret the work of coders. Human institutions interpret the work of lawyers.
I believe this is not only infuriating, I am pretty sure it is actually illegal. If lawyers would think that visuals are more important than semantics, they would explicitly discriminate blind people.
100% this. When I reached the end of that page I felt pranked because the obvious question was never answered. How are these cases resolved? Is it possible to fix some inputs and only update others? What if I sometimes want to change input A, and other times I want to update input B? All this should be explained as early as possible.
You can do it and it is explained, actually. Use # as a prefix to indicate a constant, e.g.: #50 will be a constant and not a variable.
In the future I'd like to support more user input constraints, in particular domain constraints for variables. So you could tell the solver that this cell must remain in some interval, and it would respect that interval instead of assigning any real value.
Yes. Hyprland has burnt bridges with many of the classic/pre-existing Linux dev communities. Amongst other things, the main developer was banned from freedesktop.
But they have a very, very large user base, which means lots of contributors - especially young, first-time-FOSS/Linux contributors. In a way, Hyprland has partially done what Linus was hoping to do by adding Rust to the kernel (attract the next-generation of young developers). And they have an active BDFL - no "led by committee" issues.
i don’t care, hyprland is great software and much better than whatever the ‘non-toxic as labeled by drew devault’ communities have come up with for WMs
Drew Devault is a left wing nutjob. He's done nothing but cause drama and attack people for years now.
Vaxry is an immature ~20 year old Polish dude. That means a bit of angst, Eastern European humour, more conservative opinions than most US tech workers.
Yeah, Vaxry is considered abrasive to some of the ultra-privileged leftwing US tech sphere. Most people don't care, just as people don't care about DD's views when using Sway, Miguel de Icaza's views when using Gnome, etc...
The linux developer community has quite a diverse set of opinions so it would be unfair to say that they despise hyprland. At most it's just a small number of developers who hold such an extreme position.
I don't think despised is correct. Drew made an argument for more mature and responsible behavior and leadership but some people just want to write code and not manage a community. I think that can be a lot to expect from some young programer thrown into the public eye, Hyprland is a well regarded implementation amongst tiling wms but the category always has and in my opinion always will have limited appeal for good reason.
Sure I agree that wayland (the project) could have provided these abstractions much earlier. But anyone else could have done it, too. We get all of this for free, so we shouldn't complain if other people don't do the work that we could do just as well.
reply