Go Back   Winamp & Shoutcast Forums > Community Center > Breaking News

Reply
Thread Tools Search this Thread Display Modes
Old 2nd March 2005, 22:00   #321
fwgx
Rudolf the Red.
(Forum King)
 
fwgx's Avatar
 
Join Date: Nov 2000
Posts: 9,314
Quote:
Originally posted by spiderbaby1958
The simpler a gui interface is, the less flexible and powerful, and the more clicking you have to do to accomplish a task. When you know how to use the command line, you can cut through a lot of gui "red tape".
Not so. You only have to look as far as MS products to see that they are the masters of flexable, powerful GUI design. Stating "more clicking" as a bad thing compared with remembering abstract commands off by heart and actually having to type them out exactly, precisly and without error in full sounds a bit scewed. I have yet to see any problem that cannot be implemented well in a GUI, now it may not have been but that's not the point when arguing against GUIs in general. Now I'll hapily argue that Linux is a terrible OS when it comes to it's developers creating decent GUIs. They are badly designed, inconsistent, confusing, non-intuitive and many many many other bad things that anyone that knows anything about GUI design could spot in less than 10 mins of using the system.

Having no GUI means there is no choice on what to use and is a close minded, isolationist and elitist position to take.

.: fwgx.co.uk.:.My art:.

"We think science is interesting and if you disagree, you can fuck off."
fwgx is offline   Reply With Quote
Old 3rd March 2005, 14:58   #322
xzxzzx
Forum King
 
xzxzzx's Avatar
 
Join Date: Aug 2002
Posts: 7,254
Phily, while I agree that it is possible to make a powerful and simple GUI interface, you simply can't match the power of a bash shell (without some fundamental changes to how GUIs operate).

For example, can you explain how to do something like:

1) With case sensitivity, find all files with the word "mouse" in them.
2) In those files, if they have at least 1 instance of the word "elite" in them, change "elite" to "1337", and "owned" to "pwned".

All one really needs to remember here is the name of appropriate commands to do something like this. First, to find the appropriate files, "find". I do "find --help", and get:
code:
legolas root # find --help
Usage: find [path...] [expression]
default path is the current directory; default expression is -print
expression may consist of:
operators (decreasing precedence; -and is implicit where no others are given):
( EXPR ) ! EXPR -not EXPR EXPR1 -a EXPR2 EXPR1 -and EXPR2

EXPR1 -o EXPR2 EXPR1 -or EXPR2 EXPR1 , EXPR2
options (always true): -daystart -depth -follow --help
-maxdepth LEVELS -mindepth LEVELS -mount -noleaf --version -xdev
tests (N can be +N or -N or N): -amin N -anewer FILE -atime N -cmin N

-cnewer FILE -ctime N -empty -false -fstype TYPE -gid N -group NAME
-ilname PATTERN -iname PATTERN -inum N -ipath PATTERN -iregex PATTERN
-links N -lname PATTERN -mmin N -mtime N -name PATTERN -newer FILE

-nouser -nogroup -path PATTERN -perm [+-]MODE -regex PATTERN
-size N[bckw] -true -type [bcdpfls] -uid N -used N -user NAME
-xtype [bcdpfls]

actions: -exec COMMAND ; -fprint FILE -fprint0 FILE -fprintf FILE FORMAT
-ok COMMAND ; -print -print0 -printf FORMAT -prune -ls


Report bugs to <bug-findutils@gnu.org>.



Ok, so our command will be something like:

code:
find /tmp/1337/ -name mouse -exec (do something)\;


Now, I need to make sure there is an instance of "elite" in the files. "grep" should fit the bill:
code:
legolas root # grep --help
Usage: grep [OPTION]... PATTERN [FILE] ...
Search for PATTERN in each FILE or standard input.
Example: grep -i 'hello world' menu.h main.c

Regexp selection and interpretation:
-E, --extended-regexp PATTERN is an extended regular expression
-F, --fixed-strings PATTERN is a set of newline-separated strings
-G, --basic-regexp PATTERN is a basic regular expression
-P, --perl-regexp PATTERN is a Perl regular expression
-e, --regexp=PATTERN use PATTERN as a regular expression
-f, --file=FILE obtain PATTERN from FILE
-i, --ignore-case ignore case distinctions
-w, --word-regexp force PATTERN to match only whole words
-x, --line-regexp force PATTERN to match only whole lines
-z, --null-data a data line ends in 0 byte, not newline

