Greetings from a Manjaro refugee

Why not use kdeconnect for file transfer, remote input, media control and filesystem sharing?

What I mean here is the difference between the two. In an attempt to get it working I installed KUbuntu 22.04 in a VM. Right out of the box, right click, I can share. No muss, no fuss. That is where the hot mess statement comes from.

Also, I did follow those directions. I did reboot after thinking I needed to do that. No change. I then thought, t’hell with this, let’s just pull the KUbuntu smb.conf over since clearly something there is working. Hence the VM. Pulled that smb.conf over, copied into place, rebooted, no change. Still cannot right click and share.

Because VLC does not view videos over that? VLC, on android, connecting to my main machine. I’m not sharing files from my tablet to my machine.

1 Like

Yeah, that’s one of the reasons why Kubuntu sucks and is bloated and slow. Enabling a bunch of useless crap out of the box.

Arch is a DIY distro, you install and enable what you need.

Explain to me how installing Samba in a useless state is somehow better? Ubuntu does not ship Samba installed by default. I had to opt to install it. But you would think, having decided to install it, I might just, you know, want to have it functional?

That depends on one’s use case. I have the package samba installed, and it is completely functional at what I need it to do: sit there and do nothing, while satisfying a silly dependency for Dolphin. Having the service enabled out of the box in my case would be a pain.

If you want further functionality, you can enable it yourself.

As a general philosophy on Arch, services are not enabled behind the user’s back. I see that as a good thing.

Plasma breaks this philosophy by having Baloo enabled by default, and EndeavourOS breaks this philosophy with its stupid little update notifier timer. That is something I’ve always criticised. But since it also does this with Network Manager, and firewalld, it’s not a big deal.

On the other hand, CUPS is properly handled.

So there is no need to do the same mistake with Samba.

1 Like

I find it is often easier to easily disable something from defaults, than to have something installed in a broken state and then try to fix it.

Apparently not because following the directions from the Arch wiki and pulling configs from a working system have failed to enable this simple feature.

Bull. I didn’t installed, nor configure, nor enable Pipewaire and yet…

grey         951  0.0  0.1 140532 29492 ?        S<sl Jul06  11:44 /usr/bin/pipewire
grey         953  0.1  0.9 177592 159508 ?       S<sl Jul06  21:03 /usr/bin/pipewire-pulse
grey      288375  0.0  0.0   6684  2592 pts/0    S+   01:40   0:00 grep -i pipewire

…there it is, enabled behind my back. Same with SDDM, X11,SystemD, a slew of XDG portals, and I believe SSH was installed by defaults as I don’t recall installing it on my laptop but I could be wrong. Even if I were wrong and I installed SSH I sure didn’t have to configure and enable it to get it running.

Forgot about Network Manager in the above…

Yeah, brokenly.

I disagree. The moment I hit yay -Syu samba there is no ā€œbehind my backā€ about it. I accepted the defaults. The difference here is that unlike the slew of examples above, this one is shipped with broken defaults, instead of sensible ones. I happen to expect packages to ship with sensible defaults for the distro at hand. And contrary to what you think, most do. This isn’t LFS.

Your premise that Samba is installed in a broken state is plain wrong. Just because it is not preconfigured in a way that it does what you want does not mean it is broken.

If you find following the simple instructions from the Arch wiki too difficult, you should maybe consider using a simpler distro, like 'Buntu. Of course the downside is that it is bloated, but this is exactly what you want EndeavourOS to be.

If I wanted a distro that I have to spend hours to manually debloat after installation, I’d use Manjaro.

In the bloat vs. minimalism dilemma, it’s always better to err on the side of minimalism. Otherwise, it gets out of hand really, really quickly.

2 Likes

Uh-huh. And yet I gave several other examples of services installed that come with a sensible set of defaults to actually work, and you called 0 of them ā€œbloatedā€ for being so installed.

