Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.

Är GUI ett krav för dig?

Tråden skapades och har fått 56 svar. Det senaste inlägget skrevs .

Jag har tillbringat en hel del tid med Mac OS X Server och nyligen med Red Hat Linux 8.0 för att testa lite forumidéer osv. Jag slås av några saker:

- Båda systemen är väldigt snygga på ytan (även Red Hat!) och installationerna går ganska snabbt och smärtfritt för en ganska van datoranvändare som mig.

- I båda systemen ingår grundläggande gränssnitt för DNS, Web, FTP-tjänster där man i princip kan gör det allra mest grundläggande.

- I båda systemen tvingar man ut användaren i prompten när man ska göra vissa inställningar (som att konfigurera Apache och DNS). För en GUI-människa som jag (det var ju DÄRFÖR jag gick över till Mac!) så känns det lite ovant att börja skriva kommandon man inte har en aning om vad dom betyder.

Jag har lärt mig MYCKET under det senaste halvåret och jag lyckades faktiskt fixa nästan allt strul vid installationen av Red Hat utan att fråga någon! Tyvärr strulade andra saker så det var bara att ge upp trots allt - men det är en annan historia.

I OS X Server fallet så ägnade jag fler än 20 timmar åt att få forumet att fungera. Det var många hinder som stoppade mig och först när vi omkompilerat PHP och Apache till nya versioner med unika inställningar så fungerade det. Jag kan inte skriva på 99mac vad jag tycker om sådana saker.

Måste det vara så här? Är det bara jag som kräver GUI för allting? Är utvecklingen på väg bakåt - går utvecklingen mot en härlig C: prompt igen?

[ 08. mars 2003, 19:48: Meddelandet ändrat av: Martin Björnström ]

Om man ser på vars ifrån osx kommer från början och hur pass mycke GUI det finns där så kan vi väl se rätt så klart att utveckligen går frammåt. Det har inte funnits så mycke allmänna GUI´s att tillgå för de tyngre server-platformarna (UNIX-släket) heller vad jag vet.

Ger man denna utveckling lite tid så tror jag att de kommer går frammåt och bli bättre och bättre, det är ju trots allt inte alltför längesen som linux blev en "accepterad" affärsplatform, och det är just sådanna intressen som driver utvecklingen frammåt.

GUI är inget krav i alla lägen, men jag ser gärna att Apple strävar efter att fortsätta utveckla GUI till fler funktioner i OS X. För min egen del trivs jag rätt bra i Terminal, men visst är det trevligt att kunna ändra rättigheter på filer och mappar genom "Visa info" i Finder, tex.

Jo, jag förstår att OS X Server är alldeles nytt (lanserat januari 1999 - fyra år sedan) och att det antagligen kommer dröja något eller ett par år till innan dom har allting klart.

Det som är mest frustrerande är att en del av mina macvänner plötsligt "bytt lag" och säger - GUI...haha...det behövs inte...det är MYCKET lättare att logga in som root i terminalen och sedan köra en "sudo pico httpd_conf" och skriva lite sköna <virtualdomain> taggar...

Tror de beror på att man kanske har lusten att utforksa något nytt.

För mig var de precis tvärt om. Kommer från ett användande av Linux/BSD etc.. Så när jag började köra osx på jobbet blev jag imponerad över att allt gick så smidigt, var så logiskt, vackert och genomtänkt. Så sen dess är jag frälst vid osx GUI/arbetssätt.

Fler GUI är väl att vänta och hoppas på, men jag tycker inte det är jobbigt att köra terminal nej.. men ja föredrar GUI i de fall de finns dom som fungerar och tilfredställer de behov jag har.

Nu snackar vi alltså serverhantering. Där är väl inte GUI ett krav, men finns det ett bra gränssnitt så kan det vara enklare. Men det kan ju finnas ett precis lika bra gränssnitt i en terminal, om ej lika snyggt.

Själv tycker jag det är jäkligt smidigt att sköta webserver mm från en terminal, men fördelen att jag kan sitta överallt och administrera. Och slippa vnc.

Men snackar vi websurfning och spelande, så blir det väl lite bättre med GUI, trots Lynx och Tetris i terminalen

Det är inte direkt raketteknik om vi säger så.

(översta bilden - lägger till en ny site)

(understa bilden - lägger till en ny domän)

[ 08. mars 2003, 20:38: Meddelandet ändrat av: Martin Björnström ]

GUI är näst intill ett måste för mig för att inte tala om min mamma som precis lyckats lära sig använda sin Palm som företaget gav henne. Hur ska man kräva folk att lära sig saker utantill när enklast möjligt är att ge användaren ett logiskt flöde av information på skärmen? Jag kan relativt smärtfritt ta mig fram och göra enkla saker med kommandorader på *nix-maskiner. Men jag är en sucker för trevliga och intiutiva användargränssnitt och har redan blicken fäst vid horisonten, bort med hierakiska filsystem om möjligt. Fram för lifestreams!

Apple har gjort otroligt mycket för att dölja unixgrunden med ett bra GUI. Och de fortsätter med det även nu. Så även om vissa problem löses bäst utanför GUI i dagsläget så tror jag inte man behöver vara orolig för att GUI kommer att försvinna.

Och det är inte bara Apple. Var och varannan dag dyker det upp program på VersionTracker som är skal till kommandoradsprogram för *nix. Snygga aquafierade program som förenklar för användaren.

Men eftersom efterfrågan för just de funktioner som du syftar på är så liten, så har det lägre prioritet just nu.

Menar du att dom flesta föredrar att ändra i BIND inställningar - Apache konfigfiler osv?

Det finns en anledning till att 99mac fortfarande snurrar på Windows 2000 Server... Att konfiguerera en OS X Server med 30 domäner, dom ftp konton vi behöver, DNS trädet, loggning osv är inte något jag gör frivilligt.

  • Medlem
  • Malmö
  • 2003-03-09 00:07

