The "Problem" With Distros Shipping Hyprland
Vložit
- čas přidán 21. 01. 2024
- Hyprland has gained a ton of popularity over the past few years and it's been a bit of a nightmare to get distros to package it but why is that the case and how is it changing.
==========Support The Channel==========
► Patreon: brodierobertson.xyz/patreon
► Paypal: brodierobertson.xyz/paypal
► Liberapay: brodierobertson.xyz/liberapay
► Amazon USA: brodierobertson.xyz/amazonusa
==========Resources==========
Alpine Hyprland: gitlab.alpinelinux.org/alpine...
Old Alpine Request: gitlab.alpinelinux.org/alpine...
Void Linux Request: github.com/void-linux/void-pa...
Hyrpland Issue: github.com/hyprwm/Hyprland/is...
Debian Issue: github.com/hyprwm/Hyprland/is...
Debian RFP: bugs.debian.org/cgi-bin/bugre...
=========Video Platforms==========
🎥 Odysee: brodierobertson.xyz/odysee
🎥 Podcast: techovertea.xyz/youtube
🎮 Gaming: brodierobertson.xyz/gaming
==========Social Media==========
🎤 Discord: brodierobertson.xyz/discord
🐦 Twitter: brodierobertson.xyz/twitter
🌐 Mastodon: brodierobertson.xyz/mastodon
🖥️ GitHub: brodierobertson.xyz/github
==========Credits==========
🎨 Channel Art:
Profile Picture:
/ supercozman_draws
#Linux #Wayland #Hyprland #FOSS #OpenSource
🎵 Ending music
Track: Debris & Jonth - Game Time [NCS Release]
Music provided by NoCopyrightSounds.
Watch: • Debris & Jonth - Game ...
Free Download / Stream: ncs.io/GameTime
DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase I may receive a small commission or other compensation. - Věda a technologie
If anyone missed this part, Hyprland is a dynamic tiling Wayland compositor based on wlroots that doesn't sacrifice on its looks.
when did he say that??
I know it doesn't sacrifice on its looks, but what is it based on?
Are its looks sacrificed in order to be a wlroots-based Wayland compositor with dynamic tiling?
Indeed. One of the best wayland compositors around. I especially love the community too. imgur_a_jCxNR3o
What is a monoid in the category of endofunctors?
So I hear that Hyprland is a dynamic tiling Wayland compositor based on wlroots that doesn't sacrifice on its looks.
Apparently
I wonder if this will become a new meme
@@afroceltduck I hope so, think of fitting that on a T-Shirt.
@@afroceltduckit already is. Oh, and I use a dyniamic tiling Wayland compositor based on wlroots that doesn't sacrifice on its looks btw
where did you hear that???
Mixing Debian with the "latest" anything is a sure way of not having that package
This is what made Debian a nonstarter for me for a decade. But nowadays with flatpak, Nix and distrobox, you really can have a host system that is rock stable while running the latest & greatest on top.
That said, Hyprland >0.32 installed via Nix on top of SteamOS isn't working on my system, seemingly due to mismatches between the compiled and present versions of MESA, so take my comment with a grain of salt.
I forced the latest kernel on Debian 8 way back. Learned a bunch about everything, wouldn't recommend but it worked!
@@BrokenAtarinow force the latest version of Mesa on the same machine
everyone seems to forget SID exists when talking about Debian.
Brodie is a dynamic wayland shill that doesn't sacrifice on his takes
X11 is a static bit rotting monolith that archaically sacrifices it's regression shills.
Can't wait for Brodie to be packaged in Debian so that i can send bug reports about 3 year old dependencies
truly a taker of takes.
The closing comment should've been "and don't sacrifice on the looks."
Oh, didn't realize that Hyprland was officially in Arch repos! Thanks for letting me know. Been running on AUR for ages now.
NixOS has zero problems with shipping different wlroots versions
...but lots of problems with bloat and immutability for people who probably shouldn't be using Linux in the first place if they need immutability to protect themselves from their own Linux ignorance.
Well, yeah, that's it's entire reason for existing. lol
Other packaging systems would too if they actually weren't so stubborn with the latest version only system. Libraries are already linked with a version in the filename anyway, this is easy to implement, this should be easy.
@@kreuner11 That's not my experience with the Portage package manager in Gentoo - but, of course, to use it you have sit down and overcome a steep learning curve to understand better how compilation from source works, and the topology of a Linux system.
Alternatively, you can just be lazy and have someone else "wipe your backside" for you, not understand how Linux works anyway, and then rely on immutability protecting you from yourself, and bloated package managers that let the "there's too many distros" whiners treat package management like "Pick 'n' Mix" sweeties.
My experience with Nixos is the exact opposite. No bloat, it has the apps I need and nothing else. Don't care for immutability, but the ability to rollback is a God send for people that use Linux for production use.
The fact slackware has a hyprland package lol
to be fair, calling slackbuilds "packages" is a tad generious. it's more akin to AUR packages
I think any source based distribution can easily add support for package, like in Gentoo all you need is writing a ebuild and compile it.
@@user-fs3tb2xf4w nah even source based distros strongly prefer non-vendored packages. like slackware only distributes the binary because they don't like how the source is packaged
Gentoo has an ebuild for hyprland but uses a bundled wlroots.
@@hostgrady "nah even source based distros strongly prefer non-vendored packages."
That statement makes no sense whatsoever.
" like slackware only distributes the binary because they don't like how the source is packaged"
No, they distribute binaries because they are predominantly a binary based distro. Gentoo is predominantly a source based distro with the option of using some binaries.
I manually compiled hyprland on Debian like a year and a half ago. That was a nightmare on a crappy ten year old Atom processor, but it ran pretty well once I figured it out. Had to update to a testing build of GCC at the time, and by some miracle managed not to nuke my Debian install in the process.
The speed-reading of the hyprland summary is even funnier when watching at 2x.
Dependency versioning is a pain and using system packages for it suuuuuucks in almost all cases beyond enterprise where they care about pinning so much they even want the bugs to be preserved and replicable. I deeply value hermetic and repeatable builds; the state permutations get fucking wild when my project has to build against whatever bs your system has installed vs. what I've done testing and design against. This usually isn't a big problem for your every-day consumer, but it's probably one of the biggest "wait; you're telling me it's held together with duct tape??" problems facing modern software.
"The speed-reading of the hyprland summary is even funnier when watching at 2x."
How do you learn anything from "speed-reading"? Maybe that's your core problem here, one of attention span?
"Dependency versioning is a pain and using system packages for it suuuuuucks in almost all cases beyond enterprise"
Define "beyond enterprise", please? Because as someone who works in security testing applications with developers in enterprise, I don't see anything "beyond" it, given that security restrictions and testing are at their strictest in such environments. So the above makes no sense as a statment.
"where they care about pinning so much they even want the bugs to be preserved and replicable."
No, they want the bugs to be fixed, just like everyone does.
" I deeply value hermetic and repeatable builds; "
Yes, it's called "system cloning" and "backups", sysadmins have been doing both for decades. Do try to keep up.
" the state permutations get fucking wild when my project has to build against whatever bs your system has installed vs. what I've done testing and design against."
Maybe you're just not a very good developer? You seem a bit hyper and swear a bit too much, maybe start by calming down a bit? Just a thought.
"This usually isn't a big problem for your every-day consumer, but it's probably one of the biggest "wait; you're telling me it's held together with duct tape??" problems facing modern software."
I have no idea what that means.
@@terrydaktyllus1320 "how do you learn..."
The speed-reading remark was about how he read the hyprland's tagline faster and faster each time. As for my watch speed, I watch most vids at 1.75~2.75x speed because it saves time and I don't find it detrimental.
"define..."
Perhaps "other than" would be better phrasing than "beyond". I'm talking about almost everything else (e.g. the desktop; where most people don't want to re-validate a new system image whenever discord updates, and there's little reason to do so)
"they want the bugs to be fixed"
Yesn't. Really, the bugs don't matter. What matters is lots of words ending in "-ility" like stability, reliability, reproducibility, predictability,... Bugs can be worked around but only if you know about them. Fixes are nice-to-haves, but a proven and well-understood $thing is a requirement (typically). But you already know that, because you mention: ...
"system cloning..."
Cool. Two things: 1) that's operating on a different level than what I'm talking about and 2) that's a hack to solve problems, of which at least some arise from what I'm actually talking about.
"Maybe you're just not a very good developer ... start by calming down..."
What I posted was a youtube comment not a paper I want published so
Well, you do kinda need a 'stable'-ish version for most distro packaging. The development of hyprland is going at warp speed right now.
Yeah I learned my lesson with experimental software specially for something this important. If I ever switch to Wayland it will be gnome. Maybe KDE.
Been running Hyprland for about a year now on Arch. Still running with the git packages because I hate myself. A few changes to settings syntax have caught me off guard, but otherwise mostly smooth sailing. My main problem is I keep tweaking my key combos when I come up with better ideas, then forget I've changed them.
From somewhere I remember that one of the benefits of shared libraries is that they can get security updates independent of application.
That's the biggest reason. It's also more efficient in memory and disk usage, provides better caching, requires less time to build an entire distro and leads to smaller downloads. In my subjective opinion it also leads to better software engineering.
But it doesn't work that well for rapidly changing bleeding edge stuff, which is where hyprland is right now (and where debian isn't).
@@foobar8894 it also doesn't work when a project decides to, well, patch a dependency to something slightly incompatible
while not officially a fork, in practise, it is one
I think it's pretty fair for distro's to have big reservations of bundling a specific git commit. On a rolling release less so but if you may end up using it for a long time such as Debian.
Using system libraries in principle seems like a good goal, though not an absolute must.
Yeah seems it would be better to use flatpak (or another similar containerized package system) rather than distro packages if you need to use a vendored dependency like this.
@@olnnnexcept flatpaks are Not made for this use case at all. Flatpak isn't Designed for system Applications like a compositor.
@@keit99 None of them are. Maaaaybe snaps.
Why's it the distro's job to package the latest versions from git anyway? If you want them then learn to build them yourselves and how to isolate them on your system so you don't interfere with the existing package manager.
You're asking for "the best of both worlds" here - you're demanding the capability to have the latest versions of software but don't want to take on the responsibility of managing your own systems probably when doing it yourself.
Brodie bringing that Wayland 🔥today
I don't think Hyprland is in the wrong here. They have a use-case that requires unstable versions of dependencies. Most distros fail to accommodate this use-case. I think systems like Nix, Nixpkgs and NixOS solve this problem in a very elegant way, compared to just bundling all dependencies like Flatpak, Snap or AppImage.
This is absolutely a problem with distros and packaged versions of deps, if my project needs a specific version of cmake or whatever to link against I can usually install that version.
It would be like during the switch to python 3+ all distros just dropped support for all projects that depended on 2.7, it's not like having 10 wlroots releases for every major upgrade of a distro actually matters.
Hello, Fedora Packager here !
You made a pretty terrible comparison here when comparing other distro's policies to Fedora's. Because you cannot simply compare those policies. Fedora has a very lax approach to bundling, it never forbade it, it just heavily discourages it, but if it is impossible or impractical, it has no issue with bundling. It simply requires packagers to keep documented in the package what is bundled so that it can identify packages which could be vulnerable to a possible security issue in case a bundled dependency has a security vulnerability.
For example, I maintain a very niche package, multimarkdown, which still gets bundling, and yet Fedora could absolutely live without that dependency.
Most distros though are way more strict on bundling, and hyprland may never get packaged there. So, taking Fedora as an example of distros making exceptions for hyprland is a terrible comparison.
I don't think it'll never packaged there, I expect it to eventually change of they'll try and justify why having a seperate hyprland-wlroots package isn't the exact same thing
I have Hyprland currently on Nobara, and so far I've had it running fairly smoothly.
I've spent enough time debugging broken symbols and missing shared objects to know it's often better to just statically link them when reasonable (Or containerize them with bundled dependencies) and just be done with it.
As a developer, If my dependency is unstable (wlroots in this example) then I bundle it with my app, if it's stable (like GLFW) then depend on it externally.
No wonder we devs love containers. If it "Works on my machine" it works everywhere. And storage is dirt cheap nowadays so who cares about the extra 20MB
Jeez louise, it's almost as if analyzing these things on a case by case basis results in good outcomes!
Don't get me wrong, I *hate* it if I need a super-specific version of something to build a project, but I'd be lying if I said there weren't times to do it. If your project is moving faster than your upstream dependency, and you feel confident enough in your awareness and competence with asking users to run interim versions, then depending on both the code style and release philosophies, there are 100% legitimate use cases for patterns like this.
I've been working on a compositor, and lemme tell ya, one of the things I love wlroots and it's ecosystem for is it's progressive nature and not shying away from replacing things that need improvement, but even when under *active* development, the upstream changes are hard to track if you're not intimately involved. If I were to publicize my current project outside of my own use at the moment, I would 100% have to just tell people to pin an interim wlroots.
All comes down to how "tightly integrated" the dependency is. I want a system openssl, openssh, curl, etc. upgrade to immedately take effect w/o upstream re-builds on most things, and I think that's a reasonable expectation. wlroots, however, is relatively tightly integrated with the codebase of the compositors based on it, so short of everyone following *exactly* the same release schedule, it actually somewhat surprises me that *more* of the wlroots compositors aren't shipped statically-linked or something similar.
Thanks for being sane, and just acknowledging that, hey, really depends on your project, and what you're depending on whether or not this is acceptable. Easily the most level-headed take in this dumpster fire of a comment section 😆
This feels like a great opportunity for static linking, where the idea of a package dependency wouldn't even exist at that point. If you're already using a very specific git commit build of the library you already arn't going to be sharing that library with any other code on the system, so memory reuse isnt a benefit. Neither is file size. On top of that you might be able to squeeze some performance out of LTO in that case as well.
Perhaps I am missing some details though.
If you watched the video you would have seen that that's not an option either.
Static linking is supported by hyprland/wlroots but is not acceptable according to distro rules.
Another supported option is a prefixed wlroots which does not conflict with system wlroots, but this also is not acceptable according to distro rules.
Packaging criteria demand that all dependencies be used as system packaged.
There is no technical problem here - it can be guaranteed that a correctly built hyperland package will not cause conflicts on the system. The problem is the distro package acceptance criteria, it's a purely political problem. The only solution is political as well, that distros need to sometimes be a little flexible with their written rules to the benefit of the userbase and larger community.
"But can't hyprland and wlroots simply slow down development to be packageable" oh sod off. Eventually they will all be stabilised and even covered by dust and crust but for the time being sacrificing the development velocity is really unwise.
@@SianaGearz "Static linking is supported by hyprland/wlroots but is not acceptable according to distro rules."
There's no such thing as "distro rules". Not using static linking tends to be more a security requirement because leaving old versions of libraries and dependencies on a system leaves potential security holes.
But using or not using static linking ultimately depends on what security requirements you adhere to.
@@terrydaktyllus1320 If there's no such thing then why don't you steward a hyprland package into Debian?
@@terrydaktyllus1320 Well why don't you prove that there are no distro rules by stewarding this package to acceptance with one of the distros that aren't accepting it?
My only issue with most Desktop environments is the lack of system performance views. That is, I like to see CPU/Mem/Net/Disk usage and in a nice compact graphical way next to the apps that I'm testing/using. Only Plasma seems to allow this on the panel, which I prefer to have to the left hand side.
Hyprland is a cool project. It's nice to have a dynamic tiling Wayland compositor based on wlroots that doesn't sacrifice on its looks. I look forward to trying it out in the future.
i'm running void linux and i have hyprland installed through the void template that is linked on the hyprland website. it's a few versions behind right now because it needs gcc 13 to compile, which hasn't come to void just yet. i don't really care too much at the moment, cause i really started liking using swayfx as well, which is my daily driver at the moment, but this video made me realize that perhaps it could work to just make a template for the pre compiled binaries and libraries if i want to use the latest version? might have to look into that at some point.
I don't really see what's so strange about having policy exceptions for some packages. It's a cost/benefit tradeoff. Apparently hyperland is popular enough to deserve an exception. Without the policy there would be a total mess of small packages coming with their own bundled dependencies. Pretty sure the policy is there for a reason and makes distro maintainers life easier. The limit for exceptions has to be somewhere, even if its not some specific metric.
I just got into tiling window managers this month with DWM. Do people normally install binary packages of their WM? I thought they were all built from source.
That's why I like containerized or bundled applications: The developer knows best which versions are compatible. If you as a distro maintainer are not flexible enough (or just stubborn) you loose. Imagine going to your web developers telling them they can only use node 12, because that's what you provide...
It doesn't need to be containerized.
"That's why I like containerized or bundled applications: The developer knows best which versions are compatible."
No, that's the exact opposite reason for containerisation - that you don't care about incompatible versions, you just throw together what works in one package... with the associated bloat, of course.
"If you as a distro maintainer are not flexible enough (or just stubborn) you loose."
So choose another distro, there's plenty of them. You not being satisfied with you implementation of Linux is not their problem. They're giving you (free of charge) their idea of what Linux should be, you can like or not like it. Don't blame everyone else because you're "difficult to please". You can always build your own Linux if need be.
"Imagine going to your web developers telling them they can only use node 12, because that's what you provide..."
Yes, you've made my argument for me. Because in that scenario, you move to a more suitable hosting platform. Like I said, move to another distro.
You sound very self-entitled. You're not paying distro maintainers for their work, you get it for free.
@@terrydaktyllus1320you aren’t even slightly wrong. But I think it’s a stretch to call him self entitled. He’s giving his opinion of preference. The beauty of Linux is the freedom!
@@Emancipatriot Absolutely, Linux is freedom and we can all have it how we want. But if you're not going to take responsibility for your own hardware or expect Linux to "wipe your backside" for you because you're too lazy to learn it properly, then why use it in the first place? Stick with Mac or Windows and stop being a "poseur".
That's the bit I don't get - how hard some people work NOT to have to do any Linux learning and expect everyone else to cater to their every whim.
@@terrydaktyllus1320 Your comment is really bad. You take this all from one POV and ignore the other two, the dev of whatever software and the user.
If the user agrees with everything related to a distro, except they want to use a certain program that depends on a different version of some library than the version the distro ships, you say that that is an argument against containerisation? A person wanting to use some software, and in many cases offering to package it (bundled, in this case), is the person being "difficult to please", and blaming everyone else?
The Dev also, for the other POV, is providing their software for free. The Dev is also free to use whatever version of whatever library they choose, why would it be the Dev's responsibility to make sure their software works on every idiosyncratic combination of rules for every distro? You say that the developer knowing what version works is the opposite of a reason for containerisation. What would the reason for containerisation be then, pray tell?
The reason is such as the other commenter said, the developer knows what works, the developer is giving you (free of charge) their work, you can be flexible to accept it or be stubborn and not, if you don't want to accept it you lose access to have this software packaged in your distro. If a user wants that software and there is no way to fit whatever that needs into a certain distro's packaging guidelines - that is a great argument FOR containerisation. The user can have it, with "bloat" and all, if they so choose.
When you say the other commenter sounds self-entitled, you are just shifting responsibilities. If the distro maintainer is not flexible enough, they lose certain software, that is just what it is. All of it isn't difficulty to please or self entitlement, it just is.
I agree that the web dev thing is a very bad example/comparison.
I still think the OBS is the best way people created to solve this sort of issue, but if it didn't catch on with developers and flatpak has, so be it. Makes no difference to me.
Hyprland on Slackware sounds like the combo the world needed!
I'm using it on Arch btw, and have been using various prebuilt setups like JaKooLit's and prasanthrangan's along with learning to configure it myself. I can't imagine running anything that doesn't run on a specific build of wlroots nor sacrifices on its looks.
I used prasanthrangan's as a base myself (on CachyOS). I know a handful of CSS now, lol. It's been a smooth ride on Intel GPU end though.
NixOS allows to have select packages be from the unstable channel, with the rest of the system being from the stable channel. Working good sofar with Hyprland and Cosmic Editor.
Gentoo has been doing that for at least 20 years. Arch also does it with the AUR. What's kept you? You're announcing this like it's a new concept, when it's just "Pick 'n' NixOS" reusing an old concept while wiping the user's backside for them.
@@terrydaktyllus1320 I don't have experience with Gentoo, my past understanding with Arch is that it's not easy to have multiple versions of a package simultaneously. If a AUR package depends on an AUR version of another package, it replaces the repo version with the AUR version system-wide. With NixOS, each package has its dependencies handled separately. So Hyprland wanting wlroots 0.18.0, and Sway wanting 0.16.2, both see the system having the version they want. I haven't used Arch for a few years, so it might be different now.
@@terrydaktyllus1320 NixOS has been doing it for 20 years too.
@@terrydaktyllus1320 Because of you I want to switch to NixOS
Ran into this issue recently where the bundled wlroots required a newer version of a dependency than what my distro offered. Checked out an older tag and it worked fine.
pop os x hyprland possible or nah i tried but it din't work yet it works on ubuntu...strange...thoughts??
I love Hyprland. I built it using PikaOS's packages for a secondary laptop as a test (ubuntu based) and it works surprisingly well. I main it on my arch desktop but I do like the idea of Debian with Hyprland
Sounds like the real issue is hyprland is riding the cutting edge of a fast moving wlroots..so both are moving targets. I'm honestly surprised any distro is bundling it at all give that is the case.
This is what popularity does, some maintainers don't want to accept that but it's the truth
Works on Nixos. I am running it without issues. I can understand those distros, hyprland is still not in a real stable state, development is still in a fast pace, as well as wlroots. I tnink it will take sometime, but eventually the projects will get really stable and distros will be able to ship it without hassle.
i use hyprland flake on nixos and it is good, just installed nixos yesterday! amazing and it works for me, i like the animations
13:25 "Because people somehow cannot use the search engine" I can get the annoyance with multiple duplicate issues but I don't get why it is assumed that they did not use the search engine. I always feel it is better to give people the benefit of the doubt (even though in this case, many issues were similarly named so it is likely at least one person did not search for the issue beforehand) because searching is a skill (as funny as that may sound) and not everyone is good at searching and given people tend to word things differently or describe things differently than each other, it is possible to search for the issue and not find any (or not find any that seem relevant) and open a new issue.
Arch actually has a policy that when packages achieve a state of acceptable or really high levels of popularity they'll be ported to the extra repo initially while continued interest will promote consideration for import to base. Arch reserves the right to waive their inclusion policy at any or all levels based on the aforementioned points. Arch policies are actually layered and, if I'm not mistaken, popular packages are subject to a vote for inclusion by the appropriate repo maintainers.
I would like to see Hyprland ported to Alpine - that would be awesome.
But if no one cares to package it then it's still not going to be packaged
@@BrodieRobertson Man power is always a hurdle for any number of reasons; I definitely see where you're coming from. Packaging, maintenance and general system stability definitely influence acceptance in turn affecting availability. This is where Qemu KVM with passthrough shines considering community testing and submission of a stable configuration - works for any distro, but the distro in question also has to have mind share else lags behind.
NixOS mentionend ‼️
...and ignored.
I like it. Using it on EndeavourOS with Stephan Raabe’s setup on my laptop. Counting the days until I feel confident enough to switch to it on my (Debian) workstation.
Hyprland is pretty raw at the moment. I had lot's of issues this weekend, so return to Sway.
I'm sorry to disagree with you because I've not had any breaking glitches for the time period I've been using it up till now. Maybe you use a Nvidia card?
@@isaacolukanni I'm not talking about glitches, but about general usage. In order to have stack layout(pretty common in wm) you need to install plugin hy3. I was not able to do it via hyrpm for unknown reason. When I switch to another empty workspace, all windows moving to this workspace and previous is gone, etc.
Is to feasible to make appImage or flatpack builds of hyprland??!?
If a "fork" of wlroots is made specifically for hyprland, could that comply with the distros' policies?
yes, in theory, the issue is that you will have to not only maintain hyprland but also you will need to maintain the fork of wlroots and at the speed that everything is advancing you will end up with the same issue, cuz you will never have a "release" version of that fork
Fortunately, some good install scripts exist (Thank you JaKooLit :)) so we don't have to depend on the whim of a distro maintainers. Hyprland is the best thing that happened to Linux desktop in a verly long while :)
Daily driving Hyprland on Garuda linux. Love it!
So thankful to solopasha for creating the copr for fedora. Installed it today on a Fedora 39 Sway spin install. Need to do some real work over the next week to confirm, but so far I'm over the moon. At the moment I'm totally in favor of ditching sway for hyprland. A real shame about the packaging problems though. I wonder if in a few years, both packages will be stable enough that building the latest git commit won't seem so important and hyprland can be adopted by more distros.
I briefly dabbled a few days ago with Hyprland 0.24.1 I built manually on my Debian bookworm machine. Unfortunately, that is the latest build I can use as there is no proper C++23 support in either GCC or Clang in this Debian release. Additionally, more recent tagged releases require newer libdrm and libinput which I'm not willing to track manually. It was fun while it lasted.
I like Hyprland, used it for a few weeks on Arch until I realized that I don't need anything it offers that i3 doesn't already do (I don't like animations/blur/transparency and most other compositor features, and wayland as a whole hasn't done anything for me yet either). I'll happily try it again if/when the prophesized end of X11 comes, but I think until then I'll just stick with what works for me.
And hey, who knows, maybe by that point wlroots will have settled into more of a steady state and Hyprland will be free to drop the "I need those git version exclusive API calls" requirement.
Currently running AUR hyprland on minimal ARCH.
Brodie screen capping this video on Hyprland, which btw is a dynamic tiling Wayland compositor based on wlroots that doesn't sacrifice on its looks, is low-key max Linux flex. 💪
Brodie, are you planning on making a video on the Bun Shell?
Would love to hear your thoughts.... Maybe this was the final frontier for JavaScript?
Sir please make video about minimum specs to run Wayland/hyperland
Because my device only show blank screen when run wayland
It's spec of my old laptop
- intel i3 m370 (integrated graphics)
- virtualization: vt-x
To reverse this issue - allowing bundled dependencies would need finding a way on distros side to not kill dependency cycle graphs between applications. Additionally - eli-schwartz mentioned COPR and PPA, not official packages.
I think it's worth mentioning that Hyprland is not available on Fedora 38, but it is on Fedora 39. I'm currently running F38 and considering upgrading to F39, assuming F39 is actually an 'upgrade' and not a 'bad' version like F37 was.
I'm using arco linux's hyprland. It works soooo well for my nvidia card that I can't leave it now. I think it uses nvidia dkms for this. I even got DaVinci Resolve working with just installing the AUR package (which never worked for me on fedora or any other distro).
You can run hype land by building it using void src packages and it works very well from my experience :))
I gave in the Brodie Hypr Hype a couple weeks back.
First attempt was unfair. Doing CachyOS reinstall, saw on list, figured I'd try it, but was in too much of hurry to get productive again to put the time in required.
A week later, I tried again, but poor performance in BAR [Beyond All Reason] kicked me back out, as it compounded with other nuances that were irritating me.
It is cool, I'd like to swtich to a WM, but maybe gonna give it another couple of months before trying again.
how is hyprland with nvidia non free drivers ?
What's so good about hyprland anyway. Rounded corners and blur? Other wms don't have that?
On Wayland it's not common, also you have working window capture, window animations, global shortcuts before the introduction of the portal, and a ton of ricing features that aren't common to all see in one place on Wayland
@@BrodieRobertson thanks!
Fedora has policies and guidelines on how to bundle libraries since before 2018, it's not recommended though cos it makes it harder to track library issues.
But either way, I wouldn't blame eli's comments on Fedora considering that they made them on 2022 and Hyprland was packaged in Fedora 39 a couple of months ago (Nov 2023).
This problem is so linux specific its crazy. On any other platform bringing your own dependencies is the expected thing to do, especially when the default ones don't even work. That's why I love the AUR, as long as it's not malicious, a package can exist there basically for ever untill enough people get mad to break a policy.
And it's a weird policy to me. wlroots describes itself as "about 60,000 lines of code you were going to write anyway". What would have happened if the Hyprland dev had written those 60k lines instead of pulling in wlroots? The distro package maintainers would have happily included Hyprland!
@@MarcusTheDorkus exactly. Not every dependency can be treated as a "black box". Wlroots is designed to be built on top of, not against. You can argue about something like libcurl where you call a simple API and get a response and there are many programs on the system that require it, but not everything is this simple and stable (ABI compatibility) and usually you only have one compositor on your system so there isn't much duplication either. Another (arguably small) reason is link time optimization, having a dynamically linked library prevents that completely afaik.
*For current Hyprland daily driver users: How has your experience been?*
(wanting move over eventually from Sway)
Went from a daily driver Hyprland user for months to Sway. My takeaway was that Hyprland isn't qualitatively different or better, and that it requires some compromises to use. Happier in Sway (using 1.9rc1 atm).
Hyprland is stylistically different, its development community has a different aesthetic than the wlroots community, and it is more opinionated than Sway re UI. There's little or no connection to i3, it is more shell-focused than IPC message focused. Sway documentation and community is more mature. As a user, and as a Linux developer who is dabbling in Wayland compositors and clients, the Sway/wlroots ecosystem just seems healthier.
I don't have much data about performance, as both run as fast and smoothly as I need them to, but obviously instrumentation shows that Sway is much lighter on resources; smaller memory footprint, less intensive CPU (obvs Sway ootb doesn't stress GPU).
I began using Hyprland this year with Arch Linux, just an challenge to use a daily driver desktop, since I was using Nobara Linux, and I liked Hyprland tiles alot. So far its almost been smooth sailing, sometimes when I close the tabs on firefox to fast it fails to open, and I have to wait a lil to open. Gaming has almost been perfect, Cyberpunk just fails to open, but its not a deal breaker for me, since Ill try to fix it later(cause I hate myself), and borks my system, which sucks, but so far no other game aside from Cyberpunk has borked my system. But overall my system, which is totally overkill, but it runs extremely nice, and the customization is just so nice! I think imma good time with it, until something breaks xD
I don't know why but whenever i turned on my pc, Hyperland is there to give me a warm welcome it's feels like home and i love that feeling .❤
I can only see the option of a full statically linked system maybe for inmutable distros. I any other case, not having fixed versions of main libraries is a security and maintenance nightmare.
Hyprland on 2 systems for 14 months. I have found my home.
The funny thing is if vaxersky just forked wl-roots to a "new project" named, say, "hypr-roots" that just constantly synced against upstream, these policy violations *disappear*
A lot of distros still don't like shipping a dependency that only 1 package will ever use
why cant they just statically link to wlroots.
This would be well suited for Guix or Nix, where the package definition would lock the commit for its wlroots dependency.
freebsd packaging already can handle specific versions of a dependency, so that makes total sense
there was also some "drama" on the void linux irc because of hyperland. i think some of the maintainers will never accept it in, because they dont like the hyperland dev. iirc.
Started running it, but not done configuring it nor 100% sure I will keep it. But it is nice to be running Wayland on my primary computer:
(Self compiled on Debian unstable)
What *is* hyperland? It's a wm but why is it so suddenly popular? What am I missing?
Didnt realize the issues with hyprland, very intereating.
I love a good root. I've been a fan for years.
Running Hyprland on CachyOS. I ran into an odd issue where Palworld black screens on launch under Hyprland, but runs fine on GNOME Wayland. Just need to get the time to log hunt and figure it out. Otherwise it's been a pretty smooth ride as most of my issues are Intel Arc in relation to games.
Wow
Hyprland + Intel Arc sounds like A stability nightmare.
But someones gotta find the bugs somehow.
@@nullvoid3545 Intel & Hyprland are fine, works out of box. What I mean is that because Intel shat the bed on DX12 support, running newer games can require extra launch parameters. Older stuff like Bnet games & Warframe run flawless.
@@gorrumKnight Well that's good to hear.
I think I may get an intel card if I ever upgrade my 1060 so I'm happy the bumps are being smoothed out.
I think once 6.8 & Mesa 24 are out DX12 should be in working shape, so do hold off if you're playing anything new that needs DX12. Definitely eyeing a Battlemage card when they materialize.
Recently moved from i3/XFCE to try out some DEs, when I tried to run Guild Wars 2 my whole system locked up, eventually I remembered you talking about Hyprland, and I don't think I'll ever look back. Oh and now GW2 runs fine again.
Why is it a Linux problem when a game designed to run on Windows doesn't run properly on Linux? Why not just play it in Windows and stop posing on social media about how "l33t" you are because you use Linux?
@@terrydaktyllus1320 are you feeling inadequate or something? I just mentioned why I like Hyprland.
@@Vertex_Draco "are you feeling inadequate or something?"
This isn't a discussion about me. Do try to keep up and stay on topic, there's a good chap.
"I just mentioned why I like Hyprland."
You also whined about your Windows game not working on Linux... a bit like whining when your petrol car doesn't work after you filled it with diesel fuel... that sort of thing.
@@terrydaktyllus1320 the fuck is your problem? I mentioned a game not working when I tried some DE's, now it works on Hyprland.
"This isn't a discussion about me. Do try to keep up and stay on topic"
This is a discussion about whatever the fuck I say it is. You are the one who replied to me, freaking out because someone dared to mention that they play games on Linux... On a channel about Linux... By a creator who's made videos about gaming...
You need a reality check. News flash people have been playing Windows games on Linux for a long time. The game has a platinum rating on proton db but it only stopped working when I tried out some DEs, now the problem has been fixed by going back to a WM. The fact you jumped right to calling me "l33t" and a poser because I'm a Linux gamer says more about you than me.
@@terrydaktyllus1320 This is a discussion about whatever the fuck I say it is, you're the one who replied to me. I don't know what the hell your problem is but you need a reality check. People have been playing Windows games on Linux for a long time now, the game in question has a platinum rating on Proton db, and only stopped working when I moved from a WM to a DE, now it works after moving back to a WM/Wayland compositor. The fact you jumped straight to calling me "l33t" and a poser just because I'm a Linux gamer says more about you than me. This is literally a channel about Linux, and a creator who's made videos about gaming on Linux...
Saying your package manager won't support static linking when there is a system package available is wild. Can you imagine Adobe testing against every library combination for debian, red hat etc?
Wait, this is not a flatpak story? 😂
😆🤣💦 Lost my drink!
Would a flatpak window manager work? I assume not, but that would be really cool.
I don't know if anyone has tried it
@@BrodieRobertson Be the first, Brodie, be my little test subject
Oh yes. Void Linux doesn't packaged Hyprland natively as well. They may have their reasons but it still kinda sucks. But making the best of it, I'm dabbling in River at the moment. Pretty interesting though there are no animations, blur or rounded corners.
Hyprland as a Flatpak seems to make a lot of sence though.
Why can't wl-roots be forked, then the forked version be required?
if you fork wlroots you will have to maintain it you will have to make some changes that makes some differences in order to be accepted as a "different project" and at the speed that wlroots is going you will end up in the same place, a fork that doesn't have a real release version
@@josecamilojimenez2784 well, since vaxerski is already maintaining a wl-roots "clone", the work to maintain a fork is basically done already. Most of what is left is packaging and distribution.
@@RichardBronosky not really, he is not maintaining anything, he just pulls the version of wlroots he needs and that's all, for it to be consider as a different library it needs core changes and release versions which will never have so again, you will end up in the same place cuz distros aren't going to accept a "fork" of a library that is basically the same library; In other words, dirstros aren't going to accept a car called "tiny cooper" as a new car when everything about the car is just the same as a mini cooper but with just a different stamp in the front
This is nothing to do with what's in the video but I have the same shirt but Great video
As requested at the end of the video:
Arch, latest wlroots built with `pkgctl` (not aur). I used Hyprland for a few months, but have moved to Sway.
I'm much happier with my current package configuration. I compile wlroots-0.17 for reasons other than satisfying Hyprland (developer/want a native build/building and using sway-1.9rc1-5). Hyprland was interesting, and I'm glad it shows off Wayland and wlroots, but ultimately not interesting enough to devote consciousness to its idiosyncracies (or defending its community, lol).
Imo, from what I've seen (which is a fair bit), there's no real technical reason to vendor wlroots. Even if we accept that Hypr needs a different version of wlroots than what the distribution provides, it can be built against that version without vendoring it (ie, in Arch you could specify wlroots-git; that wouldn't get hyprland into the main repositories, but you'd still have a better environment and be that much closer).
[EDIT Further down in the comments others have pointed out that your characterization of Arch policies is inaccurate. It's in "extra".]
I'm new to this. Isn't this exactly the kind of thing that Flatpack is supposed to solve?
Are you sure that they are not unvendoring hyprland and build it using their own dependencies? This is what many distros do with `pip` and probably most other packages they want to support that vendor dependencies. Maybe that's impossible with hyprland though?
lmao nevermind gotta finish the video before commenting
If I can get hyrland to look like my basically default i3 config than I might consider switching
I dont get it. If it is bundled is it not "not a dependency" by definition? Many/all of these distributions use snaps and flatpak, how can they complain about this?
Snaps and flatpaks are packaged seperate from the distro policies and don't effect the distro
isn't wayland too new to be on debian anyway ?
I think wayland is an option on debian, but it uses X11 by default.
Wayland works great on Debian. I am using Sway on Debian right now.
Hyprland will probably not get into the void repos any time soon since the dev came into the void linux subreddit and managed to get banned within just a few hours, so i doubt the maintainers would accept one of his project at this point
Can't wlroots be statically linked
This is why everyone should be running NixOS (jk). I run Hyprland on NixOS on my laptop but I can't get scaling working well on my desktop 4k 28" monitors.
No thanks. Gentoo has been fine for me since 2003 on single 1080p monitors and virtual desktops, me not having independently rotating chameleon eyes that let me focus on two screens independently.
4K is a gimmick anyway and multiple 4K monitors are used only by poseurs on social media bragging about how their computer work areas look like a Boeing 747 flight deck.
Mind you, with modern "goldfish-like" attention spans in the younger generation, you probably do need to be constantly flicking back and forth between two 4K screens, a tablet and a mobile phone with a TV and Netflix on in the background.
@@terrydaktyllus1320 on 28" monitors I think 4K looks noticeably better, especially in desktop applications. Borders are crisper, text looks nicer.
I'm also not sure why you made this a generational thing? Go into any engineering office and basically everyone will be using at least two monitors. It really does provide a tremendous productivity boost
Running Hyprland on Guix (external channel).
So I know that Wayfire's AUR build with vendor wlroots conflicts with system wlroots (or at least did at one time). From what I'm getting here, Hyprland is the same way.
Is this a case of bad packaging, or do vendor dependencies not actually work?
Assuming vendor dependencies do work and AUR builds are just bad, I'm more on the side of vaxxry. I get why distros wouldn't want this, and there's a slippery slope argument where you end up with everybody wanting their own dependencies. But overall I'd just rather have the software available.
That said, I think it's kind of silly how vaxxry just completely discards the idea of supporting stable versions of wlroots. Maybe not *now* if there's features he actually needs *now* from git wlroots. But I see no reason why he can't allow some future version of wlroots that has what he needs. And once it gets there he can just require $LATEST_VERSION of wlroots. He doesn't need to have these ifdefs or whatever for supporting every version of wlroots that ever existed.
Anyway, this is exactly why I wish Flatpak didn't assume an existing desktop session. It would be great to put desktops or wms in flatpaks for exactly this reason, among others.
I think hyprland is being accepted not just is "popular", It's because it's popular and not usually installed on commercial envs.
Distros need to be as stable as possible, mostly to be able to be used in commercial environments. (Certifications, validations.... you name it). Having modularized packages with common libs, etc... helps a lot with that. (In most cases, is the only way to certificate a distro).
Having a random app pointing to a random revision makes it hard. But in this case, no one will try to install Hyprland on a production machine for anything. If anyone needs a DE will choose Gnome or something else.
So it's not as bad. Trying to do this with java or openssh for example will for sure not be accepted.
Well I wasn't expecting an eli comment in a video today.
Hyprland is a tiling Wayland Compositor based on wlroots that doesn't sacrifice on it's looks.
Having certain popularity threshold -- after which a package is allowed to bundle whatever dependencies via static linking might make sense. Make this official approach, rather than case-by-case discussions. The question would be how do we measure "popularity"...
IMO this isn't a hyprland issue, it's an issue with the archaic system of distro-specific repackaging. This is why NixPkgs doesn't have a problem -- You can specify the EXACT git commit of dependencies if you really want, and it won't ever clash with your other packages. All while not relying on containerisation.
Finally a good example of what I refer to as Linux's Dependency Hell, and why I (personally, don't @ me for this) prefer Windows' approach of each application being fully self-sustained (where apps come with all their dlls of all dependencies and such, at the cost of repeating same libs over and over on the drive), with exceptions being to things like pip calling gcc or everyone using the same jvm
also some people in comments are mentioning the polar opposite approach of banning using outdated versions, making sure all projects are always latest and forwards compatible, i think it is such a mythical take tbh
Hyprland in Gentoo for 2 weeks now and is working perfectly fine. I dont even think sway anymore for Wayland. Packaging for all distros should be the norm not the exception.
now that Hyprland has fixed all of the cursor problems in games, and just works, i only use hyprland, i do get freeze of the whole computer and still problems if i move to a tty and return to a black screen.
but else it is perfect.