There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

d3Xt3r ,

GSIs are the way to go these days for anything that’s not a Pixel. I’m not sure if there’s a fully-degoogled GSI out there though, but you can check the list here: github.com/…/Generic-System-Image-(GSI)-list

Or here: xdaforums.com/…/treble-enabled-device-development…

And once you found a GSI you like, install using the instructions here: github.com/phhusson/…/Samsung

But it’s best to check XDA forums as well for any device-specific quirks.

d3Xt3r ,

It’s interesting, but it always seemed a bit too hacky for my liking and possibly prone to breakage. Eg seeing the compatibility table here doesn’t inspire much confidence: bedrocklinux.org/0.7/feature-compatibility.html

I also don’t like that it hijacks your host distro, it would’ve be been better if it was a bit more self-contained, like how Nix works on other distros. Feels like the mashup Bedrock does would be a PITA for troubleshooting (for instance, mixing binaries from different distros via $PATH is just asking for trouble). I also dislike that it uses FUSE to share resources between strata, given how inefficient FUSE is.

I think for most purposes, if you really want to mix-and-match distro features, a far cleaner approach would be to just use Distrobox.

Easily find program name from context menu/without terminal?

I occasionally need to know the names of programs. I asked here about “Run as Administrator” being added to the context menu (like in Windows), and the response was basically “can’t be easily done”. an example is if I wish to edit a config file it cannot be done without accessing the terminal. Knowing the name...

d3Xt3r , (edited )

On Windows, I would never need to know that the “File browser window” is called “explorer”

I do though. That knowledge is pretty handy for launching apps via the Run dialog, which I find faster than using the Start Menu with its horrible search. And this has become even more important to me with recent versions of Windows getting rid of the classic Control Panel UI, as you can still access the old applets without needing to put up with the horrid Metro UI. For instance, I find the network settings applet far more convenient and easy to use, so I just launch it via ncpa.cpl. Or if I want to get to the old System applet to change the hosname/page file size etc, I can get to it by running sysdm.cpl. Or getting to Add/Remove programs via appwiz.cpl, and so on.

Also, knowing the actual commands opens up many scripting and automation possibilities, or say you just want to create a custom shortcut to a program/applet somewhere. There are several useful applets you can launch via rundll32 for instance.

d3Xt3r , (edited )

.NET is now fully cross platform. you can absolutely run and debug applications on linux as you would in windows.

Correct me if I’m wrong, but isn’t this limited to just console apps - as in you can’t yet run GUI apps, unless you’re using a cross-platform toolkit like Avalonia, or it’s a WinForms app running under Mono?

d3Xt3r , (edited )

This is not an answer or recommendation btw, just chiming in my 2c as an Arch and Fedora user who’s tried Void for a while.

From what I’ve experienced, there was no visible difference in the startup/shutdown speed (compared to Arch). This was on a Zen 4 mini PC, with a Samsung 980 Pro PCIe 4.0 NVMe. But I suspect it’ll be the same for anyone who’s on any modern system with an NVMe drive. But, if you’re on an older PC with a spinning disk or limited RAM, you might notice a difference. But both Void and Arch were visibly faster at startup/shutdown compared to Fedora, but we’re only talking about a couple of seconds here. Again, on an NVMe, startup/shutdown speeds shouldn’t really be relevant these days, unless there’s some bug or misconfiguration slowing down your init.

I definitely do like the idea of using musl over the bloated glibc, but there’s still far too many programs out there dependent on it, so you won’t be able to get rid of glibc completely on a full-fledged desktop.

The package manager (xbps) wasn’t visibly faster compared to pacman either (especially with pacman’s parallel downloads). Also, I missed the unique features found in certain AUR helpers, like pikaur, which showed the latest Arch news and package comments.

However xbps is definitely a lot faster than the current dnf on Fedora, although that gap may close with dnf5 - which you can install if you want to. I haven’t tested dnf5 yet though so can’t comment on it. The xtools features in Void were pretty nifty, but in saying that, the lack of them on other distros wasn’t that big of a dealbreaker.

