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.
...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.
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.
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.
@@IchikaZou 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
@@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 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.
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.
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.
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.
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 😆
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...
"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.
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.
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 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?
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.
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.
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.
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.
@@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.
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'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.
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
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. 💪
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.
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.
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.
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.
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.
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.
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.
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
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?
@@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...
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.
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*
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
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).
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.
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.
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.
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 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.
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
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.
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 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.
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.
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.
@@vaxryy "I think you should look up the definition of a joke :P" Ah, yes, a "climb down". I could care less, by the way. GNOME is crap also, I haven't used it since GNOME 2 finished.
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
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.
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.
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.
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
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)
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?
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
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.
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"...
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.
@@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.
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.
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.
You mean "Pick 'n' NixOS", surely? "I'll have one of those packages over there, two of these over here, with sprinkles and a flake on top". "Linux for Babies" that even changes your nappy and wipes your bottom for you.
@@terrydaktyllus1320 I'm sick of your hate for NixOS. NixOS is NOT Linux for Babies. You don't like it? That's fine. But it's great for a lot of people. And I saw you mention in another thread here that people aren't earning how to really use Linux. Linux is a kernel, not the complete operating system. People generally don't directly do things with the kernel. NixOS is a very different distribution, and some have argued it's not a "Linux distribution" in the traditional sense, much like people argue Android isn't Linux even though it uses the Linux kernel. And that I can accept. I consider the operating system to be the distribution itself. No, I'm not one of these people saying "It should be called GNU/Linux". So what's the right way to use Linux? Well how did the creator of the distribution mean it to be used? That's a big part of it. Besides, when using Arch, you don't use apt. But for a Debian or Ubuntu user that doesn't know any better, they might think that command is incorrect. "How to use Linux" ultimately, in many ways, depends on the distribution. NixOS has a valid, yet very different way to use the operating system. It's not the "wrong" way. It's just different from most distributions. And same with other immutable systems like Steam OS. I've been using Linux since 2000, before the recent rise in popularity of the immutable distributions.I don't consider "NixOS" easy for beginners but yes, it does make certain things a lot easier once you've learned it. So people like how NixOS handles package management. You don't. Well get over it. No one is forcing you to use it, and not everyone is switching to it anyway because of the learning curve. Thank you and goodbye.
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
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?
The situation is plain and simple. The software is in early development stage, thats why it has these weird quicks for compiling. Wait 2 years for it be to stable. Then package it for distro official repos.
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).
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?
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
The idea that everything on a Linux system must use shared dependencies is and has long been one of the biggest sources of practical usability issues in Linux. There used to be good arguments for it when people had only a few gigabytes or less of disk space available, but at this point it's mostly just a philosophical devotion to the concept of "anti-bloat" even if usability suffers. Here we have distros refusing to package a popular application because doing so would foul up their perfect playground of shared dependencies. Not in a way that breaks other programs, just in a way that makes it "messy". I think programs packaging their own dependencies on Windows is a strength, not a weakness, and just because something is "the Unix way" doesn't mean it's automatically good.
Nowadays, all those development or resource issues have no point, as you say. But shared libs have a VERY important role if you want to use the OS on any production environment. Imagine you follow your filosophy and use a Distro with all the apps statically linked to their dependencies at the versions they like. Now imagine that the ssl package has a 0 day exploit bug and a new version has been released in hours to fix the problem. You are the manager of 100 vms like the one above. What do you do? You are the vendor that sells that Distro what do you do? On current distros, the vendor rebuiilds and publishes a new package. The user just download a package and restart the affected services. That's all.
"The idea that everything on a Linux system must use shared dependencies is and has long been one of the biggest sources of practical usability issues in Linux." That's a "straw man" argument. You can solve what you describe to be a "usability issue" by building Linux yourself or using a "compile from source" distro - I, as a Gentoo user, for example, do not recognise what you describe as a problem. Sure, you may not want to put in time and effort to working with Linux that way and then you rely on a distro maintainer to do that for you - and that's only as good as they are. But there is a solution to a problem with a bit of "DIY". You may also be able to solve the problem simply by changing distro. "There used to be good arguments for it when people had only a few gigabytes or less of disk space available" And that's fine for you on your gaming PC with 66 Ryzen cores and 100 terrabytes of storage but take your blinkers off and realise that the world is bigger than you - countless embedded systems, car management systems and IoT devices also run Linux and all of them do not have the same amount of storage that you do. ""but at this point it's mostly just a philosophical devotion to the concept of "anti-bloat" even if usability suffers."" "Usability" is a subjective premise. A Linux system with shell commands to allow me to write scripts to automate tasks would be "unusable" to me, yet many of the whining "baby Linux users" on here scream loudly if anyone expects them to open up a shell prompt. And "anti-bloat" (i.e. "efficient coding") is always good. "Here we have distros refusing to package a popular application because doing so would foul up their perfect playground of shared dependencies." Remember that you don't pay them to maintain their distro for your specific requirements just because you can't be bothered to learn how to package and install an application yourself. Take ownership of your computing devices, that's the CORE philosophy of Linux that you seem to be conveniently ignoring here. "Not in a way that breaks other programs, just in a way that makes it "messy"." That's not my experience in Gentoo Linux. But to use Gentoo you have to invest time and effort to learn it. Once again, there's an immediate solution to your problem if you're prepared to do some work yourself. "I think programs packaging their own dependencies on Windows is a strength, not a weakness, and just because something is "the Unix way" doesn't mean it's automatically good." I think Windows should be completely avoided because of its complete lack of respect for privacy and personal data - that makes it a completely unusable system to me without any need to consider it any further as a comparison to Linux. And care to define what you mean by "the UNIX way" in this context? Because, again, that' entirely subjective as a definition, and my definition has no relevance to any of the points you are making here. But happy to consider your definition.