Miscellaneous:
-s, --no-messages suppress error messages
-v, --invert-match select non-matching lines
-V, --version print version information and exit
--help display this help and exit
--mmap use memory-mapped input if possible

Output control:
-m, --max-count=NUM stop after NUM matches
-b, --byte-offset print the byte offset with output lines
-n, --line-number print line number with output lines
--line-buffered flush output on every line
-H, --with-filename print the filename for each match
-h, --no-filename suppress the prefixing filename on output
--label=LABEL print LABEL as filename for standard input
-o, --only-matching show only the part of a line matching PATTERN
-q, --quiet, --silent suppress all normal output
--binary-files=TYPE assume that binary files are TYPE
TYPE is 'binary', 'text', or 'without-match'
-a, --text equivalent to --binary-files=text
-I equivalent to --binary-files=without-match
-d, --directories=ACTION how to handle directories
ACTION is 'read', 'recurse', or 'skip'
-D, --devices=ACTION how to handle devices, FIFOs and sockets
ACTION is 'read' or 'skip'
-R, -r, --recursive equivalent to --directories=recurse
--include=PATTERN files that match PATTERN will be examined
--exclude=PATTERN files that match PATTERN will be skipped.
--exclude-from=FILE files that match PATTERN in FILE will be skipped.
-L, --files-without-match only print FILE names containing no match
-l, --files-with-matches only print FILE names containing matches
-c, --count only print a count of matching lines per FILE
-Z, --null print 0 byte after FILE name

Context control:
-B, --before-context=NUM print NUM lines of leading context
-A, --after-context=NUM print NUM lines of trailing context
-C, --context=NUM print NUM lines of output context
-NUM same as --context=NUM
--color[=WHEN],
--colour[=WHEN] use markers to distinguish the matching string
WHEN may be `always', `never' or `auto'.
-U, --binary do not strip CR characters at EOL (MSDOS)
-u, --unix-byte-offsets report offsets as if CRs were not there (MSDOS)