Finally, for me, ultimately what I’m after is performance, and Arch with x86-64-v4 packages and the BORE scheduler performed much better overall compared to vanilla Void (or Fedora for that matter). If Void had x86-64-v4 as well, I might consider using it as one of my primary distros, but at present, I’d relegate it to niche scenarios where system resources are limited.

If you want to use Void without transitioning, just install it in a VM and give it a good try. With the state of KVM these days there’s very little performance overhead and you can definitely daily-drive Void inside a VM, and then form your own conclusions as to whether its worth switching or not.

d3Xt3r ,

I wish they did this a decade ago, back when they tried to crowdfund the Ububtu phone - and subsequently scrapped all plans just because they didn’t meet the target. There was already a big dev scene in the community with people porting Ubuntu to Android phones - they could’ve easily partnered up with them, like how OnePlus partnered up with CyanogenMod a year later. I mean, Canonical did raise $12mil through the campaign, which showed there was not only plenty of interest, but also plenty of people willing to actually fund it.

The problem now is Google and Apple have taken such a deep foothold on the market, it may be a bit too late. After the disappointment of the scrapped Ububtu Phone and subsequent loss of trust in Canonical over the years, I can’t help but be sceptical about this whole thing. I’ll celebrate if and when we have an actual, usable, flagship device in our hands, and not something gimped like the Librem 5 or the Pinephone.

d3Xt3r ,

Nice review, thanks for sharing! I was curious about how the V3 was with Linux. I’ve got a Minisforum UM780 mini PC with a 7840HS, which I use as a homelab box, and it’s been excellent on Arch. I was tempted to get the V3 as well, but 14" is a bit too big for my use case (primarily as a tablet).

But it’s nice knowing that even the fingerprint reader worked out of the box, I know that’s been a sore point for many Linux users. The battery life seems a bit on the lower end though - have you tried TuneD yet? Apparently some folks have experienced better battery life with it, compared to PPD. I’m also curious what the battery life would be like if you ran a distro which used x86-64-v4 packages, such as CachyOS, in theory you should get better battery life since you’d be using more optimised instructions.

d3Xt3r ,

What’s the actual error message when you do the import? If there’s no graphical error, try launching it from the terminal and check the messages in the terminal when you try to import the video.

d3Xt3r ,

Hi there, while your post is technically on-topic, it would be more appropriate to post it in a community like !unixporn - that way we’re not flooded with screenshots. :)

I’ll leave this post up for now, unless we get many complaints.

d3Xt3r ,

I’m not sure what Gaduda is using, but neofetch supports various logo backends (with ASCII being the default). To get a high-resolution image, you might want to use one of the sixel/tycat/w3m/kitty backends (depending on what image protocol your terminal supports).

github.com/dylanaraps/neofetch/…/Image-Backends

d3Xt3r ,

The official wiki also has a ton of performance tuning tips, which worth checking out (especially the page on workload tuning).

d3Xt3r ,

Although not the same, this has been going on for about two years now. Jensen Harris, a former MS engineer, criticized the ads as well as the design of the new Start Menu, over here: threadreaderapp.com/…/1564399431545667585.html

d3Xt3r ,

A microplane grater - it’s been really great for dealing with ginger, and even garlic (although for garlic I mostly prefer to just squish it with the flat side of my knife). I’ve also used the slicer end to make chips out of baby potatoes and turnips.

Another go-to for me is a conventional pressure cooker - I use it when I’m feeling lazy, I just chuck everything in it - lentils/beans + rice + veggies + condiments, and it’s all done in one go, only takes 15-20 minutes and there’s no need to soak stuff beforehand. The best part is that I put all my ingredients in just a single ceramic bowl, so cleaning the cooker is super easy (just rinse it with water), and I can eat directly off the bowl, which saves me from having to use a separate dish.

d3Xt3r ,

I’ve been meaning to, but never got around to it. Thanks for the reminder!

d3Xt3r ,

