Path of Exile 2 started working in wayland native (proton_enable_wayland) and it performs much better than through kwin or whatever is used by default.
Most complaint against Rust is fucking culture war, not technical, so people who actually have technical concerns with Rust are being lumped together with Brian Lunduke and others.
As in Rust = gay kind of culture war? I’m so OOTL. Please help
Rust was among the first more well known projects, which adopted a Code of Conduct, then grifters in the OSS community cried censorship, which made people flock to it to “own the right”. Even if I think it’s an overrated marriage of flesh between C and OCaml, Code of Conducts are generally a good thing, and the people who really like toxic callouts arre more of an anomaly, and likely were flown there due to the culture war stuff.
People hate rust because of its fences/training wheels, not because it’s “woke”
…actually I just saw someone in this very comment section ranting about “soydevs”, you’re not wrong. But there are valid complaints too! Some of us are just old and think our computers should do whatever we tell them up to and including “shit yourself and catch fire”
That’s why I prefer D’s approach for memory safety. Sure, it’s not as well featured as Rust’s, however it has “fat pointers”, three levels of safety, and kind of optional garbage collector.
No quams with wayland or rust, but snap packages, those things annoy me greatly.
The most annoying thing about snaps is it’s so unnecessary. Why go to the effort of supporting that when snap exists?
Yeah, at least use Flatpac.
I’m cool with AppImage as well, they just work.
I used a daemon to manage my AppImages, worked great until fairly recently where it began mounting way too many FUSEs and just make AppImages stop working altogether. I miss it, because now I have to manually manage the AppImages, and that makes me sad. :(
I’m lazy.
I find snaps quite useful for CLI apps, I’m curious what annoys you about them.
And yes I understand that the backend not being open source is an issue, but it’s not that important imo. Flathub, for example, could change the code on their backend without notice and screw us over.
You can use flatpaks without ever touching Flathub.
You guys just discuss this using systemd like nothing is wrong!
Alright grandma let’s get you to bed
Dualboot devuan and void. Do it.
Or Alpine and Gentoo! Do it now!
Or Artix, everyone forgets bleeding edge no-systemd
This one!
You must enter Caesar’s tent alone. Anyone else must remain outside
@bernhoftbret You forgot systemd
nspawn ftw. I tried avoiding systemd until I found out how much scripting it saved me. the more I use it, the more I like it.
I think everyone has moved on at this point. Systemd became the standard more than a decade ago
Yeah, well I’m still afraid of it
are you
[ OK ] piss_baby.service?
I recently moved from X11 (BSPWM) to Wayland (Hyprland) and while I did get rid of a very annoying bug with bspwm, it did come with a few of its own quirks/annoyances:
- Hyprland does not yet have the ability to load ICC profiles
- Marking a monitor as variable refresh rate capable forces my GPU to idle at maximum clocks and draw 100W (this one really makes me wtf, but it is nvidia so idk who to blame here)
- Dragging and dropping can be very unreliable for some windows (IIRC, only with Chromium based applications so far)
- Some apps deadlock when attempting to read the clipboard (Again, only Chromium based applications so far)
Maybe if I wasn’t a masochist and installed something normal, such as KDE, I wouldn’t have any of these issues. However, I apparently and unfortunately get great pleasure out of plopping my testicles onto an anvil and smashing them like a blacksmith forges raw iron.
Rust, however, is cool. I like Rust. I can’t say that I approve of replacing everything under the sun with a Rust rewrite for no good reason, but the language itself is fine.
I live programs written in rust. They are quick & lightweight & fun.
Know what i hate ? Installing rust programs with cargo. It’s slow & grinds my Chromebook to a halt.
If you tell me to install an end-user facing application with a programming language’s package manager, I’m out. Like, Adafruit was at one point recommending a Python IDE for their own implementation of micropython called Mu, and the instructions were to install it with Pip. Nope. Not doing that.
Me: I wanna try this node program, how do I install it?
Node: Well first you need to download these 100 node packages using your system package manager before you can use my package manager.
Me: And then I can install node packages at the user-level?
Node: Oh you poor sweet summer child. At the directory-level, of course!
Me: Oh okay. Is… is all this highly necc-
Node: It’s better this way.
Annoyed Maintainer: fine, here’s a Docker file. Stop filing bugs about how you can’t install node.
Average C from source experience: (copied from Kicad)
apt get long list of dependency git clone cd cmake make sudo make install rm -r .Average Rust from source experience:
cargo installMost of the time you should probably not install from source of possible.
I try not to build from source often. My computer is a potato.
Then why do you need cargo in the first place, sir? You install a program written i Rust just as if it isn’t. When you
apt install xzy, you don’t even know what language is used to program it.And if the developer only publishes the source?
That’s your distro’s problem, not the developer’s
I mean, that’s not a Rust issue per se. It’s only noticeable because
cargois much better than most build systems, and hence is an actual option for distribution of software. But there should ideally always be a binary distribution. I know some people like to build everything by themselves, but I get it, it’s annoying.For people who do this, is the purpose to ensure you are not getting a bad binary which has some malicious code compiled in?
If yes, isn’t it more difficult to check all the source code yourself? You may as well trust a binary where the author has confirmed a hash of the binary. Unless you really are checking every single line of source code. But then I wonder how you get anything else done.
The incident from
xzgives a good example of where self-compiling stuff would be a good idea.
The code was mostly fine, but the maintainer managed to include malicious instructions in the binary. Most people who read the source, didn’t realise the possibility. I checked it out afterwards and it was still hard to get.The idea is that someone is checking the code. And by building it yourself, you can at least ensure that you’re getting what’s built from the code. It is possible that some malicious stuff was inserted while building the binary that doesn’t show up in the source code. Building from source solves that problem.
Reproducible builds try to solve that problem by generating some provenance from a third party. A middle ground can be building the binary using something like GitHub Actions, since that can be audited by others. That comes with its own can of worms since GH is owned by M$, but I digress.
So it is technically sane to do it, just not very practical in my view. But for lesser known apps, I do sometimes build from source.
cargo install xyzandapt install xyzaren’t mutually exclusive.Yeah, the good tooling also means it isn’t even terribly difficult for the dev to provide builds, but it isn’t quite as automated as publishing to crates.io, so many don’t bother with automating or manually uploading…
Pypi isn’t in any way less an option for distributing software countless projects that use it that way can be used as a proof. Hell, awscli installed from pypi for ages. In my experience cargo is extremely slow at downloading hundred libraries that every program needs and rustc is extremely slowly builds them.
Correction, uv isn’t in any way less an option. pypi is only the registry. If you are using pip you will end up in dependency hell, you might use something like poetry to avoid that, but uv is just better.
But… wait a minute… uv is inspired by cargo, and it’s also written in rust. That’s quite the coincidence, huh?
Also, cargo is fast, it’s rustc that’s slow, and that’s because rustc is doing advanced code analysis. Compiling rust is actually NP-hard, but in exchange for that, the compiler will catch bugs in place of the developer. Which is a good tradeoff considering that you only compile once and run many times.
“countless projects that use it that way” isn’t proof of anything. Countless projects tell you to
curla 2000 lines script intosudo bashthat will fill your os with bullshit.Pip is a sane default that works for absolute majority of cases, anyway correct tool for installing programs from pypi is pipx that eliminates ‘dependency hell’, but ofc new cool tool is the only way to do things.
When little program in rust that replaced previous one compiles two hours compared to previous that compiled in a few minutes it matters.
UV is a lot more than pipx. It installs applications from pypi, without dependency hell, but it also uses hard links when possible to avoid wasting space. But it’s also a dev tool. It manages python installations, workspaces, you can use it to edit the pyproject, it can also publish to pypi, even from a GitHub action if set up from pypi. It just does a lot more.
None of the issues you’ve described are Cargo’s fault. The long compilation time is simply rustc’s compile-time checks (ensuring type and memory safety is much more involved than lexing in GCC), and the number of dependencies to compile is a result of the crate ecosystem. Cargo is just the front-end that automates fetching dependencies and compilation with rustc. Blaming it for slow compilation is like hitting your monitor when the computer is acting up.
I’m not blaming cargo specifically for building it is slow to download deps as well, which was clearly stated in my first post. I’m going to edit it now.
The Rust compiler is more sophisticated than most compilers, so it can be slower at the same kind of tasks. But it also just does a different task here.
One of the tradeoffs in Rust’s design is that libraries get compiled specifically for a concrete application. So, whereas in most programming languages, you just download pre-compiled libraries, in Rust, you actually download their source code and compile all of it on your machine.
This isn’t relevant, if you get a pre-built binary. And it’s not particularly relevant during development either, because you get incremental compilation. But yeah, if someone wants to compile a Rust codebase from scratch, then they have to sit through a long build.
Try
cargo-binstallI’ll look it up. I’m guessing it install app images?
I’d guess just binary builds, no need to reinstall the entire environment again every time you install something.
What no systemd?
Why are we afraid of systemd again? /gen
I came in late w/ arch-based systems so legitimately don’t know the lore.
Systemd is controlled by redhat and is a very large part of the Linux stack. It’s become so universal that a lot random stuff won’t work unless the system has systemd.
Compared to X11 to wayland or pulseaudio to pipewire it’s a lot hard to now replace an init system and with that in the hands of redhat which is for profit is not a nice thought.
But you know, fuck it, having systemd is a massive headache for people making distros that’s just gone. Everyone is using the same thing and things just work so people aren’t really complaining. If redhat tries some shenanigans there’ll always be a fork or a systemd compatible init system or even whatever Alpine is using now that’ll take it’s place.
Off the top of my head, in no particular order:
- Systemd and its components are responsible for too many essential system functions. Init, services, mounts, timers, logging, network config, hostname, DNS resolution, locale, devices, home directories, boot, NTP sync, and I’m sure there are others, can be handled by systemd or one of its components.
- Systemd violates the UNIX philosophy of “do one thing and do it well”. Systemd is a complex solution to a complex problem: this thread has several comments by a former Arch Linux maintainer that explains why they’ve switched to systemd, and why the earlier method of using single initscripts was unsustainable.
- It is owned and maintained by Red Hat, known for its many controversies.
- Some people just don’t like modern things and think that the Linux ecosystem peaked in the 1980s.
Most (though not all) of the popular complaints are completely unreasonable. Those people usually see themselves as moral and righteous and expect the world at large to follow their personal creed. I especially consider the UNIX philosophy to be outdated, and strict adherence to it to be an obstacle for modern apps and systems.
I have some issues with systemd, and I don’t like that one for-profit company has such a massive influence over the entire Linux ecosystem, but I have to acknowledge that it works, it works well enough to counter my personal issues, and that the people whose opinion matters the most (specifically Debian and Arch maintainers) chose it for a good reason.
My personal reasons for disliking systemd (note: I still use systemd):
- The lead developer of systemd has said multiple times that we should be fine with break POSIX if it means developing faster.
- systemd has massive attack surface, making it easier to exploit and result in privilege escalation. It is a highly complex and large codebase that really shouldnt be given the trust of PID 0
- systemd is not portable or modular.
- It only just barely got musl support. Hope to see it improve in the future.
- systemd is much slower than other inits (eg. dinit, s6, openrc)
- systemd being the go-to init encourages developers to more heavily depend on it, making it difficult for distros without systemd
The biggest feature I like about systemd is run0, though I wish it was a drop in replacement for sudo. Secondly, I do like that services can be sandboxed.
The lead developer of systemd has said multiple times that we should be fine with break POSIX if it means developing faster.
I mean, so does GNU.
- It’s developed for linux and there is literally 0 linux distributions that are POSIX-compliant, also standard is dead.
- It doesn’t, also moving it to any other PID won’t make any difference.
- It is modular (IIRC there is only three mandatory parts) and portable.
- Was completely on musl side (also musl is as much not portable and modular as systemd 🙃 and in every practical way worse than glibc).
- It’s not an init, nor does it present itself like this. Do you have any benchmarks that show this slowness when doing comparable operations?
- Why exactly depending on a stable system component is a bad thing? Distros without systemd are moving against the stream, obviously there going to be some problems.
systemd DOES do one thing really well. Too well. It’s a service manager.
People noticed that it works really well as a framework for their stuff and started plugging all the other stuff in your first bullet point into it. And that also worked really well.Now I want a shirt that says “Linux ecosystem peaked in 1980s”
Those people usually see themselves as moral and righteous and expect the world at large to follow their personal creed.
If they don’t like systemd but are forced to use it for some reason, I can understand why they might have some negative feelings
Once I switched to a distro with OpenRC, I stopped feeling the need to argue about systemd
You are forced to use a lot of things bit systemd is where you draw a line? 😺
I see from your other comment in the thread that you’re enthusiastic about systemd, and that’s great.
I’m glad we inhabit a software ecosystem broad enough that we can both be happyI’m not enthusiastic about it, I’m just old enough to remeber how bad were good old times before systemd and a bit miffed how old and untrue statements about it are perpetuated.
Some people just don’t like modern things and think that the Linux ecosystem peaked in the 1980s.
Linux was released in 1991.
That makes the shirt funnier
It’s called a hyperbole.
(edit) But, honestly, it’s still kind of accurate. Many of the most significant software suites that define the Linux ecosystem in more recent decades were written in the 80s or earlier. X (the display protocol) was released in 1984, and X11 in 1987. GNU Emacs was released in 1985. Vi, in 1976. UNIX System V, from which
sysvinitand compatible init systems were adopted, was released in 1983. It’s not a stretch to say that certain people want to regress to the 1980s state, even if the kernel wasn’t around.Funny thing is, nothing in the list adheres to the so called unix philosophy.
It’s a little known fact that the first answer to Linus’ first message announcing his new OS was “You stupid thing, why did you created it? It ruined it! Linux was better before!”.
This sign won’t stop me! I can’t read!
“You can’t have programs that do multiple things! Any program that is multi-use is ebil. Standardized syntax and functionality between different related systems? NO! PROGRAM DO ONE THING!”
A lot of this is also a post-hoc justification, UNIX didn’t get shared libraries until some point in the 80s (Can’t find an exact year), so before that your options were to either statically compile the needed functionality into your program or keep it as an entirely separate program and call out to that.
It’s a perfect mix, in a time where enterprise storage was measured in single digit megabytes, and the only efficient way to created shared functionality was via separate programs, and you’ve got an OS that happens to have “easily pass data between programs” as a core paradigm.
And now people invoke it to attack an init program for also monitoring the programs it starts and not just spawning them.
even when said “one program” is actually 69 (nice) different binaries
Wait until these people find out that Linux is monolithic
Wayland is superior. Yeah I said it.
That is just like your opinion man - the dude
People say lots of things.
It’s the best. Everyone says so.
Unless you want to pass alt tab to another computer on Rustdesk etc.
I do that all the time on Wayland. I have three virtual displays, each with a TigerVNC client session connected to three other computers whose monitors I can see so I can pass my cursor seamlessly across six displays (across four different computers). Once I click in any of them, all key combos go into that instance, which is exactly what I want.
Why tho?
Well one of them is for work communication, two are for dashboards that occasionally need to be poked, one is for swap space, and two are vertical monitors where the actual work happens.
I feel like the urinal meme would fit better
I have never seen this one before but I have to disagree.
While I think Wayland has some limitations compared to X11, I would not mind them for 99% of stuff I would want to do with it. If it worked for me. I tried to use it, wanted to like it, but it just did not like me. Maybe I have the wrong GPU, but it just never worked. For my next build, I will get an AMD GPU and see if it works then.
Yeah. Although Wayland is NOT modular, as on the compositor taking care of things that probably shouldn’t be controlled by it, and Rust’s compiler doesn’t support every architecture under the sun, unlike C.
“the compositor takes care of things it shouldn’t” said the x11 user while using their display server that also manages printers, and also provides peripheral drivers, and also manages opengl drivers, and also provides a full graphic toolkit, and also provides remote access. And all that while treating multiple monitors like a single big monitor with a single shared refresh rate, and with no support for HDR of trackpad gestures. Yes, it really is upsetting when the screen compositor manages screen recording and double buffering. And remember x11 is so modular that the graphic server is part of the driver stack and so must be implemented for every GPU out there.
P.s.: anyone that thinks the Unix philosophy has any value should not touch xorg with a 10 meter pole. It does many things, badly. But sure, it does allow any unprivileged program to read and write to the framebuffer, so be my guest if that’s your thing.
Rust is an ecosystem that works almost, but not quite, entirely unlike C.
If I remember correctly, then C doesn’t support all architectures that rust supports (and vice versa).
Why would it need to be modular? What kind of modules should even be there? It can be implemented in multiple ways anyway. Rust programs are extremely slow when I build them, it really take ages on my machines, but it works just fine.
I am yet to have a successful testrun of wayland, closest I’ve had was everything seemed to work fine but some games would straight up not work. I’m sure it would be just fine if I installed a distro that had it by default but at that point it’s way beyond the convenience I’ve heard so much about.
My biggest problem was that Electron applications just refused to function, so for a while I’d try it, get annoyed and swap back to X11, and then give it a few months and try again. Back in August or so I swapped to Wayland pemanently, decided to just toss the Electron applications that wouldn’t work.
Since then the only problem I’ve had has been with DXVK and games, but only on a particular NVidia driver, so I think we can all guess who the real culprit is.
Each desktop environment needs to implement wayland so it’s best to leave it to the distro you’re using to provide it as an option. For a good wayland experience I’d recommend KDE
I think you identified the issue, in a way. I don’t blame you for wanting to manually install and configure it for understanding purposes, but I can say that hopping straight in to Fedora it seems (mostly) fine. I have had a few weird lockups, but it is far between. Also, as others have griped, drag and drop sucks right now.
If I built this, there would be a third, much larger one labeled “Snaps”.
