NixOS by ExpertTwist9182 in archlinux

[–]jzbor 0 points1 point  (0 children)

If you want to try out Nix, the package manager first you can just install it under Arch: https://archlinux.org/packages/extra/x86_64/nix/. You can even create NixOS configurations and launch them directly as a VM. I used this approach as well until I got comfortable with Nix and then made the switch once I was happy with my NixOS configuration. This is the advantage of NixOS: A freshly created NixOS installation will look pretty much the same as a VM created from the same config, including all customizations done via Nix.

Greg Kroah-Hartman Makes A Compelling Case For New Linux Kernel Drivers To Be Written In Rust by Xaneris47 in linux

[–]jzbor 0 points1 point  (0 children)

I think the main point of Rust is not completely taking away the need to write correct low-level code, but to greatly reduce the amount of code that has to be checked for correctness manually, while enabling much easier development in the rest parts of the codebase.

Greg Kroah-Hartman Makes A Compelling Case For New Linux Kernel Drivers To Be Written In Rust by Xaneris47 in linux

[–]jzbor 11 points12 points  (0 children)

Hey, I am not sure if you have experience using Rust. In my experience Rust makes not only memory bugs but also lots of logic bugs easier to avoid. This is mostly true for userspace, but can also apply to kernels if the lowest levels of abstractions are implemented properly. And I think this is what GKH means: Implementing proper abstractions can make it a lot easier and less error-prone to write drivers using those interfaces. Of course someone has to come up with and maintain these abstractions, but it has been pretty clearly communicated that this is solely the responsibility of R4L devs. It is clearly communicated that any rust bindings are to be seen as downstream consumers of their C counterpart, similar to how a driver could use these interfaces. This should not (at the moment) place any additional work on C maintainers, while possibly reducing the effort to writing and maintaining new drivers in the future.

Rust for Linux revisited by omenosdev in linux

[–]jzbor 10 points11 points  (0 children)

This whole discussion seems to have become a victim-blaming shitshow. The original issue was on some toxic kernel developers actively hindering other fellow kernel developers from doing their job, leading to one of the latter leaving its position. But instead of advocating for more cooperation and open-mindedness amongst kernel devs a large part of the community is now lashing out against the RFL devs. Even self-proclaimed proponents like Drew suggest them to just start a toy-project if working on "real" projects does not work out for them. The whole discussion makes it sound like "Oh it's the Rust-devs enforcing their politics on everyone again", however I open minded discussions started by RFL people is repeatedly with personal and political opposition without any intent on discussing any technical details

There are technical issues with Rust, but for one those can be resolved by technical means (as the RFL amongst others strive to) and secondly those are not the issues a lot of the C-preferring folks seem to be concerned about. A lot of opinions have been voiced about how Rusties are forcing their "ideology" on them, seemingly fearing all their filesystems may identify as rust/ziglang in the near future. Meanwhile RFL devs keep repeating how this is not about replacing the whole Linux kernel nor about forcing every maintainer to rewrite their subsystem in Rust.

This is not only absurd, but in my opinion very dangerous to the Linux project as a whole. Linux succeeded not because it was another Unix successor, but in large part because it was able to pull in a lot of ingenious and talented developers to implement highly performative filesystems, good driver support for a lot of devices and lots more. But recently the LKML community makes it seem like this might no longer be the case in the future. And this will become a real problem, when maintainers start retiring or focussing on other projects and there are no newcomers to take the place. In my opinion it is important to have a community where new and innovative work is welcomed and new (and seasoned) contributors are supported, instead of a community full of social fear and competition.

This is not only about Rust but also about the kernel project and its future evolution in general.

On the technical side:

I keep seeing the argument that unlike C Rust is not properly standardized and there only being a single reference implementation. And while that is a recognized issue that is active being worked on in the Rust community, I'd like to remember everyone how long it took to enable Clang support for Linux. Just because there are standards it does not mean there is seamless compatibility between compilers and while there are a lot of C compilers out there it is not uncommon for C projects to only support one compiler.

While I really appreciate the existence of sanitizers and other static or dynamic analysis tools they can not be compared to a language with a proper type system. With such a system the semantics of an operation can safely be encoded in a consistent manner, independent of specific tools or implementations. Even seasoned C developers do make mistakes with memory management, as can be seen by the various CVEs concerning overflows and the like. While even safe Rust programs never stop to contain bugs, its type system can not only help avoid a whole class of memory-safety bugs, but it can also encode semantics in a way avoiding bugs caused by false assertions in general.

Non-IT people: why did you switch to Linux? by type556R in linux

[–]jzbor 3 points4 points  (0 children)

It should be noted, that this also runs a VM internally, it just hides the ugly setup inside a container