Are there any things in Linux that need to be started over from scratch?

Yes, Linux itself! (ie the kernel). It would’ve been awesome if Linux were a microkernel, there’s so many advantages to it like security, modularity and resilience.

d3Xt3r ,

Third concern: dependencies.

I installed a fairly small rust program recently (post-XZ drama), and was a bit concerned when it pulled in literally hundreds of crates as dependencies. And I wasn’t planning on evaluating all of them to see if they were secure/trustworthy - who knows if one of them had a backdoor like XZ? Rust can claim to be as secure as Fort Xnox, but it means nothing if you have hundreds of randoms constantly going in and out of the building, and we don’t know who’s doing the auditing and holding them accountable.

d3Xt3r ,

Waydroid works, but there’s three main things you need to get things going to replicate a typical Android device:

  • OpenGapps: For GApps/Play Store. You’ll also need to register your device to get an Android ID.
  • Magisk: Mainly to pass SafetyNet / Play Integrity basic checks.
  • libndk / libhoudini: For ARM > x86 translation. libndk works better on AMD.
  • Widevine: (optional) L3 DRM for things that need it, eg Netflix

There are some automated scripts that can set this all up. I used this one in the past with some success.

Also, stay away from nVidia. From what I recall, it just doesn’t work, or there are other issues like crashes. But if you’re serious about Linux in general, then ditching nVidia is generally a good idea.

Finally, games that use anti-cheat can be a hit-or-miss (like Genshin Impact, which crashed when I last tried it). But that’s something that you may face on any emulator, I mean, any decent anti-cheat system would detect the usage of emulators.

d3Xt3r ,

Agreed. @cypherpunks, I think this would be a great idea - making a weekly megathread for Linux questions, preferably also stickied for visibility.

d3Xt3r ,

The general answer is to enable the RPM Fusion repos. But that won’t automagically install the drivers for you, you’ll need to manually identify what’s needed and install them accordingly. This guide is a decent starting point: fosslinux.com/…/how-to-install-key-drivers-on-you…

But also consider simply using a distro/spin that has all the drivers included (or automates the install), such as Nobara, or one of the Fedora Universal Blue distros.

d3Xt3r ,

The Linux kernel supports reading NTFS but not writing to it.

That’s not true. Since kernel 5.15, Linux uses the new NTFS3 driver, which supports both read and write. And performance wise it’s much better than the old ntfs-3g FUSE driver, and it’s also arguably better in stability too, since at least kernel 6.2.

Personally though, I’d recommend being on 6.8+ if you’re going to use NTFS seriously, or at the very least, 6.2 (as 6.2 introduces the mount options windows_names and nocase). @snooggums

d3Xt3r ,

In addition to static linking, you can also load bundled dynamic libraries via RPATH, which is a section in an ELF binary where you can specify a custom library location. Assuming you’re using gcc, you could set the LD_RUN_PATH environment variable to specify the folder path containing your libraries. There may be a similar option for other compilers too, because in the end they’d be spitting out an ELF, and RPATH is part of the ELF spec.

BUT I agree with what @Nibodhika wrote - this is generally a bad idea. In addition to what they stated, a big issue could be the licensing - the license of your app may not be compatible with the license of the library. For instance, if the library is licensed under the GPL, then you have to ship your app under GPL as well - which you may or may not want. And if you’re using several different libraries, then you’ll have to verify each of their licenses and ensure that you’re not violating or conflicting with any of them.

Another issue is that the libraries you ship with your program may not be optimal for the user’s device or use case. For instance, a user may prefer libraries compiled for their particular CPU’s microarchitecture for best performance, and by forcing your own libraries, you’d be denying them that. That’s why it’s best left to the distro/user.

In saying that, you could ship your app as a Flatpak - that way you don’t have to worry about the versions of libraries on the user’s system or causing conflicts.

d3Xt3r , (edited )