Jag tror att det beror helt och hållet på vad man gör på sin dator.
Den administrativa delen av arbete kräver inte nödvändigtvis av en van användare en GUI.
Den sk bildmänniska, en konstnär, en illustrator, en musiker vill nog ha en GUI att arbeta med och inte en terminal.
Själv ser jag GUI som oumbärlig för de grupper jag nämnde ovan.
Visst får man kanske bredare spektrum av möjligheter om man kan göra saker utan GUI. Som exempel här kan nämnas kodning av webbsidor.
Till och med vid en webbproduktion klarar man sig mycket bra utan att skriva koden själv och varför ska man göra det när programmet kan göra det för en. I de flesta fall blir resultatet inte sämre.
De kodknackare som stoltserar med sina färdigheter använder ändå nästan i 100% en webbläsare för att se sina alster innan de publiceras. Är inte det bättre att jobba direkt i WYSIWG läge?
De som knackar kod för hand, när se surfar, gör de det i en webbläsare i GUI läge eller tittar de enbart på koden?

Är inte det mer naturligt att bara dra in från Finder de element vi behöver in i dokumentet såsom vi Mac användare blivit bortskämda med sen länge. Varför inte låta maskinen göra jobbet?

Är det någon illustratör idag som skriver Postscript kod istället att jobba direkt i Illustrator och Freehand med de verktyg som finns färdiga i programmet?
Det tror jag inte.

Att det finns något som heter terminal idag, är det brist på fantasi hos utvecklarna som inte förmår skapa en så täckande GUI att den klarar av alla funktioner?
Det tror jag inte.
Jag tror att det är det sista som de sk "wise man" vill behålla kvar som tecken på att de är inte som alla de andra.
De vill framstå som "de kunniga". Visa kallar sig för "professionella (Mac) användare", som om alla de vanliga, som musiker, layoutare, konstnärer och skribenter skulle vara ej professionella eftersom de fattar inte vad man ska med terminalen till.
I ett enda fall är jag glad att man tog bort det visuella.
Det visuella avbildandet av ljudstyrkan, kontrasten och andra inställnigar på tv. Ni vet, när man tryckte på volymknappen så kom fram en grön linje: ökar eller minskar. Som o man inte hörde det eller såg det!

  • Oregistrerad
  • 2003-03-09 00:14

För mig är svaret solklart: -Självklart skall vi ha GUI till allt!

Visst är det charmigt och lite kul att hacka i terminalen, det tycker jag. Precis som det är charmigt och lite kul att hinka upp vatten ur brunnen och värma till ett bad, istället för att använda kranen.
Men i längden, när man bara vill ha sina vardagssysslor undangjorda snabbast och lättast möjligt...

  • Medlem
  • 2003-03-09 01:09

Martin skrev:

Måste det vara så här? Är det bara jag som kräver GUI för allting? Är utvecklingen på väg bakåt - går utvecklingen mot en härlig C: prompt igen?

Malen skrev:

Den sk bildmänniska, en konstnär, en illustrator, en musiker vill nog ha en GUI att arbeta med och inte en terminal.

En MYCKET intressant och nödvändig diskussion tycker jag. Det är aningen tröttsamt med hyllningskören kring X. Självklart skall det vara GUI till allt!
(det var ju därför jag valde mac en gång?!?!)

Ska jag behöva traggla en massa tekniskt fikonspråk bara för att få datorn begriplig för att kunna göra musik på den - skillnaden mellan mac & pc krymper känns det som...

Och jag fullkomligt struntar i nätverksoptimerade fleranvändarsystem (det är ju bara jag som använder min dator?!?! Logga in? Que?) eller det stora fördelen med att kunna rippa mp3, surfa på nätet, bränna dvd, räkna i excel, klippa dv-film, och rendera tredimensionell långfilm SAMTIDIGT. Med bonusen att om något strular skall man skriva "hckh dh u sudo fck-y" i terminalen. Wow liksom, framtiden känns ljus.

Jag är väl gammaldags antar jag - men det jag använder datorn till (musik) då behöver jag inte göra 8 andra saker samtidigt. Turligt nog använder jag väldigt bra skrivna program, så mitt OS 9 kraschar bara om jag råkar använda Internet explorer ibland...

Priset för stabilitet och en väldig massa oh så imponerade ingenjörs-features är väldigt högt, tycker jag. Den där Mac-känslan försvann liksom. Känns trist att behöva tveka inför nästa stora uppgradering av min utrustning.

Tack och lov så är det mesta för musik-produktion ganska väl GUI-omhändertaget av Apple i Mac OS X, det är mer den ganska värdefulla allmänna skötseln av systemet jag bävar inför... (kanske skall man inte bry som om allt som skrivs, men X sköter väl sig knappast HELT själv?) - så därför: GUI på allt!

(eh......fast egentligen borde jag sluta negga överhuvudtaget, dra min slitna unkna OS 9-filt över mig och först bekymra mig när jag inte har nåt annat val att uppgradera på riktigt - X eller Windooze... Men jag antar att det blir lite upprört när ens "religon" tas ifrån en?

Men visst, jag får väl göra unix till min nya religon och bombardera forumet med frågor sedan....)

  • Oregistrerad
  • 2003-03-09 01:11

GUI är onekligen bekvämt i många situationer, men det gäller även för terminalen. När man väl har lärt sig använda den är den ett otroligt kraftfullt verktyg. Men då ett verktyg för en specifik typ av uppgifter, precis som Indesign och Finder är verktyg för att klara av sina respektive uppgifter.

Anledningen till att filer typ httpd.conf oftast manipuleras via terminalen eller något textprogram och inte genom GUI beror väl i mångt och mycket på att behovet av att kunna redigera den typen av filer snabbt via en telnetsession har varit större än behovet att redigera dem via ett GUI, eftersom de härstammar från unixvärlden.

Personligen tror jag dock att mer och mer kommer kunna styras via GUI. Då fler och fler filformat standardiseras runt tekniker som XML så blir det lättare för tredjepartstillverkare att bygga verktyg som kan manipulera andra programs data, vilket resulterar att desktopanvändare får större möjligheter att sköta den typen av uppgifter. Vilket i sin tur resulterar i att det kommer att skapas ett större sug efter GUI-program för terminaluppgifter, vilket då skapar en större marknad och därmed fler program av den typen.