`egrep' means `grep -E'. `fgrep' means `grep -F'.
With no FILE, or when FILE is -, read standard input. If less than
two FILEs given, assume -h. Exit status is 0 if match, 1 if no match,
and 2 if trouble.

Report bugs to <bug-gnu-utils@gnu.org>.



So:

code:
find /tmp/1337/ -name mouse -exec grep elite {} \;


Now for the replace. I'll use sed (this one you just have to know, though it's easily found with a Google search):

code:
find /tmp/1337/ -name mouse -exec grep elite {} \;
-exec sed 's/elite/1337/g' {}\; -exec sed 's/owned/pwned/g' {}\;

(broken into two lines for the forum's sake)

Yes, this is more cryptic than using a GUI, but you'd just be opening the second file in Windows when I hit "enter", assuming I didn't know the syntax offhand anyway (which, for this simple of a command, I do). The point is that while a GUI becomes slightly more powerful over use via familiarity, a command line becomes vastly, vastly more powerful.

Can you envision a GUI producing this kind of flexibility and power? I can't. Not without some sort of major shift in GUI style. What's really missing is stdin and stdout. Different GUI pieces don't fit together.

I don't, however, particularly disagree with you on any point you made Phily, as when considering the average user, this would be totally unworkable, and you're right, linux GUIs have a long way to go (I'm pretty familiar with GUI design myself - I've read GUI design books for fun ).

Freedom of speech is the basic freedom of humanity. When you've lost that, you've lost everything.
1\/\/4y 34|<$p4y 1gp4y 33714y, 0d4y 0uy4y? | Roses are #FF0000; Violets are #0000FF; chown -R ${YOU} ~/base
The DMCA. It really is that bad. : Count for your life.
xzxzzx is offline   Reply With Quote
Old 3rd March 2005, 18:07   #323
zootm
Forum King
 
zootm's Avatar
 
Join Date: Jan 2002
Location: the nether reaches of bonnie scotland
Posts: 13,375
GUI interfaces can be made modular and powerful, but yes, text-based ones are very good for combining. The reason for this is simple - streaming. They're text interfaces, they take in and give out text. It's simple to make them parse things because of this. It's just completely pointless for the average user.

Incidentally, although I know a few GUI-based tools that it's possible to do your task in, it would require the use of text-based tools, which kinda defies the point. For the sake of finding a quick GUI-based solution, though, using the tool jEdit you could make a GUI-based solution, the only part of which where text-based stuff is needed is a BeanShell macro to close all buffers not containing "elite". It wouldn't be any more complex than using the text tools.

The point is, though, for 99% of uses of computers, this sort of nonsense is completely unnecessary. And it's not like bash and these tools aren't available for every modern computer platform (I used to code on Linux exclusively, but since I started using Cygwin there's no actual difference).

zootm is offline   Reply With Quote
Old 3rd March 2005, 19:28   #324
fwgx
Rudolf the Red.
(Forum King)
 
fwgx's Avatar
 
Join Date: Nov 2000
Posts: 9,314
Depending on how many files you're expecting to change I would use the "find in files" option in something like EmEdit to get a list of files and then click on the file in the list to open it and then use the replace command. Simple.

Although I see your point, I don't think people in general spend their days editing pure text files. Heck, I do and I extremely rarely come up against anything I can't do in a GUI or with a recorded macro in VS6. And more often than not it is quicker to do it all manually instead of read the help file for one command, try and find out a crypticly named utility that does what you want. Learn to use it, pipe it into something else and, yadda yadda yadda.

I can see GUIs doing just that kind of thing very well. You just have to create a workflow program that groups all programs into categories such as text editing, graphics etc. You drag and drop programs onto the workbench, connect up flow lines, add some filters and conditional logic and you're done.

.: fwgx.co.uk.:.My art:.

"We think science is interesting and if you disagree, you can fuck off."
fwgx is offline   Reply With Quote
Old 4th March 2005, 12:44   #325
zootm
Forum King
 
zootm's Avatar
 
Join Date: Jan 2002
Location: the nether reaches of bonnie scotland
Posts: 13,375
See, that's an interesting concept, Phily, I was wondering if that would work. The main problem is that all the different programs have non-homogeneous modes of dispatch, so it'd be hard (without command-line switches for said GUI tools ).

zootm is offline   Reply With Quote
Old 4th March 2005, 23:01   #326
xzxzzx
Forum King
 
xzxzzx's Avatar
 
Join Date: Aug 2002
Posts: 7,254
Quote:
Originally posted by Phily Baby
I can see GUIs doing just that kind of thing very well. You just have to create a workflow program that groups all programs into categories such as text editing, graphics etc. You drag and drop programs onto the workbench, connect up flow lines, add some filters and conditional logic and you're done.
This is the kind of thought I was trying to stimulate.

Still, while my example may be artificial, it is an example that could be far more easily accomplished with a text interface. Regexes are my best friends. Recently, I had to handle a mail server that was misconfigured and acting as an open relay - I decided that I'd get rid of the email that was in the outgoing queue that had come from the relatively few other servers on the net that had discovered this one.

It was easily done with a find command:

code:
find /var/qmail/queue/mess/ -exec grep "^Received:.*(spammer's ip)" {} \;
-print -exec ~/mymessagedeletescript.sh \;



I'm sure there are GUI-based tools available that would perform something like this, but I doubt there are any that would easily allow me to tweak my command. For example:

code:
find /var/qmail/queue/mess/ -exec grep "^Received:.*(spammer's ip)" {} \; -or
-exec grep "^Subject: WANT A BIG PEN[I1]S. CL[I1]CK HERE" {} \;
-print -exec ~/mymessagedeletescript.sh \;


etc...

While I understand your point about cryptic commands, Phily, you should see a competent Unix administrator who's been using those commands for a while. It's fucking magic.

Plus, it looks really good to your boss who has no idea what those strange things on your screen are, and is amazed at your fingers flying over the keyboard and your comprehension speed as you use auto-complete and are only reading the one relevant piece of data from a list of 50 .

Efficiency brings on a whole new meaning. Want the PID/image name for the program that's listening on port 80?

code:
legolas root # netstat -tlnp | grep ":80"
tcp 0 0 0.0.0.0:80
0.0.0.0:* LISTEN 2661/apache2



How many lines of code are in my project's .txt files, anyway?
code:
legolas source # find -name "*.txt" -print0 | xargs -0 cat | wc -l
2961



Hmm, that seems high. What if I don't count blank lines?

code:
legolas source # find -name "*.txt" -print0 | \
xargs -0 cat | grep --invert-match "^ *$" | wc -l
2863



That's better. By the way, if the file names didn't include spaces or wierd symbols (like a file named "bl*ah.txt"), the commands would be more like:

code:
find -name "*.txt" | xargs cat | wc -l

and if you didn't have too many .txt files to overwhelm your shell (253?), you could do:

code:
wc -l `find -name "*.txt"`


As for:
Quote:
Originally posted by Phily Baby
And more often than not it is quicker to do it all manually instead of read the help file for one command, try and find out a crypticly named utility that does what you want. Learn to use it, pipe it into something else and, yadda yadda yadda.
You're right, it's often faster the first time, and the second time, and even maybe the third time, but there eventually comes a point where you're less productive than if you'd lost the time learning. And it's not like these commands have exactly precise applications - once you've learnt how to use grep, or find (not to mention sed or awk)...

I used to view unix commands as I believe you do, that they're cryptic commands with limited use, and that it takes huge investments of time before you get any use at all out of them. It's not true, though - learning just a few commands, you have amazing power at your fingertips. It's not a mistake, these commands have been around for a very very long time in the Unix world.

Freedom of speech is the basic freedom of humanity. When you've lost that, you've lost everything.
1\/\/4y 34|<$p4y 1gp4y 33714y, 0d4y 0uy4y? | Roses are #FF0000; Violets are #0000FF; chown -R ${YOU} ~/base
The DMCA. It really is that bad. : Count for your life.
xzxzzx is offline   Reply With Quote
Old 5th March 2005, 02:17   #327
zootm
Forum King
 
zootm's Avatar
 
Join Date: Jan 2002
Location: the nether reaches of bonnie scotland
Posts: 13,375
The thing about UNIX commands is that they fit in with the UNIX paradigm - everything's a file, files are usually text. It works so well by design. The reason they're useful is because people decided to design things so that tools like that would be useful, if that makes sense.

The commands tend to be less useful on Windows because configuration and so on simply isn't stored as plaintext, and the "everything's a file" paradigm isn't used (since it has less meaning in a GUI setting). It's just design choices.

zootm is offline   Reply With Quote
Old 5th March 2005, 08:28   #328
whiteflip
Post Master General
(Forum King)
 
whiteflip's Avatar
 
Join Date: Jun 2000
Location: Seattle, Now Las Vegas
Posts: 6,032
Quote:
Originally posted by zootm
The thing about UNIX commands is that they fit in with the UNIX paradigm - everything's a file, files are usually text. It works so well by design. The reason they're useful is because people decided to design things so that tools like that would be useful, if that makes sense.

The commands tend to be less useful on Windows because configuration and so on simply isn't stored as plaintext, and the "everything's a file" paradigm isn't used (since it has less meaning in a GUI setting). It's just design choices.
Damn Regsitry. Whats so wrong with ini files anyway?

I'm Back?
whiteflip is offline   Reply With Quote
Old 5th March 2005, 14:54   #329
zootm
Forum King
 
zootm's Avatar
 
Join Date: Jan 2002
Location: the nether reaches of bonnie scotland
Posts: 13,375
What's wrong with the registry? It's as organised as .ini files are... The only real problem is cross-platform compatibility.

I used to be convinced by the "single point of failure" angle, but then I realised that ~/.* is basically the same as the single-user registry. I believe GNOME has its own registry-like construct now?

zootm is offline   Reply With Quote
Old 5th March 2005, 20:46   #330
fwgx
Rudolf the Red.
(Forum King)
 
fwgx's Avatar
 
Join Date: Nov 2000
Posts: 9,314
There's no reason that the registry can't be distributed and simply backed up to a remote domain server or something. I like the registry as an idea, it's much more preferable to flat files imho. I do LOVE the idea of a SQL based OS though. Now with that you get power, simplicity and security. I so hope MS get it to work mmmmmmm.

.: fwgx.co.uk.:.My art:.

"We think science is interesting and if you disagree, you can fuck off."
fwgx is offline   Reply With Quote
Old 6th March 2005, 19:13   #331
zootm
Forum King
 
zootm's Avatar
 
Join Date: Jan 2002
Location: the nether reaches of bonnie scotland
Posts: 13,375
WinFS isn't going into Longhorn (well, not relationally-based, anyway) any more, apparently. Bit of a bummer, really.

I'm not sure if SQL would really be sufficient for a filesystem, it's quite limited (with the exception of the theoretical, unsupported flavours). RDF seems more relevant (although I think it might be slower).

zootm is offline   Reply With Quote
Old 8th March 2005, 16:22   #332
xzxzzx
Forum King
 
xzxzzx's Avatar
 
Join Date: Aug 2002
Posts: 7,254
Quote:
Originally posted by zootm
What's wrong with the registry? It's as organised as .ini files are... The only real problem is cross-platform compatibility.

I used to be convinced by the "single point of failure" angle, but then I realised that ~/.* is basically the same as the single-user registry. I believe GNOME has its own registry-like construct now?
Ever tried editing the registry of a non-bootable Windows install? How many helpful comments have you seen in the registry? Backup of /etc/ (cp -r /etc/ /mybackup/) is a hell of a whole lot easier than backing up the registry (and a hell of a whole lot more complete in terms of machine-wide configuration).

It's also easier to tar /etc/apache/ and email it than to find the relevant registry entr(ies) and then export them. On top of all that, registry entries are often not the only place an application stores data - it's far more common to have a pointer in the registry to a configuration file when there is any complexity at all in the configuration.

The only advantage to the registry is that it's easier to change on-the-fly (in memory), so applications can often be reconfigured immediately (no restart), though since you're rarely actually changing the registry through anything but a software-specific GUI anyway, it's more of a software design issue than anything to do with the registry.

Flat files are significantly closer to writing a script (and many of them actually are scripts) to configure something, so you get useful things like the ability to include other files, to comment out sections in a standard and easily understood way (try that in the registry), to note WHY a particular setting is a certain way, to do useful things like take a setting from a remote machine, automagically.

And I'm not making this up. From Microsoft's website regaurding the registry:
Quote:
The registry can take up a large amount of space, and a very large registry can slow the overall system performance. So to save space, you should minimize the number of keys because a key consumes more space than a simpler entry. If you need to store a logically related group of data, you should figure out a way to describe them in as flat a structure as possible and use as many entries as possible.
and
Quote:
For all these reasons, and to improve the overall efficiency, the Windows 2000 Application Specification reduces the circumstances in which you need to use the registry. The specification suggests that you use files instead of entries when the amount of data is larger than 2KB.
So even Microsoft pushes toward using flat-as-possible structures and files instead of registry entries (for over 2KB).

Quote:
Originally posted by Phily Baby
There's no reason that the registry can't be distributed and simply backed up to a remote domain server or something. I like the registry as an idea, it's much more preferable to flat files imho. I do LOVE the idea of a SQL based OS though. Now with that you get power, simplicity and security. I so hope MS get it to work mmmmmmm.
There's no reason that /etc/ (and any other part of a linux machine - kernel excluded?) can't be distributed and simply backed up to a remote server or something. I like flat files as an idea, they're infinately more reliable. I do LOVE the idea of a flat-file based OS. With that, you get power, simplicity, security, and reliability. I so hope no one tries to replace it with needless complexity.

Freedom of speech is the basic freedom of humanity. When you've lost that, you've lost everything.
1\/\/4y 34|<$p4y 1gp4y 33714y, 0d4y 0uy4y? | Roses are #FF0000; Violets are #0000FF; chown -R ${YOU} ~/base
The DMCA. It really is that bad. : Count for your life.
xzxzzx is offline   Reply With Quote
Old 8th March 2005, 16:38   #333
shakey_snake
Forum Domo
 
shakey_snake's Avatar
 
Join Date: Jan 2004
Location: Everyone, get over here for the picture!
Posts: 4,313
Quote:
Originally posted by zootm
WinFS isn't going into Longhorn (well, not relationally-based, anyway) any more, apparently. Bit of a bummer, really.
DMR'ed replica of XP coming right up!


elevatorladyelevatorladyelevatorladyelevatorladyelevatorladylevitateme
shakey_snake is offline   Reply With Quote
Old 9th March 2005, 02:47   #334
zootm
Forum King
 
zootm's Avatar
 
Join Date: Jan 2002
Location: the nether reaches of bonnie scotland
Posts: 13,375
xzxzzx - for my exact feelings on the subject of registries and so on, please see here* and the subposts thereof. I know that's a copout, but I can imagine it will save a lot of time in the long term.

Secondly, the pro-registry arguments you cite are all from Microsoft (which obviously makes sense, but do you have a good reason for a single, easily-recognised repository of setting data? I'm aware that it's more "efficient", but it's not a significant loss in 99.999% of cases, particularly in context. My argument isn't for The Windows Registry, it's for a registry-like data store which would standardise settings information to a degree. Please argue against that and not the Windows registry. I'd be very interested to hear your views in particular, and anyone's views in general, of this sort of stuff.

* The resolution of which was '...it will be interesting to see if you dev types can make us bitchy admin types happy with what just might be a not bad idea. Till then "worse is better".' from the remarkably nice-to-deal-with opponent to my ideas

zootm is offline   Reply With Quote
Old 12th March 2005, 04:52   #335
xzxzzx
Forum King
 
xzxzzx's Avatar
 
Join Date: Aug 2002
Posts: 7,254
Sorry for my absence. To quote one of my favorite design quotes:

Quote:
A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
There is not necessarily anything wrong with a standardized configuration format. However, I do not think at all that this means that one should leap to something like a registry or what have you. Configuration files which are actually scripts seem like the best way to go to me. There's no reason a glorified script editor GUI couldn't be made.

A file named after the system process it configures in /etc/ is pretty damn standardized, though it does somewhat break down - it's not always a file named after such in /etc/.

I suppose my objection to a registry is more of a instinctual sort of thing - it seems a zen crime.

It seems this in two ways: For one, it forces program designers into a specific format (forcing designers to consider things: good. forcing designers to do things: bad). For the other, having something like an XML store seems like unnecessary complexity, without adding the power that simply standardizing on bash (or whatever) as a configuration interpreter would entail. XML lends itself to complicated settings, but then, I don't think that's exactly a good idea. If your configuration file is expected to look like:
code:

# Use KEYMAP to specify the default console keymap. There is a complete tree
# of keymaps in /usr/share/keymaps to choose from. This setting is used by the
# /etc/init.d/keymaps script.

KEYMAP="us"

# Should we first load the 'windowkeys' console keymap? Most x86 users will
# say "yes" here. Note that non-x86 users should leave it as "no".

SET_WINDOWKEYS="no"

# The maps to load for extended keyboards. Most users will leave this as is.

EXTENDED_KEYMAPS=
#EXTENDED_KEYMAPS="backspace keypad"


That means that your configuration file is going to need to be that simple, or you're going to have to design a more complicated system. Every complexity that you make easy on a designer is going to be used, probably far more often than it should be.

Anyway, I'm tired, I'll say some more later.

Freedom of speech is the basic freedom of humanity. When you've lost that, you've lost everything.
1\/\/4y 34|<$p4y 1gp4y 33714y, 0d4y 0uy4y? | Roses are #FF0000; Violets are #0000FF; chown -R ${YOU} ~/base
The DMCA. It really is that bad. : Count for your life.
xzxzzx is offline   Reply With Quote
Old 12th March 2005, 12:58   #336
zootm
Forum King
 
zootm's Avatar
 
Join Date: Jan 2002
Location: the nether reaches of bonnie scotland
Posts: 13,375
Some systems necessitate complex settings, though, and any generalised system should allow them in simple ways. It is trivially easy to automatically parse a file like the one you mention into XML, but I agree that it adds an extra layer of complication. And I don't agree with using scripts for representation -- it's not really standard in any way, and if nothing else nobody will agree on a language to use.

What I'd favour would replace /etc/, and I feel I have my reasons. This comes into why it seems like a "zen crime", though -- it breaks the UNIX file metaphor. "Everything's a file, files you can edit are text" is basically the system upon which UNIX is based, and it works well with the systems that were available at its inception. I do feel, however, that we have better technologies available now, and it would be very nice if we could build a more modern system design from them. Breaking compatibility, or moving to a different system, will always have vehement complaints from users of the current systems, though. And sysadmins are perhaps the most zealous users of all. You could just move everyone to a compatible configuration and merge the XML file structures to configure (GConf does something similar, but with non-standard formats too).

It is something I'm genuinely interested in, though, and I do like to hear well thought-out criticism of ideas. As for your design quote, though, my argument is that what we'd be taking away is a myriad of incompatible configuration formats and so on.

zootm is offline   Reply With Quote
Old 14th March 2005, 18:33   #337
CaboWaboAddict
Forum Sot
(Major Dude)
 
CaboWaboAddict's Avatar
 
Join Date: Mar 2004
Location: Marietta, Ga. U.S.A.
Posts: 3,915
I migrated from using INI files to using the Registry. Now I'm going back to using INI files. Too many issues with customers trying tricks with the Registry - I don't need that kind of support hassles!

Idiot's Advocate
My site (under construction)
CaboWaboAddict is offline   Reply With Quote
Old 14th March 2005, 19:03   #338
zootm
Forum King
 
zootm's Avatar
 
Join Date: Jan 2002
Location: the nether reaches of bonnie scotland
Posts: 13,375
What sort of tricks can they do with the registry that they can't do with INI files?

zootm is offline   Reply With Quote
Old 14th March 2005, 19:34   #339
CaboWaboAddict
Forum Sot
(Major Dude)
 
CaboWaboAddict's Avatar
 
Join Date: Mar 2004
Location: Marietta, Ga. U.S.A.
Posts: 3,915
Quote:
Originally posted by zootm
What sort of tricks can they do with the registry that they can't do with INI files?
Like trashing it, then calling me to help them fix it.

It is just as easy and just as efficient to use an INI file - and a hell of a lot less dangerous when your dealing with computer illiterates.

Idiot's Advocate
My site (under construction)
CaboWaboAddict is offline   Reply With Quote
Old 14th March 2005, 19:38   #340
zootm
Forum King
 
zootm's Avatar
 
Join Date: Jan 2002
Location: the nether reaches of bonnie scotland
Posts: 13,375
I take it you're referring to isolating the data from that of other applications?

My "plan" (i.e. weird solution thing in my head) isn't identical to the registry, and has its own ways of getting around this. I'd still err towards the registry and then just tell them not to touch the entries in it, though.

zootm is offline   Reply With Quote
Old 14th March 2005, 22:05   #341
xzxzzx
Forum King
 
xzxzzx's Avatar
 
Join Date: Aug 2002
Posts: 7,254
Quote:
Originally posted by zootm
Some systems necessitate complex settings, though, and any generalised system should allow them in simple ways. It is trivially easy to automatically parse a file like the one you mention into XML, but I agree that it adds an extra layer of complication. And I don't agree with using scripts for representation -- it's not really standard in any way, and if nothing else nobody will agree on a language to use.

What I'd favour would replace /etc/, and I feel I have my reasons. This comes into why it seems like a "zen crime", though -- it breaks the UNIX file metaphor. "Everything's a file, files you can edit are text" is basically the system upon which UNIX is based, and it works well with the systems that were available at its inception. I do feel, however, that we have better technologies available now, and it would be very nice if we could build a more modern system design from them. Breaking compatibility, or moving to a different system, will always have vehement complaints from users of the current systems, though. And sysadmins are perhaps the most zealous users of all. You could just move everyone to a compatible configuration and merge the XML file structures to configure (GConf does something similar, but with non-standard formats too).

It is something I'm genuinely interested in, though, and I do like to hear well thought-out criticism of ideas. As for your design quote, though, my argument is that what we'd be taking away is a myriad of incompatible configuration formats and so on.
Ok, I'm going to present a 5-minute counter-argument. This is just everything I can think of that I don't like about your solution, because I only have 5 minutes to post.

First, everything-is-a-file is a perfectly valid design philosophy (even today), because it's so damn close to nothing that it's near perfect.

Second, and I don't know exactly what you're proposing, but let's say you're going to have a big XML file which stores configuration data. How can you reasonably keep that thing secure and fast and reliable and recoverable?

Third, while it's admirable to want to have one configuration format, is that going to be able to be simple enough that it's going to be able to be edited by hand? Or is it going to be 12 levels deep before you can even find application data?

Fourth, while it's nice to have a GUI for these things, and that would mitigate some administration-added-complexity rantings I've been tempted to throw in here, how well are you going to be able to edit it

The problem I see is that a registry is basically a duplication of a file system. With a file system, you've already got security, reliability, and speed. The only thing you're missing is complexity, and I don't think that's a particularly bad thing. If you make complex configurations hard to implement, that means it's easier to simplify configuration options than to build your own configuration system.

Finally, when you're trading complexity for simplicity, you have to consider when the complexity/simplicity is going to show up. If you're complicating common operations (99.9%), and simplifying rare operations, then you'd better well be eliminating a HUGE complexity in your rare cases.

From what I can tell, "vi /etc/sshd" is far, far, FAR more common than anything you'd ever need a database/XML thing to do with more simply.

And now I must go.

Freedom of speech is the basic freedom of humanity. When you've lost that, you've lost everything.
1\/\/4y 34|<$p4y 1gp4y 33714y, 0d4y 0uy4y? | Roses are #FF0000; Violets are #0000FF; chown -R ${YOU} ~/base
The DMCA. It really is that bad. : Count for your life.
xzxzzx is offline   Reply With Quote
Old 16th March 2005, 20:36   #342
CaboWaboAddict
Forum Sot
(Major Dude)
 
CaboWaboAddict's Avatar
 
Join Date: Mar 2004
Location: Marietta, Ga. U.S.A.
Posts: 3,915
Quote:
Originally posted by zootm
I take it you're referring to isolating the data from that of other applications?

My "plan" (i.e. weird solution thing in my head) isn't identical to the registry, and has its own ways of getting around this. I'd still err towards the registry and then just tell them not to touch the entries in it, though.
Yeah, someone in sales told some of the customers that my software stores part of its configuration in the registry. SO they went dickin' around in there and trashed the whole system (not just my software), then they wanted me to straighten it out.

On the next release of each of my packages, I'm taking it back to INI files.

Idiot's Advocate
My site (under construction)
CaboWaboAddict is offline   Reply With Quote
Old 5th August 2007, 18:56   #343
spiderbaby1958
Major Dude
 
spiderbaby1958's Avatar
 
Join Date: Aug 2002
Location: Binghamton, NY
Posts: 789
Happy anniversary to me!

Quote:
Originally posted by spiderbaby1958
As for myself, I have decided: f**k Microsoft. (Hey there's something wrong with my keyboard, let me try that again FUCK MICROSOFT! (There, that's better.) Lately, I've been thinking of dabbling in Linux, but now I'm planning on making Mandrake Linux my primary OS, the sooner the better.
Five years ago this month! I chose the road less travelled, and that has made all the difference.

Of course, Mandrake is now Mandriva, and I've moved on to Debian and openSUSE. Oh what fun it has been.
spiderbaby1958 is offline   Reply With Quote
Old 29th August 2007, 05:45   #344
rockouthippie
Banned
 
rockouthippie's Avatar
 
Join Date: Jun 2004
Location: Oregon
Posts: 11,002
HD-DVD and Blue Ray discs have phone home DRM capacity, but they are not using it. The FCC nixed the broadcast flag.

While we are finding DRM invading, the DRM happy have had to back off quite a bit.

Next-Generation Secure Computing Base (formerly called Palladium) has positive possibilities. Consumer pressure should keep George Orwell from happening.

I expect that your VCR, Tivo and unencrypted MP3 collection will play for some time to come. Even if this was a product, it would first be adopted for secure business environments. You won't see anything like it for consumer desktops for years.
rockouthippie is offline   Reply With Quote
Reply
Go Back   Winamp & Shoutcast Forums > Community Center > Breaking News

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump