[kde-doc-english] sudo? - DOCUMENTATION

Jerry Nelson jerrynelson at speakeasy.net
Thu May 23 20:29:11 UTC 2013


At 5/21/2013  01:49 AM  Tuesday, you wrote:
>написане Tue, 21 May 2013 04:35:46 +0300, Jerry Nelson
><jerrynelson at speakeasy.net>:
>
>>"Sudo" does not appear in the alphabetized list.
>>I see no topic heading on root, or privileges, or super user.
>>
>>I start the editor, I am not warned I have no privileges to change the
>>file, I
>>work and cannot save my work.  This is a dead end that wastes my work.
>>
>>Please enrich the documentation to deal with "privileges", "superuser"
>>"sudo".
>>
>>Please add a warning if I lack r/w privileges for the file I have opened.
>>
>>Please make a menu item that gets me into sudo mode even if the menu is
>>only
>>informational and I must relaunch the app myself.
>>
>>I apologize in advance if there are answers to these issues in Kate and
>>I just
>>did not see them.
>>
>>kdesudo kate?
>>
>>--jerry
>
>Hi,
>
>Sure, it's a Kate bug (depends on developers PoV but closing without
>prompt to save the file with a different name is not a nice thing).
>
>Can you file a bug report against Kate [1]?
>
>@all Regarding documentation, can we just copy the old chapter about
>su/sudo from KDE 3 User Guide to Fundamentals taking into account that
>kdesudo is Ubuntu specific?
>
>Thanks in advance for your answers.
>
>Best regards,
>Yuri
>
>[1] https://bugs.kde.org/enter_bug.cgi?product=kate&format=guided
Yuri,
I filed the bug report.

When a noob starts to edit and forgets sudo, then 
can't save, what helps a lot is education and usage examples.

The glossary needs to have terms like "superuser" 
"root user" "sudo" and "kdesudo".  Even though 
the concept "root" made an appearance in the 
blockbuster movie "Jurassic Park", it still needs 
to be introduced to people for whom it never existed, or who forgot the movie.

For help about the relationships between things 
and their larger purposes (rather than the syntax 
of the commands needed to accomplish those 
purposes), the glossary is the avenue of entry.  It matters.

I still wonder (perhaps others also):

1. Is it OK to start a GUI app from the CLI with a sudo or kdesudo command?

(BTW, the Samba Server Configuration app, a GUI 
for system-config-samba, cannot be started from 
the KDE Application Launcher Menu [mode].  Samba 
has a pop-up to ask for the user pwd, but the popup will not accept any pwd.)

2. What is the difference between sudo and 
kdesudo or may I use them interchangeably?

3. Usage examples rather than man page text is the goal.

         "An easy way to edit a file in a folder 
with permission restrictions (e.g., an important systems folder)
         is to go to the folder that contains the file and start Kate with
         sudo kate NameOfFile2Edit."

         If you are building a new system, have 
added a drive, and need to change the file system 
table of drives, "fstab," you might do this:
         pwd - Where am I now?  Print my Working Directory.
         cd /  -  Change my director back up to the root.
         cd /etc  Change back down to the /etc folder.
         sudo kate fstab

CONCERNING COPYING OLD DOCUMENTATION INTO NEW:  ANSWER: YES, DO IT.

Yuri wrote 5/2013:
@all Regarding documentation, can we just copy the old chapter about
su/sudo from KDE 3 User Guide to Fundamentals taking into account that
kdesudo is Ubuntu specific?

Please divide all the documentation into

1. FOREWORD

2. DOCUMENTATION ABOUT PROGRAMS YOU WANT TO LAUNCH & USE
         alphabetical list
         if you break up the list,
         you must not divide it in any way that is different from
         how the Applications Launcher Menu 
[mode] chooses to divide the apps.
         It is OK, it is expected, that several 
programs will appear in both the "want to launch and use" list,
         and in the "move around the operating 
system and change/fix stuff" list.

3. DOCUMENTATION ABOUT VISITING AND MOVING AROUND IN THE OPERATING SYSTEM

Documentation [about specific programs, and, 
rarely, particular commands] that we need to add pgms:
         documentation to read if you want to run 
