That’s a very good point. I hadn’t considered potential lack of domain knowledge at all. In that case Rust might even help, because it’s easier to write interfaces that can’t be used wrong - so that even someone without the needed domain knowledge might be able to fix compile issues without breakage.
Behind all the negative tone there is a valid concern though.
If you don’t know Rust, and you want to change internal interfaces on the C side, then you have a problem. If you only change the C code, the Rust code will no longer build.
This now brings an interesting challenge to maintainers: How should they handle such merge requests? Should they accept breakage of the Rust code? If yes, who is then responsible for fixing it?
I personally would just decline such merge requests, but I can see how this might be perceived as a barrier - quite a big barrier if you add the learning cliff of Rust.
Points that I would gladly agree upon - but it seems the Wikipedia authors don’t.
I am not knowledgeable enough to draw a definite line what counts as functional and what doesn’t - so I chose to go with whatever Wikipedia says… Even though I dislike it.
I know, from a mathematics standpoint it does not make sense, but from how the term is used nowadays in programming it does: Those languages allow to compose functions, pass functions as parameters, return functions, etc.
Truth has been spoken.
Except that Kotlin is functional (just like Rust, C++, Visual Basic, JavaScript,…). It is, however, not Pure Functional (like Haskell or Lean4 would be - if you haven’t checked out Lean4, I can recommend it, great fun).
(Sauce: https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Functional_languages)
While gaming performance with the nVidia drivers is often better (I’m talking about FPS alone, not taking into account the card price), the interaction with the desktop environments is way better for AMD, because their drivers are fully maintained as part of open source projects. What I mean are the tools to configure display resolution, and if you are using multiple monitors, their relative positioning. Everything just works. This alone is reason enough for me to strongly recommend AMD over nVidia.
The main issue with btrfs is the RAID 5/6 write hole. If you aren’t planning to use RAID 5/6, it’s fine.
There are some other problems too, but those don’t affect data integrity. The most annoying one currently is that defragmenting breaks reflinks, such that snapshots get turned into full copies, potentially wasting a lot of space. (I have honestly no idea how noticeable fragmentation is on SSDs, and if defragmenting is even worth it nowadays.)
Afaik the --reflink isn’t needed any more with modern coreutils versions.
Sorry, I was a bit confuse. I meant, in the short term Proton is definitely a good thing.
Yes and No.
In the short term the answer is a clear “yes”, as it allows players to play nearly all Windows games on Linux without modifications, and game developers to ship their games on Linux without any extra costs.
In the long term it might have a bad effect on the market, as it further helps to cement Microsoft’s control over multimedia APIs, since game developers now have little incentive now to target anything other than DirectX…
In this case it’s a bit weird though, as the game lists Linux as supported platform, but obviously just ships the Windows build with Proton instead of having a native Linux build that uses open cross-platform APIs.
95% being trial and error. At least where I work.
deleted by creator
Mesa has its own OpenCL implementations for AMD GPUs too: Clover and RustiCL. However, Clover is not really developed any more (afaik) and lacks some important extensions, such that many programs can’t use it. RustiCL is rather new, and I don’t know how well it works.
I am still in the process of customizing my desktop on my new MNT Reform laptop. This includes some work on my status bar tool. I just fixed decibel scaling for the ALSA volume plugin yesterday: https://github.com/soulsource/swaystatus/tree/feature/alsa
I am planning to merge the ALSA plugin to the main branch this week.
Next thing to add is a battery display. Probably using the udev crate, though I am tempted to just use sysfs instead.
anti-trust authorities
The same anti-trust authorities who have been ignoring <gestures vaguely towards IT industry> completely?
Visual Studio Code with rust-analyzer has all the features I would expect from an IDE. I mean, rust-analyzer works together with cargo, so refactoring over file boundaries is not an issue. Visual Studio Code has built-in support for debugging and source control…
That said, I am currently trying to change my workflow to use vim instead of Visual Studio Code, due to my laptop’s small screen size. Rust-analyzer works great in vim too, but I still need to tweak a few things, like how warnings from cargo check are being displayed…
It’s not a dumb question at all, and there is no “agreed upon” definition.
For me the most important characteristics of a “Mainstream Distribution” would be the size of their maintainer team - though that is also inaccurate if we are talking about distributions that are built on top of other distributions - as in your example.
Another indication is to check who is sponsoring a distribution’s development. If there are plenty of commercial sponsors, then chances are that the distribution is well maintained. Similarly, if the distribution is created by a commercial company (Intel, Canonical, RedHat,…), as those companies also have an interest in keeping their product in a good state.
Age of the distribution might be another indicator. If a distribution has been around for a long time, chances are it isn’t bad either.
However, I am lazy and would not actually check any of this by hand. Instead, the thing I would actually do is to just go to https://distrowatch.com/dwres.php?resource=major and read through their list. 😉
I’m mostly using Rust for a spare time Visual Novel Engine (and Visual Novel) project.
I picked Rust, because I wanted to do something productive with my higher-free-macro crate (which is a tech-demo, but hey, if I have written it, I can just as well use it for something). If you want to get an idea how scripting the VNs in that engine will work, check out the “text adventure” example in higher-free-macro. However, Rust is definitely not an ideal choice for this project. Since performance usually isn’t a concern for visual novels, a higher-level, pure functional language like Haskell or Lean4 would probably have been a better option.
Apart from that I’m using it for many smaller things. For instance I’ve written a small tool for my status bar, swaystatus. (I was not aware that i3status-rust exists when I started working on it, and now I am already committed.) Here I chose Rust mainly because I wanted to learn about Foreign Function Interface in Rust. While I didn’t upload the sources to github until recently, I mostly had been working on this tool several years ago, when I still was a Rust newbie. However, I got back to this project some weeks ago, when I realized that I would like to have an ALSA volume display, which is now in a WIP state on a separte branch.
I’m also using Rust for some out-of-tree prototypes at work. In this case the main reason for choosing Rust is development speed. I’m using Iced.rs to build those prototype GUIs, and Iced is an amazing toolkit. Making a prototype with it is shockingly fast. If I were to do something similar with basically any other GUI toolkit, it would take me significantly longer.
And last, but not least: I’ve published a free app for SailfishOS which is compatible with passwordmaker.org: Passfish, and its underlying library, passwordmaker-rs. Here I chose Rust, because it’s way less error prone than C++ (and let’s better not talk about QML JavaScript). Also, I wanted to show that using Rust for SailfishOS app development is viable, and that it’s actually a quite pleasant experience. (If you want to try passfish, builds are available via the official SailfishOS store, or on OpenRepos).
I second the recommendation to start with The Book. It contains all the necessary information, especially in the chapter about ownership.
I would be very surprised if they wouldn’t fix all 50 filesystems.
In all projects I have worked on (which does not include the Linux kernel) submitting a merge request with changes that don’t compile is an absolute no-go. What happens there is, that the CI pipeline runs, fails, and instead of a code review the person submitting the MR gets a note that their CI run failed, and they should fix it before re-opening the MR.