You’ve also not explained the point of installing a file sharing protocol and have it completely non-functional as a sensible default. Of course, if you did, I would then ask why Pipewire works out of the box as a sensible default.

Oh, I don’t find them hard to follow at all. In case you missed the implication, I think they’re broken.

You definition of bloat and everyone else’s definition of bloat are wildly different. Functional is not bloated. Having things installed by default that don’t need to be there, that’s bloat.

There’s a difference between minimalism, and non-functional.

Samba is not installed by default. So, please explain how in your warped sense of reality when a user explicitly commands the system to install a file-sharing protocol having it installed in a broken state is preferred to a functional state. Please also explain how that differs from the slew of other services that EndeavourOS installs by default, and in a functional state? Because I have this tub of popcorn ready and I really want to see your gymnastics on why I need to configure Samba to work, but not Pipewire, X11, Network Manager, SSH, nearly all of KDE, XDG portals and literally dozens of more examples that I could come up with.

Yes I have, as a dependency for another package, which is how most users ā€œuseā€ it. You can’t have Dolphin installed without Samba, even if you don’t use it. It’s a stupid dependency, but it is how it is.

In general, Samba is a fairly useless protocol, which only Micro$oft and Android users need. Having it enabled just exposes the system to vulnerabilities and ransomware. Why would anyone want that crap actively running is beyond me.

Given these two points, it is perfectly reasonable not to have Samba enabled by default.

But just in case somebody does want it enabled, there are instructions on the wiki for how to do it.

I think that’s a pebcak.

1 Like

Sounds like a Dolphin problem, not a Samba problem. Considering that you can install Samba without Dolphin (probably the larger use case) that is what the defaults should be geared for.

In your opinion.

Yes, which is why it isn’t installed by default.

To interoperate with their other devices? Just because you don’t have a use case does not mean use cases do not exist.

Given the slew of other services which are enabled by default, you’re objectively wrong.

Given that you clearly haven’t tried them, and I have, how can you be so sure? I mean I followed them exactly. Installed it, created the group, added by user to the group, does not work. That means something is missing. Before calling it PEBCAK I’d ask you to try and point out what I am missing. Because until then, you’re just being insulting to cover up your lack of responses.

Oh boy, you’re so wrong here. Given that KDE is the most popular DE on Arch, there are many, many more KDE users than Samba users.

You want them all to have to disable a potentially dangerous service just because you can’t follow the instructions on the wiki. Absurd.

I think @moderators should split this off-topic section, as it is unfair to the OP. And probably close it…

Take a look at Quickserve :wink:

1 Like

Again, explain where I failed before making that charge.

And this is just laughable.

Your claim, no service should be configured to work by default without user intervention. Just for giggles I installed Apache on my laptop just now.

Screenshot_20220720_030317

There’s Apache fresh after install, functional. Add that to the list of services that are functional upon install. Your case is looking weak.

You’re asking a bit much… :crystal_ball:

Not seeing how a small HTTP server is replicating SMB?

No, I’m not. If your claim is that I failed to follow the directions, and I am claiming that I did and it is not working, the least you can do is attempt a replication. Until you do you cannot claim that I am failing to follow the directions properly.

But that would involve me using Samba, which is not something I am comfortable with, as it is dangerous rubbish. :wink:

Then I kindly ask you stop making a claim you cannot back up.

Well, did you manage to follow the instructions to the successful resolution? Nope.

What is more probable: that the wiki is entry wrong, or that you made a mistake? Definitely the latter. Either that, or you’re the only person wanting to use Samba on Arch and nobody else noticed the wiki being wrong. :man_shrugging:

Which has multiple causes.

How many of those people are looking for the share dialog in KDE’s folder properties to work? Wiki’s are wrong all the time; that is why they are Wiki’s. The Wiki philosophy is to make correcting mistakes easy because mistakes, or, more likely, a drift in how things used to work and how they now work, are common.