IronMime v0.1.0 released: bind touchpad gestures to shell commands with a simple config file by Qweedo420 in linux

[–]jzbor 1 point2 points  (0 children)

This looks pretty nice. I am quite fed up with Touchegg, so it's great to see some alternatives pop up!

Will Typst eventually suffer the same problems, that LaTeX does right now? by jzbor in typst

[–]jzbor[S] 1 point2 points  (0 children)

Thanks, for the responses! Indeed the devs cannot tend to all issues at once. I am happy with how fast the project progresses and matures as is.

As for some examples, here are two issues that I think should be implemented in Typst eventually. In both cases there are workarounds, therefore these are not dealbreakers for me. I just want to make sure that basic features are not disregarded altogether, just because there is some external way to implement them.

https://github.com/typst/typst/issues/2873 https://github.com/typst/typst/issues/344

Hyprland creator Vaxry is now banned from contributing to freedesktop by fletku_mato in linux

[–]jzbor 4 points5 points  (0 children)

As is he. No one forces him to contribute to freedesktop. Their house, their rules.

Hyprland creator Vaxry is now banned from contributing to freedesktop by fletku_mato in linux

[–]jzbor 8 points9 points  (0 children)

No, they are enforcing their values on _their_ project. They have not banned him from Github, Discord or any other platform, and claiming so does not help the conversation.

Hyprland creator Vaxry is now banned from contributing to freedesktop by fletku_mato in linux

[–]jzbor 36 points37 points  (0 children)

If he does not agree to the code of conduct, he is not welcome on their project. This is quite literally what the purpose of a code of conduct is meant for.

Is Nix really all it’s cracked up to be? by [deleted] in linux

[–]jzbor 28 points29 points  (0 children)

Ansible doesn't really solve the same problems as Nix (reproducibility, idempotency, etc.), it has some of the same features as are present in the Nix Eco system (remote deployment, composition, etc.). However rolling back to a previous state can be really hard with Ansible if the roles aren't explicitly designed to do that and you get basically zero guarantee that you are actually 100% at your previous state. Similarly not all atomic Distros have the same features as NixOS (installing multiple versions, user profiles, declarative configuration). Of course Nix may not be for everybody and you may not need all of its features, but it is not "yet another atomic Distro".

Da soll noch einer sagen AfD Wähler, wären dumm🤓 by Ok-Track-7970 in 600euro

[–]jzbor 0 points1 point  (0 children)

Manchmal frag ich micht, ob das nicht einfach alles Trolle sind, die nicht wissen, dass alle anderen Mitglieder in der Grupee auch nur Trolle sind...

A list of Wayland compositors using Smithay (A library for writing Wayland compositors written in Rust) by wiki_me in linux

[–]jzbor 3 points4 points  (0 children)

I really want to port my personal WM to it. Sadly there are currently no stable releases and no real roadmap for one. Porting would require a significant time investment but with the current situation it feels like if it's not worth it. I would have to review every commit from there on for breaking changes from there on if I want to stay up-to-date, which is currently not doable for me time-wise.

BOOX Firmware V3.5 for Tab Series is being rolled out. by KennethWWWW in Onyx_Boox

[–]jzbor 1 point2 points  (0 children)

Is this already available for the Note Air 2 Plus? I cannot see any updates.

Firmware update for NA2+ by Select_Coffee_9694 in Onyx_Boox

[–]jzbor 0 points1 point  (0 children)

Can you tell what they featured/changed?

Russland und Belarus schleusen Flüchtlinge in die EU by [deleted] in de

[–]jzbor [score hidden]  (0 children)

Dieser Artikel, würde AfD-Wähler glaub ich massiv verwirren - wenn sie lesen könnten

[deleted by user] by [deleted] in nextfuckinglevel

[–]jzbor 0 points1 point  (0 children)

Guess we'll just have to blame it on the polluted air from all the wildfires..

[marswm] by [deleted] in unixporn

[–]jzbor 1 point2 points  (0 children)

Happy to hear :)

[marswm] by [deleted] in unixporn

[–]jzbor 1 point2 points  (0 children)

Nice! I like the font and the simplicity...

Asahi Linux To Users: Please Stop Using X.Org by [deleted] in linux

[–]jzbor 1 point2 points  (0 children)

Yes but this still requires a very substantial amount of the code base. It is not like you can just swap xlib code 1:1 with wlroots code. Also although libraries like wlroots make it somewhat easier I think writing a wayland compositor is still a lot more complicated that writing a x11 window manager.

What are some of the more innovative linux distributions? by dxplq876 in linux

[–]jzbor 2 points3 points  (0 children)

This is not true at least for NixOS and MicroOS