I’m not super familiar with ZFS so I can’t elaborate much on those bits, but hardlinks are just pointers to the same inode number (which is a filesystem’s internal identifier for every file). The concept of a hardlink is a file-level concept basically. Commands like lsblk, df etc work on a filesystem level - they don’t know or care about the individual files/links etc, instead, they work based off the metadata reported directly by the filesystem. So hardlinks or not, it makes no difference to them.

Now this is contrary to how tools like du, ncdu etc work - they work by traversing thru the directories and adding up the actual sizes of the files. du in particular is clever about it - if one or more hardlinks to a file exists in the same folder, then it’s smart enough to count it only once. Other file-level programs may or may not take this into account, so you’ll have to verify their behavior.

As for move operations, it depends largely on whether the move is within the same filesystem or across filesystems, and the tools or commands used to perform the move.

When a file or directory is moved within the same filesystem, it generally doesn’t affect hardlinks in a significant way. The inode remains the same, as do the data blocks on the disk. Only the directory entries pointing to the inode are updated. This means if you move a file that has hardlinks pointing to it within the same filesystem, all the links still point to the same inode, and hence, to the same content. The move operation does not affect the integrity or the accessibility of the hardlinks.

Moving files or directories across different filesystems (including external storage) behaves differently, because each filesystem has its own set of inodes.

  • The move operation in this scenario is effectively a copy followed by a delete. The file is copied to the target filesystem, which assigns it a new inode, and then the original file is deleted from the source filesystem.
  • If the file had hardlinks within the original filesystem, these links are not copied to the new filesystem. Instead, they remain as separate entities pointing to the now-deleted file’s original content (until it’s actually deleted). This means that after the move, the hardlinks in the original filesystem still point to the content that was there before the move, but there’s no link between these and the newly copied file in the new filesystem.

I believe hardlinks shouldn’t affect zfs migrations as well, since it should preserve the inode and object ID information, as per my understanding.

d3Xt3r ,

As an Arch user (btw), that’s rarely an issue thanks to the AUR and it’s vast package pool :) But on the very rare occasion that it’s not there on the AUR but available as a deb, I can use a tool called Debtap to convert the .deb to the Arch’s .tar.zst package.

For rpm-based distros like Fedora and OpenSUSE etc, there’s a similar tool called alien that can convert the .deb to .rpm.

In both instances though, dependencies can be a pain, sometimes you may need to trawl thru the dependencies and convert/install them, before to do the main package.

Ideally though, you’d just compile from source. It used to be a daunting task in the old days, but with modern CPUs and build systems like meson, it’s not really a big deal these days. You’d just follow the build instructions on the package’s git repo, and usually it’s just a simple copy-paste job.

Finally, if these packages are just regular apps (and not system-level packages like themes etc), then there are multiple options these days such as using containers like Distrobox, or installing a Flatpak/Appimage version of that app, if available.

d3Xt3r , (edited )

Thanks! Yep I mentioned you directly seeing as all the other other mods here are inactive. I’m on c/linux practically every day, so happy to manage the weekly stickies and help out with the moderation. :)

d3Xt3r , (edited )

In addition to the other replies, one of the main draws of Wayland is that it’s much less succeptible to screen-tearing / jerky movements that you might sometimes experience on X11 - like when you’re dragging around windows or doing something graphics/video heavy. Wayland just feels much smoother and responsive overall. Other draws include support for modern monitor/GPU features like variable refresh rates, HDR, mixed DPI scaling and so on. And there’s plenty of stuff still in the works along those lines.

Security is another major draw. Under X11, any program can directly record what’s on your screen, capture your clipboard contents, monitor and simulate keyboard input/output - without your permission or knowledge. That’s considered a huge security risk in the modern climate. Wayland on the other hand employs something called “portals”, that act as a middleman and allow the user to explicitly permit applications access to these things. Which has also been a sore point for many users and developers, because the old way of doing these things no longer works, and this broke a lot of apps and workflows. But many apps have since been updated, and many newer apps have been written to work in this new environment. So there’s a bit of growing pains in this area.