Men terminalen kommer nog alltid att finnas kvar. För inget slår flexibiliteten i en snabb perl-oneliner

  • Medlem
  • 2003-03-09 11:48

jag anser mig vara en relativt avancerad användare av vissa program, men jag har aldrig gett mig in i terminalen, och jag längtar inte dit heller. Jag vill inte behöva kunna terminalen och radkommandon för att kunna utmana min dators prestanda. Länge leve GUI!

Detta är ett exempel på httpd_conf - den fil som man använder för att konfigurera webbservern.

För att ändra i den måste du först logga in som <root> och sedan använda en texteditor i terminalen.

#
# Based upon the NCSA server configuration files originally by Rob McCool.
#
# This is the main Apache server configuration file. It contains the
# configuration directives that give the server its instructions.
# See for detailed information about
# the directives.
#
# Do NOT simply read the instructions in here without understanding
# what they do. They´re here only as hints or reminders. If you are unsure
# consult the online docs. You have been warned.
#
# The configuration directives are grouped into three basic sections:
# 1. Directives that control the operation of the Apache server process as a
# whole (the ´global environment´).
# 2. Directives that define the parameters of the ´main´ or ´default´ server,
# which responds to requests that aren´t handled by a virtual host.
# These directives also provide default values for the settings
# of all virtual hosts.
# 3. Settings for virtual hosts, which allow Web requests to be sent to
# different IP addresses or hostnames and have them handled by the
# same Apache server process.
#
# Configuration and logfile names: If the filenames you specify for many
# of the server´s control files begin with "/" (or "drive:/" for Win32), the
# server will use that explicit path. If the filenames do *not* begin
# with "/", the value of ServerRoot is prepended -- so "logs/foo.log"
# with ServerRoot set to "/etc/httpd" will be interpreted by the
# server as "/etc/httpd/logs/foo.log".
#

### Section 1: Global Environment
#
# The directives in this section affect the overall operation of Apache,
# such as the number of concurrent requests it can handle or where it
# can find its configuration files.
#

#
# Don´t give away too much information about all the subcomponents
# we are running. Comment out this line if you don´t mind remote sites
# finding out what major optional modules you are running
ServerTokens OS

#
# ServerRoot: The top of the directory tree under which the server´s
# configuration, error, and log files are kept.
#
# NOTE! If you intend to place this on an NFS (or otherwise network)
# mounted filesystem then please read the LockFile documentation
# (available at );
# you will save yourself a lot of trouble.
#
# Do NOT add a slash at the end of the directory path.
#
ServerRoot "/etc/httpd"

#
# ScoreBoardFile: File used to store internal server process information.
# If unspecified (the default), the scoreboard will be stored in an
# anonymous shared memory segment, and will be unavailable to third-party
# applications.
# If specified, ensure that no two invocations of Apache share the same
# scoreboard file. The scoreboard file MUST BE STORED ON A LOCAL DISK.
#
#ScoreBoardFile run/httpd.scoreboard

#
# PidFile: The file in which the server should record its process
# identification number when it starts.
#
PidFile run/httpd.pid

#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 300

#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive Off

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 100

#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 15

##
## Server-Pool Size Regulation (MPM specific)
##

# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves

StartServers 8
MinSpareServers 5
MaxSpareServers 20
MaxClients 150
MaxRequestsPerChild 1000

# worker MPM
# StartServers: initial number of server processes to start
# MaxClients: maximum number of simultaneous client connections
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestsPerChild: maximum number of requests a server process serves

StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0

# perchild MPM
# NumServers: constant number of server processes
# StartThreads: initial number of worker threads in each server process
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# MaxThreadsPerChild: maximum number of worker threads in each server process
# MaxRequestsPerChild: maximum number of connections per server process

NumServers 5
StartThreads 5
MinSpareThreads 5
MaxSpareThreads 10
MaxThreadsPerChild 20
MaxRequestsPerChild 0

#
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, in addition to the default. See also the
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses (0.0.0.0)
#
#Listen 12.34.56.78:80
Listen 80