sudo apt-get install or find out what that means,
         or learn how to look for other 
"packages" to install: the Muon Package Manager, Ubuntu Software Center
         sudo apt-get install software-center
         Mention the Panel and Widgets.  Mention 
the search command in duckduckgo.com !upackages software-center
         "For programs that launch all the 
programs, read about:  link to Application Launcher, others.  "

Documentation [of pgms, apps] to read if you are 
adding drives or thinking about using a file 
system other than the current 
default:  gparted,  KDE Partition 
Manager,  fstab, mount, umount, etc see also 3rd 
party pcmanfm . . .    mkfs.btrfs, apt-get install btrfs-tools.

         "gparted / view / file system support" 
seems a very buried, indirect way to find out 
what file systems actually live in this new world.

         If there was a list of supported or somewhat-supported file systems
         (the list does not have to definitive; 
we need a guide, not a guarantee; you write, we 
wont' sue, just put in a disclaimer)
         with a list of file systems in the 
documentation , then under btrfs I might discover 
that btrfs-progs is now btrfs-tools,
         whatever.  The documentation would be 
the launch pad for discovery that is my problem, not yours.
         You are figuring out how to create an 
overview that is also tied to specific programs,
         you are not telling noobs to go out and kill themselves.

Documentation to read for file management -- 
moving around the folder tree, viewing and 
editing files, creating network shares,
         what can you do with Nepomuk and Strigi?  Dolphin!!  pcmanfm

Documentation [which pgm names?] to read if you 
want info on the opsys itself, or the underlying hardware
         KInfoCenter, System Monitor, maybe there are more . . .

THE FOREWORD

The FOREWORD can divide up the landscape in whatever is a convenient way.

I need to have several things mentioned, be told 
roughly their relationship, and be told 
explicitly (just a link) where to get more 
information about them.  The essential, 
mysterious things for the Foreword include:

Ubuntu, Kubuntu: both are variants of  Linux (you 
could reference a famous book or Website), 
Kubuntu is the KDE flavor of Ubuntu, and KDE is 
mostly graphics technology for changing how 
Kubuntu does its desktop compared to 
Ubuntu.  (References welcome.  I suggest using 
only famous institutionally stable ones that you 
won't have to change or update often).

I need a word about the relationship between the 
kernel and the overall "Ubuntu" or "Kubuntu " 
operating system.  Makes me think I don't 
understand what a kernel is when people in this 
world can run an old kernel with a new operating 
system (to save compatibility with a major app they have in production).

Now you are in a strong position to solve the 
mystery of the meaning of a "Long Term Support" 
edition  -- what must change, what will not change if you choose this.

You can give your own opinion ("In the humble 
opinion of some Kubuntu community members . . . 
").  Every time you realize that entire 
university course have been devoted to something 
you are oversimplifying, just make a humorous excuse and say it anyway.

It's nice that there is such a thing as a KDE 3 
User Guide to Fundamentals, and, here in the 
forward --- where it is nailed down in one or two 
sentences what KDE, Kubuntu and Ubuntu vs the 
kernel are --- here would be a fine place to 
discover its existence and have a link to it.

ABOUT THE COMMENTS AUTHOR:
I have used personal computers for over 30 years 
but I am a Linux novice.  My puzzlement over 
obvious things ("What is KDE?" "Just the 
desktop?") can be as great as a true noob, but 
(to my frustration) I know just what I am missing 
and how easy it would be to understand, if only someone would tell me.

I hope this helps.  I am in the midst of a big 
install, but soon I will forget the pain (and any 
suggestions that might have been useful), so I 
tried to capture what it feels like (capture the cognition, actually).

Make what you are creating the central place to 
start.  Let it link (selectively!)  to the 
definitive things in other parts of the 
open-source, Ubuntu / Debbian world.  Your 
documentation cannot ever be complete, it cannot 
be definitive ("Sue me if I'm wrong").   But it 
can be the best place to go, the best place to 
start.  "Discovery begins here."

--jerry


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-doc-english/attachments/20130523/cc52e27a/attachment.html>


More information about the kde-doc-english mailing list