GeneralThis forum is for non-technical general discussion which can include both Linux and non-Linux topics. Have fun!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
3.16. /srv : Data for services provided by this system
3.16.1. Purpose
/srv contains site-specific data which is served by this system.
Rationale
This main purpose of specifying this is so that users may find the location of the data files for particular
service, and so that services which require a single tree for readonly data, writable data and scripts (such as
cgi scripts) can be reasonably placed. Data that is only of interest to a specific user should go in that users’
home directory.
The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on
how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www,
and cvs. On large systems it can be useful to structure /srv by administrative context, such as
/srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program
should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv.
However /srv should always exist on FHS compliant systems and should be used as the default location for
such data.
Distributions must take care not to remove locally placed files in these directories without administrator
permission.
That reminds me...for some weird reason, my dad says "Linux" with a long "i", as in "line-ux". O_o
Festival (at least on my Arch machine) says it that way, too.
As for the rest:
etc - "et setera"
usr - "user"
var - a bit undecided, but I lean towards "vahr" (rhyming with "car")
GNOME - "nome" i.e. no hard "g"
GNU - "gənu" i.e. exactly as spelled
sudo - I lean towards "sue-dough", but still undecided
In total, a lot of Linux/UNIX terminology is weird, so I try not to "pronounce" them at all, save for the sub-vocalizations that you do anyway when you read them.
Phonetic 'hieroglyphs" are never meant to be literally spoken.
Ideas represented as characters. Acronyms are a phonetic device used to associate an idea to a single representation of that idea.
Considering that colloquialism reflects the spoken languages more than the grammatically correct form, a person will receive multiple translations of a word.
@MrCode, I pronounce Linux the same way as your dad. LINE-UX.
My argument for doing so is that the English pronunciation of Linus is LINE-US (Like the kid out of Peanuts) so therefore it makes perfect sense that the English pronunciation of Linux should follow the same rules. Linus being Finnish will obviously pronounce it in a Finnish way.
Consider it a localisation. You say tomaaaaato, I say tomarrrrto.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.