8 ms·

I hope that XFCE remains a solid lightweight desktop option. I've become a huge fan of KDE over the past couple of years, but it certainly isn't what you would

by jchw 9mo ago

I hope that XFCE remains a solid lightweight desktop option. I've become a huge fan of KDE over the past couple of years, but it certainly isn't what you would consider lightweight or minimal. Personally, I'm a big proponent of Wayland and not big Rust detractor, so I don't see any problem with this. I do, however, wonder how many long-time XFCE fans and the folks who donated the money funding this will feel about it. To me the reasoning is solid: Wayland appears to be the future, and Rust is a good way to help avoid many compositor crashes, which are a more severe issue in Wayland (though it doesn't necessarily need to be fatal, FWIW.) Still I perceive a lot of XFCE's userbase to be more "traditional" and conservative about technologies, and likely to be skeptical of both Wayland and Rust, seeing them as complex, bloated, and unnecessary. Of course, if they made the right choice, it should be apparent in relatively short order, so I wish them luck.

coldpie 9mo ago
> Still I perceive a lot of XFCE's userbase to be more "traditional" and conservative about technologies, and likely to be skeptical of both Wayland and Rust, seeing them as complex, bloated, and unnecessary. Very long time (since 2007) XFCE user here. I don't think this is accurate. We want things to "just work" and not change for no good reason. Literally no user cares what language a project is implemented in, unless they are bored and enjoy arguing about random junk on some web forum. Wayland has the momentum behind it, and while there will be some justified grumbling because change is always annoying, the transition will happen and will be fairly painless as native support for it continues to grow. The X11 diehards will go the way of the SysV-init diehards; some weird minority that likes to scream about the good old days on web forums but really no one cares about. There are good reasons to switch to Wayland, and I trust the XFCE team to handle the transition well. Great news from the XFCE team here, I'm excited for them to pull this off.
- graemep 9mo ago
  I used XFCE for a long time and I very much agree. it just works, and is lightweight. I use KDE these days but XFCE would be my second choice. > The X11 diehards will go the way of the SysV-init diehard I hope you are not conflating anti-systemD people with SysV init diehards? As far as I can see very few people want to keep Sysv init, but there are lots who think SystemD init is the wrong replacement, and those primarily because its a lot more than an init system. In many ways the objects are opposite. People hate system D for being more than init, people hate Wayland for doing less than X. Edit: corrected "Wayland" to "XFCE" in first sentence!
  - LeFantome 9mo ago
    It is refreshing to see somebody else notice that the complaints about systemd and Wayland are philosophically incompatible. Systemd is creating the same kind of monolith monoculture that Xorg represented. Wayland is far more modular. Regardless of your engineering preferences, rejecting change is the main reason to object to both.
    - graemep 9mo ago
      I do not have a strong opinion about Xorg vs Wayland. My only real concern is that it might make it harder for the BSDs but that seems to be being dealt with. I do like being able to use X over the nextwork but that is a problem that can be solved. I do dislike System D for two reasons. One is exactly because it s a monolith and, in effect, an extension of the OS. The other is the attitude of the developers which becomes very evident if you browser the issues.
      - kelnos 9mo ago
        > My only real concern is that it might make it harder for the BSDs Our OpenBSD packager has already said in our Matrix channel that he'll be testing here and there in order to keep me honest ;)
      - ethanpailes 9mo ago
        > I do like being able to use X over the nextwork but that is a problem that can be solved. And in fact has been: https://github.com/wayland-transpositor/wprs https://github.com/wayland-transpositor/wprs
    - kelnos 9mo ago
      > Wayland is far more modular. Not sure I agree here, assuming you mean "... than X11". With Wayland, you put your display code, input-handling code, compositor code, session-handling code, and window-management code all in the same process. (Though there is a Wayland protocol being worked on to allow moving the WM bits out-of-process.) With X11, display and input-handling are in the X server, and all those other functions can be in other processes, communicating over standard interfaces.
- BearOso 9mo ago
  If Rust has one weakness right now, it's bindings to system and hardware libraries. There's a massive barrier in Rust communicating with the outside ecosystem that's written in C. The definitive choice to use Rust and an existing Wayland abstraction library narrows their options down to either creating bindings of their own, or using smithay, the brand new Rust/Wayland library written for the Cosmic desktop compositor. I won't go into details, but Cosmic is still very much in beta. It would have been much easier and cost-effective to use wlroots, which has a solid base and has ironed out a lot of problems. On the other hand, Cosmic devs are actively working on it, and I can see it getting better gradually, so you get some indirect manpower for free. I applaud the choice to not make another core Wayland implementation. We now have Gnome, Plasma, wlroots, weston, and smithay as completely separate entities. Dealing with low-level graphics is an extremely difficult topic, and every implementor encounters the same problems and has to come up with independent solutions. There's so much duplicated effort. I don't think people getting into it realize how deceptively complex and how many edge-cases low-level graphics entails.
  - duped 9mo ago
    There really isn't a "massive barrier" to FFI. Autogenerate the C bindings and you're done. You don't have to wrap it in a safe abstraction, and imo you shouldn't.
    - fork-bomber 9mo ago
      This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem. Keeping the whole “it’s funded by the Government/Google etc” nonsense aside: I personally wish that at least a feeble attempt would be made to actually use the FFI capabilities that Rust and its ecosystem has before folks form an opinion. Personally - and I’m not ashamed to state that I’m an early adopter of the language - it’s very good. Please consider that the Linux kernel project, Google, Microsoft etc went down the Rust path not on a whim but after careful analysis of the pros and cons. The pros won out.
      - elektronika 9mo ago
- jchw 9mo ago
  > Literally no user cares what language a project is implemented in I think this is true but also maybe not true at the same time. For one thing, programming languages definitely come with their own ecosystems and practices that are common. Sometimes, programming languages can be applied in ways that basically break all of the "norms" and expectations of that programming language. You can absolutely build a bloated and slow C application, for example, so just using C doesn't make something minimal or fast. You can also write extremely reliable C code; sqlite is famously C after all, so it's clearly possible, it just requires a fairly large amount of discipline and technical effort. Usually though, programs fall in line with the norms. Projects written in C are relatively minimal, have relatively fewer transitive dependencies, and are likely to contain some latent memory bugs. (You can dislike this conclusion, but if it really weren't true, there would've been a lot less avenues for rooting and jailbreaking phones and other devices.) Humans are clearly really good at stereotyping, and pick up on stereotypes easily without instruction. Rust programs have a certain "feel" to them; this is not delusion IMO, it's likely a result of many things, like the behaviors of clap and anywho/Rust error handling leaking through to the interface. Same with Go. Even with languages that don't have as much of a monoculture, like say Python or C, I think you can still find that there are clusters of stereotypes of sorts that can predict program behavior/error handling/interfaces surprisingly well, that likely line up with specific libraries/frameworks. It's totally possible to, for example, make a web page where there are zero directly visible artifacts of what frameworks or libraries were used to make it. Yet despite that, when people just naturally use those frameworks, there are little "tells" that you can pick up on a lot of the time. You ever get the feeling that you can "tell" some application uses Angular, or React? I know I have, and what stuns me is that I am usually right (not always; stereotypes are still only stereotypes, after all.) So I think that's one major component of why people care about the programming language that something is implemented in, but there's also a few others: - Resources required to compile it. Rust is famously very heavy in this regard; compile times are relatively slow. Some of this will be overcome with optimization, but it still stands to reason that the act of compiling Rust code itself is very computationally expensive compared to something as simple as C. - Operational familiarity. This doesn't come into play too often, but it does come into play. You have to set a certain environment variable to get Rust to output full backtraces, for example. I don't think it is part of Rust itself, but the RUST_LOG environment variable is used by multiple libraries in the ecosystem. - Ease of patching. Patching software written in Go or Python, I'd argue, is relatively easy. Rust, definitely can be a bit harder. Changes that might be possible to shoehorn in in other languages might be harder to do in Rust without more significant refactoring. - Size of the resulting programs. Rust and Go both statically link almost all dependencies, and don't offer a stable ABI for dynamic linking, so each individual Rust binary will contain copies of all of their dependencies, even if those dependencies are common across a lot of Rust binaries on your system. Ignoring all else, this alone makes Rust binaries a lot larger than they could be. But outside of that, I think Rust winds up generating a lot of code, too; trying to trim down a Rust wasm binary tells you that the size cost of code that might panic is surprisingly high. So I think it's not 100% true to say that people don't care about this at all, or that only people who are bored and like to argue on forums ever care. (Although admittedly, I just spent a fairly long time typing this to argue about it on a forum, so maybe it really is true.)
- cf100clunk 9mo ago
  > The X11 diehards will go the way of the SysV-init diehards; some weird minority I upvoted your general response but this line was uncalled for. No need to muddy the waters about X11 -> Wayland with the relentlessly debated, interminable, infernal init system comparison.
  - patjensen 9mo ago
    Just wait for systemd-wayland.
    - michaelmrose 9mo ago
      Gnome?
    - LeFantome 9mo ago
      Systemd does not have to force Wayland as it is already going the other way. Both GNOME and KDE are requiring systemd now.
      - cf100clunk 9mo ago
        This discussion is originally about xfce, which does not require systemd now.
      - dlcarrier 9mo ago
        KDE support doesn't even require Linux, let alone Systemd: https://community.kde.org/FreeBSD/Setup https://community.kde.org/FreeBSD/Setup GNOME, on the other hand, practically wants everything running on the exact same software stack, so it requiring a package means nothing.
- theamk 9mo ago
  > Literally no user cares what language a project is implemented in This is only true most of the time - some languages have properties which "leak" to user. Like if it's Java process, then sooner or later user will have to mess with launchers and -Xmx option. Or if it's a process which has lots of code and must not crash, language matters. C or C++ would segfault on any sneeze. Python or Ruby or even Java would stay alive (unless they run out of memory, or hang due to a logic bug)
  - gf000 9mo ago
    > even Java That "even Java" that runs half of the internet and most fortune 500 companies business critical infrastructure..
    - pjmlp 9mo ago
      And 70% of mobile market share, that people forget about, even if isn't the proper coffee flavour.
- account42 9mo ago
  > The X11 diehards will go the way of the SysV-init diehards; some weird minority that likes to scream about the good old days on web forums but really no one cares about. Being proud of how you are uncaring towards others is a sad state of affairs.
ok123456 9mo ago
Why does Wayland "feel like the future?" It feels like a regression to me and a lot of other people who have run into serious usability problems. At best, it seems like a huge diversion of time and resources, given that we already had a working GUI. (Maybe that was the intention.) The arguments for it have boiled down to "yuck code older than me" from supposed professionals employed by commercial Linux vendors to support the system, and it doesn't have Android-like separation — a feature no one really wants. The mantra of "it's a protocol" isn't very comforting when it lacks so many features that necessitate workarounds, leading to fragmentation and general incompatibility. There are plenty of complicated, bad protocols. The ones that survive are inherently "simple" (e.g., SMTP) or "trivial" (e.g., TFTP). Maybe there will be a successor to Wayland that will be the SMTP to its X400, but to me, Wayland seems like a past compromise (almost 16 years of development) rather than a future.
- justin66 9mo ago
  It's a downgrade that we have no choice but to accept in order to continue using our machines. Anyone familiar with Microsoft or Apple already knows that's the future.
  - simoncion 9mo ago
    > It's a downgrade that we have no choice but to accept in order to continue using our machines. Odd. Xorg still works fine [0], and we'll see how XLibre pans out. [0] I'm using it right now, and it's still getting updates.
    - ok123456 9mo ago
      They're trying to "nudge" everyone. Major desktop environments and entire distributions are removing X11 support to varying degrees. A lot of this is because they can't get their adoption rates above about half due to various broken workflows or simply user preference. They intentionally don't want you to keep using X11, and they'll keep turning up the heat on the pot until we're all boiling. Gnome just removed the middle-click paste option. Is that because they fixed the clipboard situation on Linux, and there's a universal, unambiguous way of cut and paste that works across every application? No. It's because middle-click to paste is an "X-ism." This is just demagoguery and unserious.
poulpy123 9mo ago
Afaik there exists only X11 and Wayland, and X11 is dying if not dead. And for rust I don't see why a desktop user would be concerned by the language used as long as it is good enough.
thisislife2 9mo ago
Yeah, I am staunch proponent of "don't try to fix what is not broken". Current XFCE is fast, light-weight, usable and works fine without major issues. While I don't fully understand the advantages / disadvantages of XFCE using Wayland instead of X, if, as someone else pointed out here on HN, running XFCE on Wayland is going to make it slower, it means these developers will be crippling one of XFCE's strongest feature. In that case other minor advantages seems pointless to users like me.
- happymellon 9mo ago
  > running XFCE on Wayland is going to make it slower Citation. None of the other desktops have slowed with Wayland, and gaming is as fast as, if not marginally faster on KDE/Gnome with Wayland vs LXDE on X. https://www.phoronix.com/review/ubuntu-2504-x11-gaming https://www.phoronix.com/review/ubuntu-2504-x11-gaming
  - thisislife2 9mo ago
    I based it on this thread - https://news.ycombinator.com/item?id=46780901 https://news.ycombinator.com/item?id=46780901
    - jchw 9mo ago
      Latency and throughput are very different things. However, it's worth noting that the comparison here is with and without compositing. If you were using compositing already on X11 (I believe XFCE offers it with "Desktop Effects" or something to that tune) then you've already been eating compositing latency, and you should actually get less latency in some situations. But as far as it performing worse overall, I don't think that would be expected. Compositing itself does lean more on hardware acceleration to provide a good experience, though, so if you compare it on a machine that has no hardware accelerated graphics with compositing disabled, then it really would be worse, yeah.
      - mrktf 9mo ago
        Little misconception here (beware i'm using xlibre and causal user). On X11 you can find two mechanisms which can be called compositor : 1st: "enable display compositing" option - this one increases latency as every window draw need go though compositor application (in nutshell it exchanging opengl textures - only synchronization messages goes over "wire") 2nd: the Xserver rendering pipeline compositor, this one goes with modesetting (intel, amdgpu) driver TearFree option - almost everything inside X11 server in OpenGL textures and compositor perform direct blending to screen (including direct scanout). What I want to tell, on modern X (there are merge requests for Xorg server to modesetting driver, amdgpu have this code) with TearFree enabled you by default optimal hardware acceleration - there comes lower latency
bufio 9mo ago
Then the future is full of high latency.
davidgerard 9mo ago
Long-time XFCE user here. We care that stuff works the same, we appreciate how much work it is to achieve that when the world is changing out from under you, and we appreciate that XFCE understands this and cares about it. Being in Rust is not a concern.
jeroenhd 9mo ago
My watch from 8 years ago runs Wayland. Nothing written in Rust as far as I can tell, though. With that knowledge, I'm certain that XFCE will remain lightweight. It can be done, so I feel confident that the XFCE folks will get it done.
dlcarrier 9mo ago
I don't think this will be a quick transition. Wayland has lots of potential, but it's far from ready to replace X11, especially in multitasking environments. XFCE is taking their time, because their community is more very concerned stability. I predict that XFCE will default to X11 until Wayland has reached broad feature parity, then default to Wayland but keep X11 support until the last vestages of incompatibility are delt with. There's no reason that this wouldn't be accepted by their community, and it should be lighter weight, in the end.
internet_points 9mo ago
Long-time xfce fan here, I trust the team to make the right decisions of what to do with their copious spare time and insane amounts of funding </s> (Instead of seeing this as "xfce jumps on bandwagon", I'm seeing it more as "bandwagon finally stable enough for xfce".)
einr 9mo ago
I am an XFCE user since many years, and am pretty decidedly in the "traditional and conservative about technologies" camp, and I think this is neat and just fine and dandy -- as long as they're not in a hurry to depreciate X11. Whenever I eventually have to go Wayland I would like to continue to use XFCE, so thumbs up for doing the work.

by jchw 9mo ago

coldpie 9mo ago

> Still I perceive a lot of XFCE's userbase to be more "traditional" and conservative about technologies, and likely to be skeptical of both Wayland and Rust, seeing them as complex, bloated, and unnecessary. Very long time (since 2007) XFCE user here. I don't think this is accurate. We want things to "just work" and not change for no good reason. Literally no user cares what language a project is implemented in, unless they are bored and enjoy arguing about random junk on some web forum. Wayland has the momentum behind it, and while there will be some justified grumbling because change is always annoying, the transition will happen and will be fairly painless as native support for it continues to grow. The X11 diehards will go the way of the SysV-init diehards; some weird minority that likes to scream about the good old days on web forums but really no one cares about. There are good reasons to switch to Wayland, and I trust the XFCE team to handle the transition well. Great news from the XFCE team here, I'm excited for them to pull this off.

graemep 9mo ago
I used XFCE for a long time and I very much agree. it just works, and is lightweight. I use KDE these days but XFCE would be my second choice. > The X11 diehards will go the way of the SysV-init diehard I hope you are not conflating anti-systemD people with SysV init diehards? As far as I can see very few people want to keep Sysv init, but there are lots who think SystemD init is the wrong replacement, and those primarily because its a lot more than an init system. In many ways the objects are opposite. People hate system D for being more than init, people hate Wayland for doing less than X. Edit: corrected "Wayland" to "XFCE" in first sentence!
- LeFantome 9mo ago
  It is refreshing to see somebody else notice that the complaints about systemd and Wayland are philosophically incompatible. Systemd is creating the same kind of monolith monoculture that Xorg represented. Wayland is far more modular. Regardless of your engineering preferences, rejecting change is the main reason to object to both.
  - graemep 9mo ago
    I do not have a strong opinion about Xorg vs Wayland. My only real concern is that it might make it harder for the BSDs but that seems to be being dealt with. I do like being able to use X over the nextwork but that is a problem that can be solved. I do dislike System D for two reasons. One is exactly because it s a monolith and, in effect, an extension of the OS. The other is the attitude of the developers which becomes very evident if you browser the issues.
    - kelnos 9mo ago
      > My only real concern is that it might make it harder for the BSDs Our OpenBSD packager has already said in our Matrix channel that he'll be testing here and there in order to keep me honest ;)
    - ethanpailes 9mo ago
      > I do like being able to use X over the nextwork but that is a problem that can be solved. And in fact has been: https://github.com/wayland-transpositor/wprs https://github.com/wayland-transpositor/wprs
  - kelnos 9mo ago
    > Wayland is far more modular. Not sure I agree here, assuming you mean "... than X11". With Wayland, you put your display code, input-handling code, compositor code, session-handling code, and window-management code all in the same process. (Though there is a Wayland protocol being worked on to allow moving the WM bits out-of-process.) With X11, display and input-handling are in the X server, and all those other functions can be in other processes, communicating over standard interfaces.
BearOso 9mo ago
If Rust has one weakness right now, it's bindings to system and hardware libraries. There's a massive barrier in Rust communicating with the outside ecosystem that's written in C. The definitive choice to use Rust and an existing Wayland abstraction library narrows their options down to either creating bindings of their own, or using smithay, the brand new Rust/Wayland library written for the Cosmic desktop compositor. I won't go into details, but Cosmic is still very much in beta. It would have been much easier and cost-effective to use wlroots, which has a solid base and has ironed out a lot of problems. On the other hand, Cosmic devs are actively working on it, and I can see it getting better gradually, so you get some indirect manpower for free. I applaud the choice to not make another core Wayland implementation. We now have Gnome, Plasma, wlroots, weston, and smithay as completely separate entities. Dealing with low-level graphics is an extremely difficult topic, and every implementor encounters the same problems and has to come up with independent solutions. There's so much duplicated effort. I don't think people getting into it realize how deceptively complex and how many edge-cases low-level graphics entails.
- duped 9mo ago
  There really isn't a "massive barrier" to FFI. Autogenerate the C bindings and you're done. You don't have to wrap it in a safe abstraction, and imo you shouldn't.
  - fork-bomber 9mo ago
    This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem. Keeping the whole “it’s funded by the Government/Google etc” nonsense aside: I personally wish that at least a feeble attempt would be made to actually use the FFI capabilities that Rust and its ecosystem has before folks form an opinion. Personally - and I’m not ashamed to state that I’m an early adopter of the language - it’s very good. Please consider that the Linux kernel project, Google, Microsoft etc went down the Rust path not on a whim but after careful analysis of the pros and cons. The pros won out.
    - elektronika 9mo ago
jchw 9mo ago
> Literally no user cares what language a project is implemented in I think this is true but also maybe not true at the same time. For one thing, programming languages definitely come with their own ecosystems and practices that are common. Sometimes, programming languages can be applied in ways that basically break all of the "norms" and expectations of that programming language. You can absolutely build a bloated and slow C application, for example, so just using C doesn't make something minimal or fast. You can also write extremely reliable C code; sqlite is famously C after all, so it's clearly possible, it just requires a fairly large amount of discipline and technical effort. Usually though, programs fall in line with the norms. Projects written in C are relatively minimal, have relatively fewer transitive dependencies, and are likely to contain some latent memory bugs. (You can dislike this conclusion, but if it really weren't true, there would've been a lot less avenues for rooting and jailbreaking phones and other devices.) Humans are clearly really good at stereotyping, and pick up on stereotypes easily without instruction. Rust programs have a certain "feel" to them; this is not delusion IMO, it's likely a result of many things, like the behaviors of clap and anywho/Rust error handling leaking through to the interface. Same with Go. Even with languages that don't have as much of a monoculture, like say Python or C, I think you can still find that there are clusters of stereotypes of sorts that can predict program behavior/error handling/interfaces surprisingly well, that likely line up with specific libraries/frameworks. It's totally possible to, for example, make a web page where there are zero directly visible artifacts of what frameworks or libraries were used to make it. Yet despite that, when people just naturally use those frameworks, there are little "tells" that you can pick up on a lot of the time. You ever get the feeling that you can "tell" some application uses Angular, or React? I know I have, and what stuns me is that I am usually right (not always; stereotypes are still only stereotypes, after all.) So I think that's one major component of why people care about the programming language that something is implemented in, but there's also a few others: - Resources required to compile it. Rust is famously very heavy in this regard; compile times are relatively slow. Some of this will be overcome with optimization, but it still stands to reason that the act of compiling Rust code itself is very computationally expensive compared to something as simple as C. - Operational familiarity. This doesn't come into play too often, but it does come into play. You have to set a certain environment variable to get Rust to output full backtraces, for example. I don't think it is part of Rust itself, but the RUST_LOG environment variable is used by multiple libraries in the ecosystem. - Ease of patching. Patching software written in Go or Python, I'd argue, is relatively easy. Rust, definitely can be a bit harder. Changes that might be possible to shoehorn in in other languages might be harder to do in Rust without more significant refactoring. - Size of the resulting programs. Rust and Go both statically link almost all dependencies, and don't offer a stable ABI for dynamic linking, so each individual Rust binary will contain copies of all of their dependencies, even if those dependencies are common across a lot of Rust binaries on your system. Ignoring all else, this alone makes Rust binaries a lot larger than they could be. But outside of that, I think Rust winds up generating a lot of code, too; trying to trim down a Rust wasm binary tells you that the size cost of code that might panic is surprisingly high. So I think it's not 100% true to say that people don't care about this at all, or that only people who are bored and like to argue on forums ever care. (Although admittedly, I just spent a fairly long time typing this to argue about it on a forum, so maybe it really is true.)
cf100clunk 9mo ago
> The X11 diehards will go the way of the SysV-init diehards; some weird minority I upvoted your general response but this line was uncalled for. No need to muddy the waters about X11 -> Wayland with the relentlessly debated, interminable, infernal init system comparison.
- patjensen 9mo ago
  Just wait for systemd-wayland.
  - michaelmrose 9mo ago
    Gnome?
  - LeFantome 9mo ago
    Systemd does not have to force Wayland as it is already going the other way. Both GNOME and KDE are requiring systemd now.
    - cf100clunk 9mo ago
      This discussion is originally about xfce, which does not require systemd now.
    - dlcarrier 9mo ago
      KDE support doesn't even require Linux, let alone Systemd: https://community.kde.org/FreeBSD/Setup https://community.kde.org/FreeBSD/Setup GNOME, on the other hand, practically wants everything running on the exact same software stack, so it requiring a package means nothing.
theamk 9mo ago
> Literally no user cares what language a project is implemented in This is only true most of the time - some languages have properties which "leak" to user. Like if it's Java process, then sooner or later user will have to mess with launchers and -Xmx option. Or if it's a process which has lots of code and must not crash, language matters. C or C++ would segfault on any sneeze. Python or Ruby or even Java would stay alive (unless they run out of memory, or hang due to a logic bug)
- gf000 9mo ago
  > even Java That "even Java" that runs half of the internet and most fortune 500 companies business critical infrastructure..
  - pjmlp 9mo ago
    And 70% of mobile market share, that people forget about, even if isn't the proper coffee flavour.
account42 9mo ago
> The X11 diehards will go the way of the SysV-init diehards; some weird minority that likes to scream about the good old days on web forums but really no one cares about. Being proud of how you are uncaring towards others is a sad state of affairs.

ok123456 9mo ago

Why does Wayland "feel like the future?" It feels like a regression to me and a lot of other people who have run into serious usability problems. At best, it seems like a huge diversion of time and resources, given that we already had a working GUI. (Maybe that was the intention.) The arguments for it have boiled down to "yuck code older than me" from supposed professionals employed by commercial Linux vendors to support the system, and it doesn't have Android-like separation — a feature no one really wants. The mantra of "it's a protocol" isn't very comforting when it lacks so many features that necessitate workarounds, leading to fragmentation and general incompatibility. There are plenty of complicated, bad protocols. The ones that survive are inherently "simple" (e.g., SMTP) or "trivial" (e.g., TFTP). Maybe there will be a successor to Wayland that will be the SMTP to its X400, but to me, Wayland seems like a past compromise (almost 16 years of development) rather than a future.

justin66 9mo ago
It's a downgrade that we have no choice but to accept in order to continue using our machines. Anyone familiar with Microsoft or Apple already knows that's the future.
- simoncion 9mo ago
  > It's a downgrade that we have no choice but to accept in order to continue using our machines. Odd. Xorg still works fine [0], and we'll see how XLibre pans out. [0] I'm using it right now, and it's still getting updates.
  - ok123456 9mo ago
    They're trying to "nudge" everyone. Major desktop environments and entire distributions are removing X11 support to varying degrees. A lot of this is because they can't get their adoption rates above about half due to various broken workflows or simply user preference. They intentionally don't want you to keep using X11, and they'll keep turning up the heat on the pot until we're all boiling. Gnome just removed the middle-click paste option. Is that because they fixed the clipboard situation on Linux, and there's a universal, unambiguous way of cut and paste that works across every application? No. It's because middle-click to paste is an "X-ism." This is just demagoguery and unserious.

poulpy123 9mo ago

Afaik there exists only X11 and Wayland, and X11 is dying if not dead. And for rust I don't see why a desktop user would be concerned by the language used as long as it is good enough.

thisislife2 9mo ago

Yeah, I am staunch proponent of "don't try to fix what is not broken". Current XFCE is fast, light-weight, usable and works fine without major issues. While I don't fully understand the advantages / disadvantages of XFCE using Wayland instead of X, if, as someone else pointed out here on HN, running XFCE on Wayland is going to make it slower, it means these developers will be crippling one of XFCE's strongest feature. In that case other minor advantages seems pointless to users like me.

happymellon 9mo ago
> running XFCE on Wayland is going to make it slower Citation. None of the other desktops have slowed with Wayland, and gaming is as fast as, if not marginally faster on KDE/Gnome with Wayland vs LXDE on X. https://www.phoronix.com/review/ubuntu-2504-x11-gaming https://www.phoronix.com/review/ubuntu-2504-x11-gaming
- thisislife2 9mo ago
  I based it on this thread - https://news.ycombinator.com/item?id=46780901 https://news.ycombinator.com/item?id=46780901
  - jchw 9mo ago
    Latency and throughput are very different things. However, it's worth noting that the comparison here is with and without compositing. If you were using compositing already on X11 (I believe XFCE offers it with "Desktop Effects" or something to that tune) then you've already been eating compositing latency, and you should actually get less latency in some situations. But as far as it performing worse overall, I don't think that would be expected. Compositing itself does lean more on hardware acceleration to provide a good experience, though, so if you compare it on a machine that has no hardware accelerated graphics with compositing disabled, then it really would be worse, yeah.
    - mrktf 9mo ago
      Little misconception here (beware i'm using xlibre and causal user). On X11 you can find two mechanisms which can be called compositor : 1st: "enable display compositing" option - this one increases latency as every window draw need go though compositor application (in nutshell it exchanging opengl textures - only synchronization messages goes over "wire") 2nd: the Xserver rendering pipeline compositor, this one goes with modesetting (intel, amdgpu) driver TearFree option - almost everything inside X11 server in OpenGL textures and compositor perform direct blending to screen (including direct scanout). What I want to tell, on modern X (there are merge requests for Xorg server to modesetting driver, amdgpu have this code) with TearFree enabled you by default optimal hardware acceleration - there comes lower latency

bufio 9mo ago

Then the future is full of high latency.

davidgerard 9mo ago

Long-time XFCE user here. We care that stuff works the same, we appreciate how much work it is to achieve that when the world is changing out from under you, and we appreciate that XFCE understands this and cares about it. Being in Rust is not a concern.

jeroenhd 9mo ago

My watch from 8 years ago runs Wayland. Nothing written in Rust as far as I can tell, though. With that knowledge, I'm certain that XFCE will remain lightweight. It can be done, so I feel confident that the XFCE folks will get it done.

dlcarrier 9mo ago

I don't think this will be a quick transition. Wayland has lots of potential, but it's far from ready to replace X11, especially in multitasking environments. XFCE is taking their time, because their community is more very concerned stability. I predict that XFCE will default to X11 until Wayland has reached broad feature parity, then default to Wayland but keep X11 support until the last vestages of incompatibility are delt with. There's no reason that this wouldn't be accepted by their community, and it should be lighter weight, in the end.

internet_points 9mo ago

Long-time xfce fan here, I trust the team to make the right decisions of what to do with their copious spare time and insane amounts of funding </s> (Instead of seeing this as "xfce jumps on bandwagon", I'm seeing it more as "bandwagon finally stable enough for xfce".)

einr 9mo ago

I am an XFCE user since many years, and am pretty decidedly in the "traditional and conservative about technologies" camp, and I think this is neat and just fine and dandy -- as long as they're not in a hurry to depreciate X11. Whenever I eventually have to go Wayland I would like to continue to use XFCE, so thumbs up for doing the work.