#
# Load config files from the config directory "/etc/httpd/conf.d".
#
Include conf.d/*.conf

#
# Dynamic Shared Object (DSO) Support
#
# To be able to use the functionality of a module which was built as a DSO you
# have to place corresponding `LoadModule´ lines at this location so the
# directives contained in it are actually available _before_ they are used.
# Statically compiled modules (those listed by `httpd -l´) do not need
# to be loaded here.
#
# Example:
# LoadModule foo_module modules/mod_foo.so
#
LoadModule access_module modules/mod_access.so
LoadModule auth_module modules/mod_auth.so
LoadModule auth_anon_module modules/mod_auth_anon.so
LoadModule auth_dbm_module modules/mod_auth_dbm.so
LoadModule auth_digest_module modules/mod_auth_digest.so
LoadModule include_module modules/mod_include.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule env_module modules/mod_env.so
LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule cern_meta_module modules/mod_cern_meta.so
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
LoadModule usertrack_module modules/mod_usertrack.so
LoadModule unique_id_module modules/mod_unique_id.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
LoadModule dav_module modules/mod_dav.so
LoadModule status_module modules/mod_status.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule asis_module modules/mod_asis.so
LoadModule info_module modules/mod_info.so
LoadModule cgi_module modules/mod_cgi.so
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
LoadModule imap_module modules/mod_imap.so
LoadModule actions_module modules/mod_actions.so
LoadModule speling_module modules/mod_speling.so
LoadModule userdir_module modules/mod_userdir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so

#
# ExtendedStatus controls whether Apache will generate "full" status
# information (ExtendedStatus On) or just basic information (ExtendedStatus
# Off) when the "server-status" handler is called. The default is Off.
#
#ExtendedStatus On

### Section 2: ´Main´ server configuration
#
# The directives in this section set up the values used by the ´main´
# server, which responds to any requests that aren´t handled by a
# definition. These values also provide defaults for
# any containers you may define later in the file.
#
# All of these directives may appear inside containers,
# in which case these default settings will be overridden for the
# virtual host being defined.
#

#
# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.
#
# User/Group: The name (or #number) of the user/group to run httpd as.
# . On SCO (ODT 3) use "User nouser" and "Group nogroup".
# . On HPUX you may not be able to use shared memory as nobody, and the
# suggested workaround is to create a user www and use that user.
# NOTE that some kernels refuse to setgid(Group) or semctl(IPC_SET)
# when the value of (unsigned)Group is above 60000;
# don´t use Group #-1 on these systems!
#
User apache
Group apache

#
# ServerAdmin: Your address, where problems with the server should be
# e-mailed. This address appears on some server-generated pages, such
# as error documents. e.g. [email protected]
#
ServerAdmin [email protected]

#
# ServerName gives the name and port that the server uses to identify itself.
# This can often be determined automatically, but we recommend you specify
# it explicitly to prevent problems during startup.
#
# If this is not set to valid DNS name for your host, server-generated
# redirections will not work. See also the UseCanonicalName directive.
#
# If your host doesn´t have a registered DNS name, enter its IP address here.
# You will have to access it by its address anyway, and this will make
# redirections work in a sensible way.
#
ServerName www.anatanodomain.jp

#
# UseCanonicalName: Determines how Apache constructs self-referencing
# URLs and the SERVER_NAME and SERVER_PORT variables.
# When set "Off", Apache will use the Hostname and Port supplied
# by the client. When set "On", Apache will use the value of the
# ServerName directive.
#
UseCanonicalName Off

#
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/var/www/html"

#
# Each directory to which Apache has access can be configured with respect
# to which services and features are allowed and/or disabled in that
# directory (and its subdirectories).
#
# First, we configure the "default" to be a very restrictive set of
# features.
#

Options FollowSymLinks
AllowOverride None

#
# Note that from this point forward you must specifically allow
# particular features to be enabled - so if something´s not working as
# you might expect, make sure that you have specifically enabled it
# below.
#

#
# This should be changed to whatever you set DocumentRoot to.
#

#
# Possible values for the Options directive are "None", "All",
# or any combination of:
# Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI Multiviews
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn´t give it to you.
#
# The Options directive is both complicated and important. Please see
# http://httpd.apache.org/docs-2.0/mod/core.html#options
# for more information.
#

# Options Indexes FollowSymLinks
Options INCLUDES FollowSymLinks

#
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
# Options FileInfo AuthConfig Limit
#
AllowOverride None

#
# Controls who can get stuff from this server.
#
Order allow,deny
Allow from all

#
# Disable autoindex for the root directory, and present a
# default Welcome page if no other index page is present.
#

#
# UserDir is disabled by default since it can confirm the presence
# of a username on the system (depending on home directory
# permissions).
#
UserDir disable

#
# To enable requests to /~user/ to serve the user´s public_html
# directory, remove the "UserDir disable" line above, and uncomment
# the following line instead:
#
#UserDir public_html

#
# Control access to UserDir directories. The following is an example
# for a site where these directories are restricted to read-only.
#
#
# AllowOverride FileInfo AuthConfig Limit
# Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
#
# Order allow,deny
# Allow from all
#
#
# Order deny,allow
# Deny from all
#
#

#
# DirectoryIndex: sets the file that Apache will serve if a directory
# is requested.
#
# The index.html.var file (a type-map) is used to deliver content-
# negotiated documents. The MultiViews Option can be used for the
# same purpose, but it is much slower.
#
DirectoryIndex index.html index.html.var index.shtml

#
# AccessFileName: The name of the file to look for in each directory
# for access control information. See also the AllowOverride directive.
#
AccessFileName .htaccess

#
# The following lines prevent .htaccess and .htpasswd files from being
# viewed by Web clients.
#

Order allow,deny
Deny from all

#
# TypesConfig describes where the mime.types file (or equivalent) is
# to be found.
#
TypesConfig /etc/mime.types

#
# DefaultType is the default MIME type the server will use for a document
# if it cannot otherwise determine one, such as from filename extensions.
# If your server contains mostly text or HTML documents, "text/plain" is
# a good value. If most of your content is binary, such as applications
# or images, you may want to use "application/octet-stream" instead to
# keep browsers from trying to display binary files as though they are
# text.
#
DefaultType text/plain

#
# The mod_mime_magic module allows the server to use various hints from the
# contents of the file itself to determine its type. The MIMEMagicFile
# directive tells the module where the hint definitions are located.
#

# MIMEMagicFile /usr/share/magic.mime
MIMEMagicFile conf/magic

#
# HostnameLookups: Log the names of clients or just their IP addresses
# e.g., www.apache.org (on) or 204.62.129.132 (off).
# The default is off because it´d be overall better for the net if people
# had to knowingly turn this feature on, since enabling it means that
# each client request will result in AT LEAST one lookup request to the
# nameserver.
#
HostnameLookups Off

#
# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a
# container, error messages relating to that virtual host will be
# logged here. If you *do* define an error logfile for a
# container, that host´s errors will be logged there and not here.
#
ErrorLog logs/error_log

#
# LogLevel: Control the number of messages logged to the error_log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel warn

#
# The following directives define some format nicknames for use with
# a CustomLog directive (see below).
#
LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined
LogFormat "%h %l %u %t "%r" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

#
# The location and format of the access logfile (Common Logfile Format).
# If you do not define any access logfiles within a
# container, they will be logged here. Contrariwise, if you *do*
# define per- access logfiles, transactions will be
# logged therein and *not* in this file.
#
# CustomLog logs/access_log common
CustomLog logs/access_log combined

#
# If you would like to have agent and referer logfiles, uncomment the
# following directives.
#
#CustomLog logs/referer_log referer
#CustomLog logs/agent_log agent

#
# If you prefer a single logfile with access, agent, and referer information
# (Combined Logfile Format) you can use the following directive.
#
#CustomLog logs/access_log combined

#
# Optionally add a line containing the server version and virtual host
# name to server-generated pages (error documents, FTP directory listings,
# mod_status and mod_info output etc., but not CGI generated documents).
# Set to "EMail" to also include a mailto: link to the ServerAdmin.
# Set to one of: On | Off | EMail
#
ServerSignature On

#
# Aliases: Add here as many aliases as you need (with no limit). The format is
# Alias fakename realname
#
# Note that if you include a trailing / on fakename then the server will
# require it to be present in the URL. So "/icons" isn´t aliased in this
# example, only "/icons/". If the fakename is slash-terminated, then the
# realname must also be slash terminated, and if the fakename omits the
# trailing slash, the realname must also omit it.
#
# We include the /icons/ alias for FancyIndexed directory listings. If you
# do not use FancyIndexing, you may comment this out.
#
Alias /icons/ "/var/www/icons/"

Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all

#
# This should be changed to the ServerRoot/manual/. The alias provides
# the manual, even if you choose to move your DocumentRoot. You may comment
# this out if you do not care for the documentation.
#
Alias /manual "/var/www/manual"

Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all

# Location of the WebDAV lock database.
DAVLockDB /var/lib/dav/lockdb

#
# ScriptAlias: This controls which directories contain server scripts.
# ScriptAliases are essentially the same as Aliases, except that
# documents in the realname directory are treated as applications and
# run by the server when requested rather than as documents sent to the client.
# The same rules about trailing "/" apply to ScriptAlias directives as to
# Alias.
#
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"

#
# Additional to mod_cgid.c settings, mod_cgid has Scriptsock
# for setting UNIX socket for communicating with cgid.
#
#Scriptsock logs/cgisock

#
# "/var/www/cgi-bin" should be changed to whatever your ScriptAliased
# CGI directory exists, if you have that configured.
#

AllowOverride None
Options None
Order allow,deny
Allow from all

#
# Redirect allows you to tell clients about documents which used to exist in
# your server´s namespace, but do not anymore. This allows you to tell the
# clients where to look for the relocated document.
# Example:
# Redirect permanent /foo http://www.example.com/bar

#
# Directives controlling the display of server-generated directory listings.
#

#
# FancyIndexing is whether you want fancy directory indexing or standard.
# VersionSort is whether files containing version numbers should be
# compared in the natural way, so that `apache-1.3.9.tar´ is placed before
# `apache-1.3.12.tar´.
#
IndexOptions FancyIndexing VersionSort NameWidth=*

#
# AddIcon* directives tell the server which icon to show for different
# files or filename extensions. These are only displayed for
# FancyIndexed directories.
#
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip

AddIconByType (TXT,/icons/text.gif) text/*
AddIconByType (IMG,/icons/image2.gif) image/*
AddIconByType (SND,/icons/sound2.gif) audio/*
AddIconByType (VID,/icons/movie.gif) video/*

AddIcon /icons/binary.gif .bin .exe
AddIcon /icons/binhex.gif .hqx
AddIcon /icons/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/uuencoded.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/tex.gif .tex
AddIcon /icons/bomb.gif core

AddIcon /icons/back.gif ..
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
AddIcon /icons/blank.gif ^^BLANKICON^^

#
# DefaultIcon is which icon to show for files which do not have an icon
# explicitly set.
#
DefaultIcon /icons/unknown.gif

#
# AddDescription allows you to place a short description after a file in
# server-generated indexes. These are only displayed for FancyIndexed
# directories.
# Format: AddDescription "description" filename
#
#AddDescription "GZIP compressed document" .gz
#AddDescription "tar archive" .tar
#AddDescription "GZIP compressed tar archive" .tgz

#
# ReadmeName is the name of the README file the server will look for by
# default, and append to directory listings.
#
# HeaderName is the name of a file which should be prepended to
# directory indexes.
ReadmeName README.html
HeaderName HEADER.html

#
# IndexIgnore is a set of filenames which directory indexing should ignore
# and not include in the listing. Shell-style wildcarding is permitted.
#
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

#
# AddEncoding allows you to have certain browsers (Mosaic/X 2.1+) uncompress
# information on the fly. Note: Not all browsers support this.
# Despite the name similarity, the following Add* directives have nothing
# to do with the FancyIndexing customization directives above.
#
AddEncoding x-compress Z
AddEncoding x-gzip gz tgz

#
# DefaultLanguage and AddLanguage allows you to specify the language of
# a document. You can then use content negotiation to give a browser a
# file in a language the user can understand.
#
# Specify a default language. This means that all data
# going out without a specific language tag (see below) will
# be marked with this one. You probably do NOT want to set
# this unless you are sure it is correct for all cases.
#
# * It is generally better to not mark a page as
# * being a certain language than marking it with the wrong
# * language!
#
# DefaultLanguage nl
#
# Note 1: The suffix does not have to be the same as the language
# keyword --- those with documents in Polish (whose net-standard
# language code is pl) may wish to use "AddLanguage pl .po" to
# avoid the ambiguity with the common suffix for perl scripts.
#
# Note 2: The example entries below illustrate that in some cases
# the two character ´Language´ abbreviation is not identical to
# the two character ´Country´ code for its country,
# E.g. ´Danmark/dk´ versus ´Danish/da´.
#
# Note 3: In the case of ´ltz´ we violate the RFC by using a three char
# specifier. There is ´work in progress´ to fix this and get
# the reference data for rfc1766 cleaned up.
#
# Danish (da) - Dutch (nl) - English (en) - Estonian (et)
# French (fr) - German (de) - Greek-Modern (el)
# Italian (it) - Norwegian (no) - Norwegian Nynorsk (nn) - Korean (kr)
# Portugese (pt) - Luxembourgeois* (ltz)
# Spanish (es) - Swedish (sv) - Catalan (ca) - Czech(cz)
# Polish (pl) - Brazilian Portuguese (pt-br) - Japanese (ja)
# Russian (ru) - Croatian (hr)
#
AddLanguage da .dk
AddLanguage nl .nl
AddLanguage en .en
AddLanguage et .et
AddLanguage fr .fr
AddLanguage de .de
AddLanguage he .he
AddLanguage el .el
AddLanguage it .it
AddLanguage ja .ja
AddLanguage pl .po
AddLanguage kr .kr
AddLanguage pt .pt
AddLanguage nn .nn
AddLanguage no .no
AddLanguage pt-br .pt-br
AddLanguage ltz .ltz
AddLanguage ca .ca
AddLanguage es .es
AddLanguage sv .se
AddLanguage cz .cz
AddLanguage ru .ru
AddLanguage tw .tw
AddLanguage zh-tw .tw
AddLanguage hr .hr

#
# LanguagePriority allows you to give precedence to some languages
# in case of a tie during content negotiation.
#
# Just list the languages in decreasing order of preference. We have
# more or less alphabetized them here. You probably want to change this.
#
LanguagePriority en da nl et fr de el it ja kr no pl pt pt-br ltz ca es sv tw

#
# ForceLanguagePriority allows you to serve a result page rather than
# MULTIPLE CHOICES (Prefer) [in case of a tie] or NOT ACCEPTABLE (Fallback)
# [in case no accepted languages matched the available variants]
#
ForceLanguagePriority Prefer Fallback

#
# Specify a default charset for all pages sent out. This is
# always a good idea and opens the door for future internationalisation
# of your web site, should you ever want it. Specifying it as
# a default does little harm; as the standard dictates that a page
# is in iso-8859-1 (latin1) unless specified otherwise i.e. you
# are merely stating the obvious. There are also some security
# reasons in browsers, related to javascript and URL parsing
# which encourage you to always set a default char set.
#
AddDefaultCharset ISO-8859-1

#
# Commonly used filename extensions to character sets. You probably
# want to avoid clashes with the language extensions, unless you
# are good at carefully testing your setup after each change.
# See ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets for
# the official list of charset names and their respective RFCs
#
AddCharset ISO-8859-1 .iso8859-1 .latin1
AddCharset ISO-8859-2 .iso8859-2 .latin2 .cen
AddCharset ISO-8859-3 .iso8859-3 .latin3
AddCharset ISO-8859-4 .iso8859-4 .latin4
AddCharset ISO-8859-5 .iso8859-5 .latin5 .cyr .iso-ru
AddCharset ISO-8859-6 .iso8859-6 .latin6 .arb
AddCharset ISO-8859-7 .iso8859-7 .latin7 .grk
AddCharset ISO-8859-8 .iso8859-8 .latin8 .heb
AddCharset ISO-8859-9 .iso8859-9 .latin9 .trk
AddCharset ISO-2022-JP .iso2022-jp .jis
AddCharset ISO-2022-KR .iso2022-kr .kis
AddCharset ISO-2022-CN .iso2022-cn .cis
AddCharset Big5 .Big5 .big5
# For russian, more than one charset is used (depends on client, mostly):
AddCharset WINDOWS-1251 .cp-1251 .win-1251
AddCharset CP866 .cp866
AddCharset KOI8-r .koi8-r .koi8-ru
AddCharset KOI8-ru .koi8-uk .ua
AddCharset ISO-10646-UCS-2 .ucs2
AddCharset ISO-10646-UCS-4 .ucs4
AddCharset UTF-8 .utf8

# The set below does not map to a specific (iso) standard
# but works on a fairly wide range of browsers. Note that
# capitalization actually matters (it should not, but it
# does for some browsers).
#
# See ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets
# for a list of sorts. But browsers support few.
#
AddCharset GB2312 .gb2312 .gb
AddCharset utf-7 .utf7
AddCharset utf-8 .utf8
AddCharset big5 .big5 .b5
AddCharset EUC-TW .euc-tw
AddCharset EUC-JP .euc-jp
AddCharset EUC-KR .euc-kr
AddCharset shift_jis .sjis

#
# AddType allows you to add to or override the MIME configuration
# file mime.types for specific file types.
#
AddType application/x-tar .tgz

#
# AddHandler allows you to map certain file extensions to "handlers":
# actions unrelated to filetype. These can be either built into the server
# or added with the Action directive (see below)
#
# To use CGI scripts outside of ScriptAliased directories:
# (You will also need to add "ExecCGI" to the "Options" directive.)
#
#AddHandler cgi-script .cgi

#
# For files that include their own HTTP headers:
#
#AddHandler send-as-is asis

#
# For server-parsed imagemap files:
#
AddHandler imap-file map

#
# For type maps (negotiated resources):
# (This is enabled by default to allow the Apache "It Worked" page
# to be distributed in multiple languages.)
#
AddHandler type-map var

# Filters allow you to process content before it is sent to the client.
#
# To parse .shtml files for server-side includes (SSI):
# (You will also need to add "Includes" to the "Options" directive.)
#
AddOutputFilter INCLUDES .shtml

#
# Action lets you define media types that will execute a script whenever
# a matching file is called. This eliminates the need for repeated URL
# pathnames for oft-used CGI file processors.
# Format: Action media/type /cgi-script/location
# Format: Action handler-name /cgi-script/location
#

#
# Customizable error responses come in three flavors:
# 1) plain text 2) local redirects 3) external redirects
#
# Some examples:
#ErrorDocument 500 "The server made a boo boo."
#ErrorDocument 404 /missing.html
#ErrorDocument 404 "/cgi-bin/missing_handler.pl"
#ErrorDocument 402 http://www.example.com/subscription_info.html
#

#
# Putting this all together, we can Internationalize error responses.
#
# We use Alias to redirect any /error/HTTP_.html.var response to
# our collection of by-error message multi-language collections. We use
# includes to substitute the appropriate text.
#
# You can modify the messages´ appearance without changing any of the
# default HTTP_.html.var files by adding the line;
#
# Alias /error/include/ "/your/include/path/"
#
# which allows you to create your own set of files by starting with the
# /var/www/error/include/ files and
# copying them to /your/include/path/, even on a per-VirtualHost basis.
#

Alias /error/ "/var/www/error/"

AllowOverride None
Options IncludesNoExec
AddOutputFilter Includes html
AddHandler type-map var
Order allow,deny
Allow from all
LanguagePriority en es de fr
ForceLanguagePriority Prefer Fallback

ErrorDocument 400 /error/HTTP_BAD_REQUEST.html.var
ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var
ErrorDocument 403 /error/HTTP_FORBIDDEN.html.var
ErrorDocument 404 /error/HTTP_NOT_FOUND.html.var
ErrorDocument 405 /error/HTTP_METHOD_NOT_ALLOWED.html.var
ErrorDocument 408 /error/HTTP_REQUEST_TIME_OUT.html.var
ErrorDocument 410 /error/HTTP_GONE.html.var
ErrorDocument 411 /error/HTTP_LENGTH_REQUIRED.html.var
ErrorDocument 412 /error/HTTP_PRECONDITION_FAILED.html.var
ErrorDocument 413 /error/HTTP_REQUEST_ENTITY_TOO_LARGE.html.var
ErrorDocument 414 /error/HTTP_REQUEST_URI_TOO_LARGE.html.var
ErrorDocument 415 /error/HTTP_SERVICE_UNAVAILABLE.html.var
ErrorDocument 500 /error/HTTP_INTERNAL_SERVER_ERROR.html.var
ErrorDocument 501 /error/HTTP_NOT_IMPLEMENTED.html.var
ErrorDocument 502 /error/HTTP_BAD_GATEWAY.html.var
ErrorDocument 503 /error/HTTP_SERVICE_UNAVAILABLE.html.var
ErrorDocument 506 /error/HTTP_VARIANT_ALSO_VARIES.html.var

#
# The following directives modify normal HTTP response behavior to
# handle known problems with browser implementations.
#
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4.0b2;" nokeepalive downgrade-1.0 force-response-1.0
BrowserMatch "RealPlayer 4.0" force-response-1.0
BrowserMatch "Java/1.0" force-response-1.0
BrowserMatch "JDK/1.0" force-response-1.0

#
# The following directive disables redirects on non-GET requests for
# a directory that does not include the trailing slash. This fixes a
# problem with Microsoft WebFolders which does not appropriately handle
# redirects for folders with DAV methods.
#
BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully
BrowserMatch "^WebDrive" redirect-carefully

#
# Allow server status reports, with the URL of http://servername/server-status
# Change the ".your-domain.com" to match your domain to enable.
#
#
# SetHandler server-status
# Order deny,allow
# Deny from all
# Allow from .your-domain.com
#

#
# Allow remote server configuration reports, with the URL of
# http://servername/server-info (requires that mod_info.c be loaded).
# Change the ".your-domain.com" to match your domain to enable.
#
#
# SetHandler server-info
# Order deny,allow
# Deny from all
# Allow from .your-domain.com
#

#
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
#
#ProxyRequests On
#
#
# Order deny,allow
# Deny from all
# Allow from .your-domain.com
#

#
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server version; "Block" removes all outgoing Via: headers)
# Set to one of: Off | On | Full | Block
#
#ProxyVia On

#
# To enable the cache as well, edit and uncomment the following lines:
# (no cacheing without CacheRoot)
#
#CacheRoot "/etc/httpd/proxy"
#CacheSize 5
#CacheGcInterval 4
#CacheMaxExpire 24
#CacheLastModifiedFactor 0.1
#CacheDefaultExpire 1
#NoCache a-domain.com another-domain.edu joes.garage-sale.com

#
# End of proxy directives.

### Section 3: Virtual Hosts
#
# VirtualHost: If you want to maintain multiple domains/hostnames on your
# machine you can setup VirtualHost containers for them. Most configurations
# use only name-based virtual hosts so the server doesn´t need to worry about
# IP addresses. This is indicated by the asterisks in the directives below.
#
# Please see the documentation at
#
# for further details before you try to setup virtual hosts.
#
# You may use the command line option ´-S´ to verify your virtual host
# configuration.

#
# Use name-based virtual hosting.
#
#NameVirtualHost *

#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for requests without a known
# server name.
#
#
# ServerAdmin [email protected]
# DocumentRoot /www/docs/dummy-host.example.com
# ServerName dummy-host.example.com
# ErrorLog logs/dummy-host.example.com-error_log
# CustomLog logs/dummy-host.example.com-access_log common
#

Visst önskar jag mig GUI till allt. Jag tror också att det kommer. Som det är nu finns det tredjeparts applikationer som sköter det mesta man annars får göra via terminalen.
Apple har bra inte hunnit med, skulle vi ha väntat på OS X tills de byggt GUI till allt? Då hade inte OS X varit släppt ännu skulle jag tro.
Jag hoppas ni läst Tomas Ytterbergs senaste krönika i Macworld "Macen - Unix 1-0". Den säger nästan precis det jag tycker.

Men att racka ner på OS X för att de saknar vissa GUI tillämpningar tycker jag är fel. Den vanlige användern behöver sällan om ens aldrig använda sig av terminalen.
Men som tekniker för att felsöka datorn är den helt underbar. Jag kan verkligen in i minsta detalj ta reda på vad som hänt via logg-filer. Precis som min kollegor PC teknikerna gör.

Sedan kan jag bara hålla med om att OS X Server har en bit kvar. Än så länge är det skoj att jobba i terminalen där med. Så länge jag slipper ändra BIND inställningar för ofta.

[ 09. mars 2003, 13:04: Meddelandet ändrat av: Mattias Hedman ]

  • Medlem
  • Gävle
  • 2003-03-09 13:28

Jag jobbar mycket i Mac OS X server 10.2 och visst har den blivit bättre sen 10.2. Särkilt WorkgroupManager är ju helt underbar, lite slö bara.
Men det finns ju 200 till funktioner som jag skulle vilja kunna konfigurera. Ta bara FTP-servern, konfigureringen i den är ju rena skämtet.

För att inte tala om handboken som ALDRIG innehåller dom förklaringar jag vill ha.

  • Medlem
  • Hammarö
  • 2003-03-09 17:18

Klart det ska finnas GUI till alla funktioner i OSX Server. Annars finns det ju ingen som helst anledning att köpa OSX när man kan installera Debian eller FreeBSD istället. Om man i grunden har UNIX. Vad ska man då satsa på för att urskilja sig från mängden? Lättanvänt och fungerande GUI. Inget av detta är något skrivbord i GNU/Linux och *BSD, inte så att man kan skryta med det i alla fall.

Citat:

citera:Skapades ursprungligen av: Puppet:
Klart det ska finnas GUI till alla funktioner i OSX Server.

Jag håller i princip med. Till dess att jobbet är gjort kan vi alltid förlita oss på tredjepartstillverkare.

GUI bör finnas för dem som vill använda det, och självklart för CLI finnas kvar för dem som vill använda det.

Personligen föredrar jag CLI för många saker, vet man vad som ska göras så (tycker jag) går det snabbare eftersom man aldrig ens behöver lyfta fingrarna från tangentbordet.

  • Medlem
  • Stockholm
  • 2003-03-10 11:53

Det grafiska gränssnittet är väl själva kärnan i Macintosh. Utan ett grafiskt gränssnitt är det ingen Mac.

Kommandoraden är nog bra men bör hållas väl dold.

Som sagt, man ska inte behöva använda CLI om man inte vill.

Citat:

citera:Skapades ursprungligen av: Martin Björnström:
För att ändra i den måste du först logga in som <root> och sedan använda en texteditor i terminalen.

Ett tips i all välmening: skriv sudo framför kommandot (i det här fallet texteditor typ emacs) så räcker det att du är inloggad som en vanlig user med administrationsrättigheter. Du får då tillfällig root-access även om du inte aktiverat rootkontot.

  • Medlem
  • 2003-03-19 03:07

Se där!
Där lärde jag mig nått nytt. Tack för det scooterbabe!

/Erik

  • Medlem
  • Hemmesdynge
  • 2003-03-19 09:17

Det finns en _stor_ fördel med att spara alla inställningar i textfiler som sedan kan manipuleras med en texteditor via telnet.

Ta Win2k som exempel. Var finns AD-informationen? Var ligger informationen om alla dina domäner till webservern? Jo: i binära filer som endast Microsoft vet hur man manipulerar.

Jag har tappat en hel domän med 100-tals användare och datorkonton på grund av en trasig hårddisk. Att det mesta av informationen var intakt spelade ingen roll, för jag kunde ju inte extrahera någon som helst information från M$ binärfiler.

I fallet X-server ligger informationen till största del i textfiler som man kan extrahera information ur även om filerna skadats delvis. DET är en fördel.

Sen ska man inte underskatta sådana enkla verktyg som grep och awk. Att tröska loggar på en windows-burk är ju rena tortyren i jämförelse med att "greppa" i de rena textfiler som finns i Uni*x.

Exempel: Jag skapar konton till kanske 100 studenter varje termin. I windows innebär det en massa knappande och plitande. I Uni*x kan jag få en textfil med en utskrift ur LADOK innehållande registrerade studenter. Sen skapar jag användare genom att köra den textfilen genom ett script med awk och grep och dessutom ge dem slumpade lösenord och sen skriva ut en ansvarsförbindelse till var och en av dem med namn, användarnamn och lösenord, allt i ett och samma kommando!
Numera är det nog möjligt på windows om man är en guru på VB eller så, men det är absolut inte lika lätt som under Un*x! Dessutom är det en "piece of cake" att flytta dessa användare och deras filer till en helt annan Un*x-dialekt. Du kan skriva ut din konf-filer och dem på papper för framtida referens... man kan fortsätta hur länge som helst.

Visst är det kul med GUI med det kan också vara _väldigt_ farligt. Iom att W2k är så "enkelt" att installera så gör folk det, många gånger utan att veta ett skvatt om vad de gör. Därav alla dessa ämlans virus och maskar. Jag har sett w2kserver-installationer som blev drabbade av Nimda/Code Red där administratören inte ens _visste_ att IIS rullade i bakgrunden. Och hur kunde det komma sig att den här masken som angrep MS-SQL-server kunde göra sådan skada när buggfixen var 6 månader gammal? Jo, troligen därför att det fanns mängder med admins som inte visste att deras burk körde SQL-server!

Inget system är resistent mot klantiga admins, men w2k har som standardpolicy allt på medans de flesta (moderna) Uni*x har allt av (se OSX t.ex.). Det minimerar lite av risken.

Visst kan man tycka at maccen har blivit mindre maccig med ett CLI, men det är ju också det som har gjort att vi har fått så många switchers. Dessutom har ju faktiskt maccen äntligen fått ett system som håller för framtiden.

Oj, detta blev långt...

Edit: fingrar som är snabbare än tanken, eller var det tvärtom?

[ 19. mars 2003, 09:21: Meddelandet ändrat av: bollman ]

Sen ska man inte underskatta sådana enkla verktyg som grep och awk. Att tröska loggar på en windows-burk är ju rena tortyren i jämförelse med att "greppa" i de rena textfiler som finns i Uni*x.

Windows 2000 har ju rena textloggar? Hur menar du?

Iom att W2k är så "enkelt" att installera så gör folk det, många gånger utan att veta ett skvatt om vad de gör. Därav alla dessa ämlans virus och maskar.

Det kan väl inte vara ett självändamål att göra ett knepigt OS så att man håller borta alla nybörjare?

Jag har fem servrar idag och har jobbat med drift av olika tjänster sedan tre år tillbaka. På servrarna driver vi uppemot 30 domäner och alla typer av tjänster vi behöver (DNS:er, FTP, MySQL, SQL2000, Backup, loganalys, mailservrar osv).

Trots det känner jag mig alldeles för "grön" för att ge mig in i Unix/Linux världen.

Det är lite sånt jag också kan känna när man kört windows och de blir mer påtagligt för varje ny version som microsoft kommer med.

Verkar som att dom utgår ifrån att man är en jubelidiot och inte kan eller ens kan lära sig nånting. Allt skall vara stort och blaffigt och överallt så man riktigt "ser" de, och sen ska vi ha hjälpredor till allting som skulle gå fortare utan.

Detta stör mig enormt när jag vill veta vad som händer på min dator och ha kontroll äver vad jag gör.

  • Medlem
  • Lund
  • 2003-03-19 10:19

GUI till allt. Det tycker jag. Skulle nästan vara intressant med en omröstning i ämnet...

GUI om det finns, men hellre CLI än ingenting (eller att sitta och vänta tills någon skapar ett GUI).

Bevaka tråden