That's true, but the syntax is different then. In this blog post I cover fish, and I didn't intent to say that this cannot be done in other shells (and I think I never said so).
Pretty unrelated, but I just wanted to say that I love how bash scripting uses if to open an if statement and fi to close it... makes me giggle every time lol
If that is something people want, then there will be distributions integrating AI tools as default configuration. But probably mostly open source solutions only. And most people maybe don't want AI applications, so there will always be AI free distros available. As long as it is not proprietary and controlled by one company only, I don't see any problem with integrating AI.
Personally, my (uneducated) opinion is that we already have plug-and-play functionality on a program level ie I can add an OpenAI api key to various programs and make them 'smarter'. Since the Linux experience is often pretty piecemeal as is, this would be a solid enough approach for most.
In terms of AI being ingrained within a Desktop Environment, that seems harder for me to imagine... Like how the Office Suite has AI functionality, would the KDE suite of apps allow for cross-program functionality? Would this require a substantial change in system requirements for local processing? Would there be an open-source LLM hosted in the cloud for chat purposes that also mirrors the privacy expectations of the average Linux user?
I understand people's apprehension towards Linux distros seemingly chasing the latest fad, but I think it's also worth hypothesizing the alternative if AI and LLMs are here to stay/differentiate.
LLMs are big, so you either need a powerful PC to run them or use cloud services. Linux users tend to not be fans of either, so it’ll probably take a while before anything big happens.
Besides, for the things where an LLM actually makes sense (like a copilot-style code generator), there are already implementations.
I am a Debian user, and I can't really say I am not a fan of "Big". I have a laptop as my production machine but I also have as big a file server as I can afford. I would not want an AI that is part of my OS unless it is local. I do use ChatGPT and Stable Diffusion, but only for non-critical functions.
You can create sudoers rules that allow users to run specific commands with root privileges.
Create a file in /etc/sudoers.d with the contents:
zabbix ALL=(ALL:ALL) NOPASSWD: /sbin/zfs status
This will grant the zabbix user the ability to run /sbin/zfs status as root without a password. However, they will need to run the command with sudo. If you want to allow that user to run additional commands, just add them to the end of that line like this:
zabbix ALL=(ALL:ALL) NOPASSWORD: /sbin/zfs status, /sbin/zpool status
So I don't know what file access logs I should look at. All the samba logs have essentially had nothing at all in them except for variations on [2023/09/28 23:50:31, 0] ../../source3/rpc_server/rpc_worker.c:1125(rpc_worker_main) rpcd_winreg version 4.18.6 started. Copyright Andrew Tridgell and the Samba Team 1992-2023
so it doesn't seem like they're going to be of any help here...
The new files do show and launch on the server itself just fine.
Stopping samba does produce the expected timeout errors on clients
Renamed file does show as renamed. Bonus, a new file I created on the server from context menu "New text file" entry does also show on clients
Renamed file does show as renamed. Bonus, a new file I created on the server from context menu "New text file" entry does also show on clients
Hmm... so what's different about the files that don't show up? If we can figure that out, that may point to the solution... Were they created in a notably different way (e.g. uploaded from a client)? Are they symlinked into the directory? Are they named in a notably different way? Very different in size? You've said you've already checked file permissions, but what about the actual owner/group -- are they the same as the files that do show up?
Is SELinux (or some other security software) running and doing something weird maybe? For Fedora, I think there would be a log entry at /var/log/audit/audit.log if something is getting blocked due to a security policy, but I don't run Fedora personally.
Turns out, yes it was. For Samba shares, SELinux requires every file to have the sudo semanage fcontext --add --type "samba_share_t" command run on it. And of course, the new files wouldn't have had this like the ones that were present when I was setting up Samba...
I expanded my search to making a post on the Fedora forums, where an @/glb pointed out that fact, and thankfully was able to also state that adding it to fstab for the drive will automate that process at boot. So the issue is now solved, thanks to glb over here: https://discussion.fedoraproject.org/t/file-sharing-woes-samba-nfs-sftp/91112/13
Linux
Newest