In terms of major incompatibilities with Wayland - XFCE is still a work-in-progress but nearly there (should be ready maybe later this year), but some older DE/WMs may never get updated for Wayland (such as OpenBox and Fluxbox). Gnome and KDE work just fine though under Wayland. nVidia’s proprietary drivers are still glitchy/incomplete under Wayland (but AMD and Intel work fine). Wine/Proton’s Wayland support is a work-in-progress, but works fine under XWayland.

Speaking of which, “XWayland” is kinda like a compatibility layer which can run older applications written for X11. Basically it’s an X11 server that runs inside Wayland, so you can still run your older apps. But there are still certain limitations, like if you’ve got a keyboard macro tool running under XWayland, it’ll only work for other X11 apps and not the rest of your Wayland desktop. So ideally you’d want to use an app which has native Wayland support. And for some apps, you may need to pass on special flags to enable Wayland support (eg: Chrome/Chromium based browsers), otherwise it’ll run under XWayland. So before you make the switch to Wayland, you’ll need to be aware of these potential issues/limitations.

d3Xt3r ,

That wasn’t the point I was trying to make though. :)

Chrome(ium) still doesn’t run natively under Wayland by default - you’ll need to manually pass specific flags to the executable to tell it to use Wayland. See: wiki.archlinux.org/title/chromium#Native_Wayland_…

Firefox also needed manual flags, but not anymore - Wayland support is enabled by default since version 121, released around three months ago. But some distros had enabled Wayland for Firefox much before that, Fedora being one of them.

d3Xt3r ,

The network transparency thing is no longer a limitation with Wayland btw, thanks to PipeWire and Waypipe.

d3Xt3r ,

Are you sure? I just tested it on Fedora 39, using Chrome v123 (Flatpak) and Chromium v123 (repo package), both of them were running under XWayland.

d3Xt3r , (edited )

To add to what @bloodfart wrote, the history of TTYs (or virtual consoles) goes all the way back to the early days of computing and teletypewriter machines.

In the old days, computers were gigantic, super expensive, and operated in batch mode. Input was often provided through punched cards or magnetic tape, and output was printed on paper. As interactive computing developed, the old teletypewriters (aka TTYs) were repurposed from telecommunication, to serve as interactive terminals for computers. These devices allowed operators to type commands and receive immediate feedback from the computer.

With advancements in technology, physical teletypewriters were eventually replaced by electronic terminals - essentially keyboards and monitors connected to the mainframe. The term “TTY” persisted, however, now referring to these electronic terminals.

When Unix came out in the 70s, it adopted the TTY concept to manage multiple interactive user sessions simultaneously. As personal computing evolved, particularly with the introduction of Linux, the concept of virtual consoles (VCs) was introduced. These were software implementations that mimicked the behavior of physical terminals, allowing multiple user sessions to be managed via a single physical console. This was particularly useful in multi-user and server environments.

This is also where the term “terminal” or “console” originates from btw, because back in the day these were physical terminals/consoles, later they referred to the virtual consoles, and now they refer to a terminal app (technically called a “terminal emulator” - and now you know why they’re called an “emulator”).

With the advent of graphical interfaces, there was no longer a need for a TTY to switch user sessions, since you could do that via the display manager (logon screen). However, TTYs are still useful for offering a reliable fallback when the graphical environment fails, and also as a means to quickly switch between multiple user sessions, or for general troubleshooting. So if your system hangs or crashes for whatever reason - don’t force a reset, instead try jumping into a different TTY. And if that fails, there’s REISUB.

d3Xt3r ,

I’m not aware of any distros that works better on Intel Macs - in general you may find one or two things not working (like WiFi or Bluetooth), that may take extra steps to resolve.

You can check general compatibility here: wiki.archlinux.org/title/Laptop/Apple

In saying that, if you like the macos aesthetic, you might be interested in elementary OS.

d3Xt3r ,

Actually binaries can include non-executable files as well! Strictly speaking, a “binary” refers to pretty much any file that’s not plain-text (so if you tried to open a binary in a text editor, you’d see gibberish).

d3Xt3r ,

The big benefit is that you get damn near 100% compatibility with even games that have windows only anti-cheat because… you’re running windows.

This isn’t necessarily true - most anti-cheat programs detect VMs, and depending on the game, some may prevent you from launching the game (eg games using Vanguard), others may flag you and cause you to get kicked out of the game, or even get you banned (Battleye is pretty notorious for this, from what I hear).

Now there are some tricks you can use, such as editing the XML for your VM to mimic your host machine’s SMBIOS data / vendor strings etc, but it’s a bit of work and can be a hit-or-miss.

Of course, the best option would be to not support games which use invasive anti-cheat in the first place. :)

And if you’re on nVidia, it can be a bit of a pain to get it all going, since you need to patch your GPU’s vBIOS. You can see how much work is involved in setting it all up over here: gitlab.com/Mageas/single-gup-passthrough - so not for the faint-hearted. :)

cc: @JinxLuckless

d3Xt3r , (edited )

You can just install the tools you want on your host OS. But if it’s like hundreds of tools then yeah makes more sense to run it inside a VM, just so it’s all nice and separate from your daily-driver. And you may think it’s funny but the performance of Linux-on-Linux is actually pretty good, and there isn’t much of a RAM/CPU overhead either. And if you’re really strapped for RAM, you could use KSM (kernel samepage merging) and ballooning.

Many Linux users use VMs (or containers) for separate workloads, and it’s a completely normal thing to do. For instance, on my homelab box, my host OS is my daily-driver, but all my lab stuff (Kubernetes, Ansible etc) all run under VMs. The performance is so good that you won’t even notice/care that it’s running on a VM. This is all thanks to the Linux/KVM/QEMU/libvirt stack, if it were something else like VMWare or VBox, it’d be a lot more clunkier and you can feel that it’s running on a VM - but that’s not the case with KVM.

d3Xt3r ,

I’m running Linux mint

I’d say that’s your main issue. Mint isn’t really optimised for gaming, as it uses an old and non-gaming optimised kernel, and most packages in general are pretty old. When it comes to Linux and gaming, the #1 rule is to try to get the latest kernel and graphics drivers. You could install a more recent and optimised kernel on Mint, but if you do that you risk breaking things, which may especially happen when you do your next OS upgrade. So I’d recommend switching to either a gaming-optimised distro such as Bazzite, or a distro which has the latest packages and is optimised for performance, such as CachyOS (although I wouldn’t recommend it if you’re still very new to Linux, since it’s based on Arch - if you’re new to Linux then Bazzite would be a better option).

The second issue is - which version of Proton are you using? If you’re using the official Proton, I’d recommend using Proton-GE instead, as it includes a lot of extra patches and tweaks not present in the official Proton + uses more up-to-date components like DXVK. You can install Proton-GE easily using ProtonUp-Qt. Once you’ve installed Proton-GE, go to the game’s property in Steam and change the compatibility tool to Proton-GE.

d3Xt3r ,

This was answered previously in this thread: lemmy.ml/comment/10140174

d3Xt3r ,

NetworkManager doesn’t support DoH, DoT or other recent protocols like DoQ and DoH3. You’ll need to set up a local DNS resolver / proxy which can handle those protocols. You could use dnsproxy for this. Once you set it up, you can just use “127.0.0.1” as your DNS server in NetworkManager.

Btw, if possible I’d recommend sticking to DoH3 (DNS-over-HTTP/3) or DoQ (DNS-over-QUIC) - they perform better than DoT and vanilla DoH, and are more reliable as well.

d3Xt3r ,

I think you’d be fine with either, but in the end it comes down to how “hands-off” you want to be, or how much customisability, flexibility and performance you’re after. Unlike Manjaro, Cachy is closer to Arch, which means things may on rare occasions break or may require manual intervention (you’ll need to keep up with the Arch news). Bazzite on the other hand is the polar opposite, being an immutable distro - updates are atomic (they either work or don’t, and in case an update is no good, you can easily rollback to a previous version from GRUB); but this also means you lose some customisability and flexibility - like you can’t run a custom kernel or mess with the display manager (logon screen) etc, and you’ll need to mostly stick to installing apps via Flatpak or Distrobox.

Overall, if you’re after a console-like experience that just works™, then choose Bazzite. On the other hand, if you’re a hands-on type of person who likes to fine-tune things and is after the best possible performance, choose CachyOS.

How the xz backdoor highlights a major flaw in Nix (shadeyg56.vercel.app)

The main issue is the handling of security updates within the Nixpkgs ecosystem, which relies on Nix’s CI system, Hydra, to test and build packages. Due to the extensive number of packages in the Nixpkgs repository, the process can be slow, causing delays in the release of updates. As an example, the updated xz 5.4.6 package...

d3Xt3r OP , (edited )

First of all, I’m not the author of the article, so you’re barking up the wrong tree.

You’re using the unstable channel.

That doesn’t matter in the big scheme of things - it doesn’t solve the fundamental issue of slow security updates.

You could literally build it on your own, or patch your own change without having to wait - all you have to do is update the SHA256 hash and the tag/commit hash.

Do you seriously expect people to do that every time there’s a security update? Especially considering how large the ecosystem is? And what if someone wasn’t aware of the issue, do you really expect people to be across every single vulnerability across the hundreds or thousands of OSS projects that may be tied to the packages you’ve got on your machine?

The rest of your points also assume that the older packages don’t have a vulnerability. The point of this post isn’t really about the xz backdoor, but to highlight the issue of slow security updates.

If you’re not using Nix the way it is intended to be, it is on you. Your over-reliance on Hydra is not the fault of Nix in any way.

Citation needed. I’ve never seen the Nix developers state that in any official capacity.

d3Xt3r ,

iwd is great. In fact I’d say take it a step further and get rid of the beast that is NetworkManager as well.

austindw.com/networkmanager-is-bloat/

d3Xt3r ,

There are lightweight GUI options for that too. For iwd, you can use iwgtk. For VPN, that would depend on your VPN protocol/service. Some providers like Proton have their own client, others can use something like Wireguard Client (as an example) or something similar depending on your VPN setup.

d3Xt3r ,

No, you’re right. There’s no organisation options. It’s pretty barebones overall, and doesn’t look great on large foldables either. Guess there’s no reason to switch from my current launcher.

d3Xt3r ,

AIO Launcher - not for everyone, but I prefer function over form. :)

d3Xt3r ,

I know it’s not the same thing, but this kina reminds me of the old GDI object limit in Windows which had an upper limit of 65,536. If you reached that limit your system would start exhibiting all sorts of weird glitches, including not being able to launch any apps even if you had plenty of free RAM.

d3Xt3r ,

No, @lseif is correct.

I just did a test using dd - I created 100 files of exactly 1 MiB each (1048576 bytes). du reported the size as “100M” as expected, whereas eza reported it as “105M” - which is what you’d get if you divided 104857600 by 1000000 (= 104.8576 or 105M if you round it off).

d3Xt3r ,

I was talking about the 1000 vs 1024 issue, do the dd test yourself and it’s easy to verify that he was right.

As for the specific descrepancy that you’re seeing, lots of things can throw off a file size calculation - symlinks, sparse files, reflinks, compression etc. Since you’re the only one with access to your files, you’ll need to investigate and come to a conclusion yourself (and file a bug report if necessary).

d3Xt3r , (edited )

If you’re going for a container/VM-first approach, you might be interested in Bluefin DX - it’s an immutable distro based on Fedora Atomic, and follows a workflow revolving around containers and VMs. Basically tuned exactly for homelab users and developers, who’re looking for a stable yet up-to-date base (unlike Debian, which tends to use outdated packages, unless you’re on Sid). The biggest advantages of using an immutable distro is that you never have to worry about a broken update again - so you can just focus on your work.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • random
  • lifeLocal
  • goranko
  • All magazines