Which one, and why?
Or, if you don't currently use Linux, which ones have you looked at or thought about trying?
Slackware.
I'm about to switch.
I tried the LiveCD for Bisexual Ubuntu Linux. It seemed pretty nice. I'm switching to Kubuntu (KDE version). I assume I'll switch to something else later, since I won't really know enough to make an informed decision before I've actually used Linux.
I view it as a horses-for-courses market...
For my own machines, and boxes I manage -- Gentoo Linux.
* It runs on all my machines... both x86 and MIPS
* Great package management
* Lets me do everything, my way.
* Install only the stuff you need, no unneeded cruft.
* I also happen to be a developer for Gentoo -- so this is a no-brainer. ;-)
For other people's machines I'm setting up -- Ubuntu
* Great package management
* Well integrated desktop
* Keeps things simple, but allows users to get their hands dirty.
I also dabble with Debian (I have one box currently running Debian, an old Toshiba Satellite PRO 430CDS -- acts as my serial console server).
4-ch is powered by Debian. That's not something we like to brag about: given that the Debian community is reknown for being a bunch of anti-social idiots who like to beat up the n00bs. But the OS has a "No Bullshit" policy of only installing what is needed, without having to build everything from scratch. And with the performance we get out of it, this is a good thing.
A good laugh: http://nanocrew.net/2005/10/03/despair-linux/
I use Ubuntu on a laptop; the April 2005 version. It's mostly nice, but that "Synaptic" program is so totally broken: slow, horridly organized...
Has that been improved in the October 2005 version? If so, I might bother trying to upgrade.
Gentoo.
I do not recommend Gentoo. The ricer speed boost is minimal even with lots of flags, and binary packages are nonexistent. The BSD-style services are nice but still a hassle compared with (yes) Windows. The only reason I use it is because I managed to get my fake VIA graphics card working on it, and I don't want to waste countless hours of my life duplicating that effort on a better distro, when I could be posting on Internet forums.
I've never tried Ubuntu, but it sounds nice, and Debian was fun.
I use Gentoo right now but if I ever reinstall, I will install Slackware. I sort of got 'stuck' in Gentoo because of all the configuration goodies -- a bit addictive. Slackware because it stays out of the way and doesn't modify the programmes. I also like the configuration (BSD style, I think it's called) which is very simple and easy to change.
I use (k)ubuntu and I'm sticking to it. I don't want to use time on configuration, I like it when things work well enough out of the box.
Also the update cycle fits me well, every 6 months I get new goodies. With Debian, the software update cycle is too long for me, with gentoo it's too short.
I made the mistake of installing Gentoo on one of my older computers. It took a few days for it to compile everything. I let it keep going because I though it wouldn't be so bad once the initial install was done. I was wrong. It seemed that I was always waiting for something to compile. So obviously, slow computers and Gentoo don't go together.
Yeah... that was one of Slackware's biggest advantages, IMHO... was the BSD-style init scripts.
/etc/rc.d/rc.modules -- loaded kernel modules (drivers)/etc/rc.d/rc.inet1 -- configured your network/etc/rc.d/rc.inet2 -- started up daemons/etc/rc.d/rc.local -- misc stuff
There were others too... it was neat! It did mean you needed to edit these files yourself to start daemons, but it wasn't so bad, and worked rather well. Very flexible, but it did mean more work maintaining your boot scripts.
Red Hat, Debian, SuSE, Ubuntu, and just about any other distro you care to mention use SystemV-style init scripts. That is, in /etc/rc#.d (where # is the runlevel -- 1 to 5), you have a bunch of symlinks pointing to scripts in /etc/init.d (or /etc/rc.d/init.d in earlier versions of Red Hat).
The symlinks were named, S##servicename -- for services to be started in that runlevel... and K##servicename -- for services to be killed. The ## bit was a number, indicating the order of things to take place. The script to kick this all off (called from init), therefore looked a little like this:
#!/bin/bash
# rc -- Start and stop runlevel services
#
# Get the new runlevel
runlevel=$1
shift
# Get the last runlevel
oldrunlevel=$(< /var/lib/runlevel )
# Leave the old runlevel...killing its services in order:
for service in /etc/rc${oldrunlevel}.d/K*; do
$service stop
done
# Start services for new runlevel
for service in /etc/rc${runlevel}.d/S*; do
$service start
done
# Store the new runlevel for reference later
echo ${runlevel} > /var/lib/runlevelAnd in /etc/inittab...
l0:0:wait:/sbin/rc 0
l1:S1:wait:/sbin/rc 1
....
l5:5:wait:/sbin/rc 5
l6:6:wait:/sbin/rc 6Now, my only complaint with these two, is that it's a bitch knowing which order services are to be started in. Removing a service from several runlevels with the SysV scripts, without the use of some tool, is repeticious tedium. Adding a script is even worse.
Gentoo's system was a breath of fresh air. It uses named runlevels (how many people would know runlevel 0 was halt and runlevel 6 was reboot?) and dependancies are tracked. i.e. if the machine tries to bring up a DHCP-configured ethernet adaptor, it won't try running NTP -- because presumably the NTP server will be inaccessible. It also allows for parallel starts.
It's not to bad to configure. There's rc-update to do things for you... but doing it by hand is easy too. Inside /etc/runlevels, there's a bunch of directories, one for each named runlevel. Inside that, is symlinks to the init scripts to be started. Want to start a service in the default runlevel? Easy, just ln -s /etc/init.d/SERVICE /etc/runlevels/default, and you're done. No order numbers to worry about (as in SysV), or knowing where in the script file to place the start service line (BSD).
As for the point of Gentoo on slow boxes -- this is where Debian has a significant edge, as nothing needs to be compiled. However, if you have a few powerful boxes running Gentoo, and your CFLAGS are set appropriately, it's not that difficult to emerge -B a package to produce a binary for the slow box in the cluster. You can also use distcc, which will throw the compile jobs (but not linking) around the network.
I use Debian on my laptop... with apt sources for experimental... Some things, like my perl configuration, tend to be broken, but the apps I actually use are sort of stable. ( Two annoying bugs, but hey, whatever. It's not supposed to be a super-stable ultra-secure machine )
The plus side of having this sort of environment is that I can easily build damn near every application I want from CVS sources without having to look too much for the correct versions of things the app depends on, A high-enough version can usually be found in the package repository.
>>11 makes me want to run over to "UNIX redone" thread and cry.
Linux really, really needs to start using launchd, or something else remotely sane.
>>14
Apple's replacement for initd (and a whole lot more):
http://developer.apple.com/macosx/launchd.html
http://arstechnica.com/reviews/os/macosx-10.4.ars/5
If you haven't heard about it, you must be living in a cave. :o
No, not living in a cave... I don't have any Apple machines.
Yick! XML for a config file format?? No thankyou, I can do without the bloat of an XML parser.
Awareness of it has little to do with owning an Apple box. It was discussed quite a bit in the *nix world a few months ago.
I have no love for XML either, but it's self-validating, which is crucial when you're dealing with something similar to init. They could have developed a different format with similar properties, but that throws out the benefit of an already-existing set of tools. Furthermore, XML is less ugly than reams of shell script.
Throwing out the entire idea just because you don't like one aspect is questionable. The inertia that the *nix community displays to some good ideas is really annoying to me, particularly when they come up with trivial excuses.
The XML format is not there just for the sake of having an XML format. Mac OS X provides not only a parser for XML files, but also for the specifc XML format that plist files use.
A plist is translated into a tree-structure of object (hash tables, arrays, and various wrapper classes for strings, integers and such). It's used for pretty much everything in the system. In yet another callback to the UNIX-complaints thread, this is the sort of facilities an OS should provide, to free developers from the burden of creating new data file parsers over and over again.
I throw away the idea of an XML-based init because....
inittab format might look a little ugly too, but it's heaps better than launchd's format.inittab isn't a file you change often. Normally, it's set up for you with sane defaults, and you go from there.
launchd looks like it's trying to replace not just init, but also cron and inetd. Now, okay you could roll these all into one binary... but there's nothing wrong with using separate programs to handle this. After all, they all do different things:
init looks after runlevel management, kicking off init scripts when asked, reaping zombie processes, and keeping terminal lines opencron runs programs at specific times, as specific users.inetd binds to various TCP ports, and fires of the handling program when someone connects.They do different tasks. Very different.
Incidentally, inetd has increasingly become less important as most programs these days are able to run standalone. In addition, many programs using privileged ports (0 ~ 1023) run as root initially, bind to the port, then chuid to a daemon user with restricted privileges. When inetd was first conceived, this was not the case. It's purpose, is that it would run as root bound to its ports, and it would fork, chuid to a restricted user, then exec the responsible program. That said, it is sometimes useful to be able to run programs like Apache under inetd, rather than as standalone programs.
I do think the cron implementations could do with a shake up. IMHO the crontab file format is a bit arcane, but it's not too bad. I say cron needs attention, and not init, because as I mentioned earlier, you seldom ever need to touch inittab.
inetd has a cleaner alternative... xinetd. The latter is a much more modern implementation, using a much nicer config file format. If cron were to use something similar, that'd be really nice. :-)
You see what I mean?
> there's nothing wrong with using separate programs to handle this.
On the contrary, there is. Did you read either of the links I provided?
In other news, I was in a bad mood when I posted >>20. Please forgive the scathing tone. ;_;
Those posts weren't there when I wrote my reply... I saw them after I had clicked Reply.
Okay, Mac OS X might have this wizz bang XML parser. Linux has one two... libxml2 for one.
However, my point is, it's still an additional library kicking around. And for things like Busybox ( http://www.busybox.net ), this is a Bad Thing.
XML is also overkill for the task. A lot of these programs just need a simple, flat config file structure. XML is a tree structure. For things that are "trees", yes, XML is wonderful. But for things like cron tables, file system tables, etc... it very quickly turns into a mess of tags.
Suppose we wanted to revamp the format of the /etc/fstab file. At present, this is what it looks like. This is my fstab file:
stuartl@beast /mnt/scratch/gentoo/mips/ip22/busybox-1.01 $ cat /etc/fstab
/dev/sdc1 / xfs rw 0 0
/dev/sdb1 /boot ext2 rw,noauto 0 0
... some more for /usr, /opt, /var...etc...
/dev/sdb2 /mnt/win2k ntfs ro,umask=0000 0 0
/dev/sdb5 /mnt/apps vfat rw,umask=0000 0 0
... etc...Now, you could do that in XML. This is what it could look like:
<fstab>
<device node="/dev/sdc1">
<mountpoint>/</mountpoint>
<type>xfs</type>
<options>rw</options>
<dump>0</dump>
<pass>0</pass>
</device>
...
</fstab>Or perhaps you could do this...
<fstab>
<device node="/dev/sdc1">
<mountpoint dir="/" />
<type name="xfs" />
<options>
rw
</options>
<dump value="0" />
<pass value="0" />
</device>
...
</fstab>Notice how less readable that is?
I'd much rather see a far simpler format. Something like this:
/dev/sdc1
mountpoint: /
fstype: xfs
options: rw
dump: 0
pass: 0
/dev/sdb1
mountpoint: /boot
fstype: ext2
options: rw noauto
dump: 0
pass: 0Now isn't that so much neater? :-) It's also trivial to parse too. Not as easy as the original format (cut -d' ' -f COLUMN), but considerably easier than the XML.
Pseudocode for parsing the above file:
Define a data type, mountRecord with the following members:
String device
String mountpoint
String fstype
Array of Strings options
int dump
int passDefine an array of mountRecords, mounts
Define a mountRecord, record
Define a String, var
Define a String, val
Define an int, positionforeach line in file:
if line starts with whitespace:
Strip proceeding whitespace from line
position = location of ": " sequence in line
if sequence found:
var = line->subString( from start to position )
val = line->subString( from position to end )
case var in:
mountpoint: record->mountpoint = val
fstype: record->fstype = val
options: record->options = val
... etc ...
else
add record to mounts
clear recordNot terribly difficult in C. Now, does this explain my opposition to the idea of XML? I agree, some files could do with an update... it's very difficult to mount a partition on a directory containing spaces unless you do it by hand. I'm not sure if mount is smart enough to recognise the \ escape sequence. That format above would handle spaces in the middle of a directory name (but not starting or trailing spaces).
My point is, yes... things could be improved... but we don't have to turn to XML. If you use a hammer to solve every problem, then every problem will tend to look like a nail.
No, I understand your opposition to XML. Like I said, I don't like it either; I'm firmly in the "smaller is better" camp. However, XML is flexible enough that you can use it for a wide variety of tasks. It seems Apple wants to use it for configuration, and considering the myriad needs for configuration tasks, XML is an existing wheel with good fit.
If XML is the price to pay for a single uniform configuration system, I'd pay it in a heartbeat. You don't even need to look at XML in plaintext if you don't want to, because you can use programs explicitly made for editing XML. Fortunately, unlike the mess known as Microsoft's registry, XML usually isn't binary, so you can still process it with normal text tools. It seems to be a net win to me.
Right now, in *nix land, configuration files are largely (all?) custom. None of them have the same format, and it's annoying. Throwing out all the custom crud and replacing it with a single shared library will both reduce bugs and code size. Hell, I want a single config API, but I'm not aware of any with penetration. Add an XML editor in standard distro, and walk away laughing.
That said, this is tangental to replacing initd & co with launchd.
Indeed, Mac OS X ships with a GUI program to edit plist files quickly. Of course, this is seldom necessary, as programs usually have proper interfaces for editing settings. But when you need to do some low-level hacking, it gives you a quick way to look at and edit not just any config file, but lots of other files too - most data files are plists, too.
Arguments about code size are silly. If you based all decisions on what to include in an OS on the requirements of embedded systems, we'd still be stuck in the seventies. If it is really too much to keep an XML parsing library around, then you make alternative lightweight tools for the embedded systems. You already mentioned busybox, which is exactly that. By your arguments, we shouldn't be using glibc att all for anything, because it's too big and bloated to fit on embedded systems. I work with embedded systems, and let me tell you, Linux itself is far too big and bloated to fit on those I use. Let's never use Linux anymore!
Here's a question, which produces more bloat: One XML parsing library, or the config file parsing code in every program that uses a config file?
And to answer the main point of >>22:
Yes, XML files are less readable. That is besides the point, because when you have a standardized config format, you can create tools to deal with it more efficiently. You don't need to edit it with a text editor, but you can still edit it with a text editor.
And yes, you could think up a more efficient format. But then you are losing the main advantage, which is that everything can use plists. If you use a simpler and more efficient format for things that don't need the full XML format, you need separate tools to deal with separate files. Or, since this is UNIX we're talking about, you're back to using text editors again, and learning multiple config formats.
This thread is hopelessly infested with programmers :(
Actually... the current crontab, fstab and inittab files, aren't that different.
They're delimited text files... much like csv.
fstab and crontab are whitespace delimitedinittab is colon delimitedStandard tools? cut, grep, and a few shell inbuilt functions is all you need.
This is why the format is chosen. Now, the tabbed format I mentioned above would be much more difficult to parse by a shell script, but still not impossible, sed would have to join the party. XML however would be damn near insanity.
And yes... everything can use cut, and grep, or an inbuilt equivalent. A version of grep with the complexity required for this task is very trivial. Bloat? What's 1kB on most machines? libxml2's shared library weighs in at a whopping 2.1MB on my machine.
>>24, Funny you should mention dumping glibc. I've been wanting to do that for months in the Gentoo/MIPS project. Largely because it's a pain in the arse to build if you've got <= 128MB RAM. Unfortunately, my Cobalt Qube 2 falls in that category with 128MB RAM, and so I usually have to kill a couple of running daemons before a catalyst run will succeed.
On x86 systems, many binary-only programs (such as Sun Java, most games), and some of the prebuilt binaries like the ones from OpenOffice.org and Mozilla, are all linked against glibc. Very few are linked against µClibc. So there is a point to using glibc -- it's highly backward compatable with binaries linked against earlier versions (which µClibc is not -- believe me, I found out last night). Also, µClibc is not compatable with glibc-linked binaries. So on x86, it's obvious why they still use glibc. On Gentoo/MIPS, it's the backward compatability that keeps us using glibc for now. But many of us are thinking of moving to µClibc, especially now that it supports NPTL. (although support for that will be some time, currently it relies on gcc CVS HEAD, and the very latest snapshot of µClibc)
So okay... getting back ontopic... we could use two different config formats... in fact, the sane thing would be to keep support for the old format for legacy installations and embedded systems. This would keep backward compatability.
Now okay... I now ask this... how many developers, do you think will move to this new format? 50%? 20%? 2%? Possibly closer to the latter... because many distributions already handle the old format just fine, and don't see a reason to change. Moving to the new format would require much hacking of existing tools. This would be made easier by a common library... but what if the library lacks the API you're looking for? We're back to the roll your own mess we're in now.
Hey, I want to get some opinions here. There's a couple of Black Friday sales on the Sandisk Cruzer and PNY Attache USB flash drives. I really would rather get a Lexar JumpDrive Lightning for its on-drive security features, but for the prices that are being offered ($80 for a 2gb USB flash drive? YA RLY) I think I can suffice.
So does anyone have any recommendations/warnings/cautions about either? This thing is going to be carried everywhere on my keychain. What I want to do is get some sort of flash drive security software that password-protects it and works on IBM PC computers.
> the current crontab, fstab and inittab files, aren't that different.
They're not the only configuration files on the system. There's all the files for shell, all the files for X, all the files for the window manager, all the files for the applications, etc. The stuff in /etc/ is perhaps a few dozen out of the hundreds you'll find on a system.
> A version of grep with the complexity required for this task is very trivial.
All those tools work on XML too. However, if there was a single configuration system, you'd only need to resort to them in exceptional circumstances anyway. One reason to have a standard config API is so you can build surrounding support infrastructure as well. There should be no reason to resort to grep and friends in the first place.
You can, but you shouldn't need to.
> libxml2's shared library weighs in at a whopping 2.1MB on my machine.
libxml2 is large, but just as there is busybox, there are also much smaller (and more limited) implementations of XML parsers out there. Take a look at TinyXML for instance.
In any case, half of that 2.1MB are debugging symbols. So you're left with ~1MB of library floating around on computer that have >128MB RAM. That's less than 1%. Furthermore, if the XML parser is full-fledged, I imagine applications, like browsers, will use it for more than just configuration.
> and some of the prebuilt binaries like the ones from OpenOffice.org and Mozilla, are all linked against glibc.
You want to replace glibc, but use OO.org and Mozilla? That's like writing bubblesort in assembly to sort large arrays...
> This would be made easier by a common library... but what if the library lacks the API you're looking for?
The point we've been arguing from the beginning is that it should be replaced by a common library. We aren't referring to the use of XML directly.
By replacing the junk we have now with a single API, we get rid of the thousands of different formats that are currently out there. We get a single API to target, and the supporting infrastructure.
Developers won't need to waste time developing their own parsers. Admins won't need to waste time hacking up custom scripts to munge with yet another configuration format. Support will be happy because of the support infrastructure. And so on.
Of course, the reason the *nix world is so ugly is because there is no authority. This is why OSX kicks the living shit out of any OSS OS usability-wise, and a lot of the underlying architecture is more elegant too. If there's any justice, freedesktop will start ripping off ideas from OSX, since the rest of the OSS world can't get its act together.
Yeah... this is the problem though... convincing the masses that we should use format X (e.g. XML, the "whitespace" tree, CSV, whatever) rather than making one's own. And this ties into the point I made before -- use a hammer for everything, everything will look like a nail. Developers pick formats that meet their own ends.
In Gentoo, most of our config files use Bourne-shell syntax. In fact, for the most part, they are Bourne shell scripts.
/etc/make.conf is exactly that, a shell script. It gets sourced by portage when building stuff. The ebuilds themselves? Again, shell scripts. Where's the parser? /bin/bash does that for us.
I dare say many apps could use some other format, but sometimes there's very good reasons for picking one format over another.
Config scripts being shell code is something I really don't like. It's one of the reasons initd (whether SysV or BSD) is so ugly. It's also one reason why launching services in parallel, based on dependencies, is near-impossible.
> Developers pick formats that meet their own ends.
I disagree. They pick solutions for their needs. There is no standard API, so they all roll their own. XML is just a symptom; I wouldn't care what the format was as long as there was an API.
Actually init uses a CSV format... it's not a shell script at all.
Try running:
stuartl@beast ~ $ grep -v '^#' /etc/inittab | grep -v '^$' > tee /tmp/inittab.csv... then throw the resulting file at any spreadsheet (e.g. OpenOffice). It even works as a raw file... all the grep commands do is filter out the comments and blank lines.
Parallelising of services is done by the rc scripts, which are normally shell scripts. And again, I point to the Gentoo rc scripts (part of the baselayout package), which do allow parallel startup of services.
> > Developers pick formats that meet their own ends.
> I disagree. They pick solutions for their needs. There is no standard API, so they all roll their own. XML is just a symptom; I wouldn't care what the format was as long as there was an API.
Well, you mentioned a couple of libraries, that could be used as a standard API. The fact is, they aren't used as a standard API, because (1) none of us can be bothered, but also (2) sometimes there are good reasons for doing things differently.
Some programs are not binaries, but rather, are shell scripts. So using the shell itself to parse their config files is an easy route out. It's also a route that works rather well. Shell scripts have a simple syntax, and work just fine as config files.
How many web applications use a script in PHP or Perl for their configuration files? Again, having a file in another format, means introducing code to parse it. Even in PHP, where there's built-in XML parsers -- you still have to write logic to use those parsing functions. Or you could just do an include("config.php"); and be done with it. The latter also means you don't have this config file out in the open, as the webserver will render the PHP code, producing an empty document -- whereas they'd have to use .htaccess hacks to hide the file otherwise.
Core system programs, yes, I see a benefit in having them use a similar config format. Outside of that though, it starts to become more impractical.
Bah, caffeine difficiency disorder... that tee isn't susposed to be there. (either keep the > and ditch tee, or keep tee and ditch >)
> Actually init uses a CSV format... it's not a shell script at all.
I'm referring to rc.d et al.
> Parallelising of services is done by the rc scripts, which are normally shell scripts.
I don't see how a shell script can effectively parallelize boot for a couple reasons: the first is that bash scripts aren't multi-process/multi-threaded, the second is that there's no way for the starting processes to communicate back, "Okay, I'm started!" I can think of a number of work arounds, but they're all hacks. Of course, I think bourne shell is piss poor to begin with.
Just using & doesn't cut it. Elaborate on how gentoo does it.
> The fact is, they aren't used as a standard API, because (1) none of us can be bothered, but also (2) sometimes there are good reasons for doing things differently.
No, they aren't used because they aren't used. Programmers want their programs to achieve a wide audience, and that includes minimizing fringe dependencies. There's another problem with fringe libraries: they're more likely to be buggy, and there's no guarantee they'll be there in the future. It's a vicious cycle.
These are all things that go through my mind. I'm absolutely certain most other developers think alike.
Anyway, you have yet to tell me what these good reasons are. The Mac world seems to be doing just fine with their APIs, and if it's really so bad, a program can still use it's own config. However, the vast majority don't. Hell, if you can serialize an object into XML, I don't see what you can't do.
It's a lot like getopt(). A long time ago coders all rolled their own CLI option parsers, and it was bad. Then getopt() came along, and it was better. It's a bit pathetic we still have things like dd floating around which use their own parsing, because it only makes the interface even more inconsistent.
> Some programs are not binaries, but rather, are shell scripts.
You can use getopt in shell scripts. Now, why not do the same for configuration? Well, other than the obvious fact that Bash and friends should all be thrown away, but I digress.
> How many web applications use a script in PHP or Perl for their configuration files?
To be honest, that's both ugly, error-prone, and horribly brittle. Ignoring that, perl and php scripts are hardly the norm. Servers serving webpages use it, but most applications don't. Even so, if there was a uniform API for gathering options, I'd use it. A couple perl scripts I've written in the past had their own config formats, and it would have been nice if I didn't have to do that.
> > Actually init uses a CSV format... it's not a shell script at all.
>
> I'm referring to rc.d et al.
m0n0wall is an example that doesn't use shell scripts. Instead it uses PHP, and XML for its config files.
Mind you, it's a highly specialised version of FreeBSD, a router distribution. Shell scripts don't have to be written in shell scripts, but that's what's done because that's what most Linux distribution developers are used to, and is what has been done historically.
>
> > Parallelising of services is done by the rc scripts, which are normally shell scripts.
>
> I don't see how a shell script can effectively parallelize boot for a couple reasons: the first is that bash scripts aren't multi-process/multi-threaded, the second is that there's no way for the starting processes to communicate back, "Okay, I'm started!" I can think of a number of work arounds, but they're all hacks. Of course, I think bourne shell is piss poor to begin with.
>
> Just using & doesn't cut it. Elaborate on how gentoo does it.
http://www.gentoo.org/cgi-bin/viewcvs.cgi/rc-scripts/sbin/rc-services.sh?root=gentoo-src&view=markup
It's right there, under start_service. This is an old version of the file, I've been digging around in CVS, I'm not sure where the latest version is kept. It does basically the same thing though. It backgrounds the process using the & operator (which tells bash to fork and exec).
> > The fact is, they aren't used as a standard API, because (1) none of us can be bothered, but also (2) sometimes there are good reasons for doing things differently.
>
> No, they aren't used because they aren't used. Programmers want their programs to achieve a wide audience, and that includes minimizing fringe dependencies. There's another problem with fringe libraries: they're more likely to be buggy, and there's no guarantee they'll be there in the future. It's a vicious cycle.
And this brand new config file (lets call it libconfig for the sake of argument) would not be buggy and a fringe dependancy how? As I say, you've still got to convince the masses out there that it's worthwhile porting their code to this new library.
I realise there are benefits in doing this... but there are programs out there, that have been handling config files, for decades. sendmail and procmail are classic examples -- both have an absolutely horrid config file format. People have winged about their config file formats for years, and the developers there still insist on using that old format, even though many viable alternatives exist.
The kludge they've come up with, is GNU m4 -- macro processing, which is every bit as ugly as the original file.
> These are all things that go through my mind. I'm absolutely certain most other developers think alike.
>
> Anyway, you have yet to tell me what these good reasons are. The Mac world seems to be doing just fine with their APIs, and if it's really so bad, a program can still use it's own config. However, the vast majority don't. Hell, if you can serialize an object into XML, I don't see what you can't do.
I have actually. Shell script applications are a classic example. Many of them use a shell-script syntax for their config files, because all the script has to do is source the file. Easy. Almost bug-free... and it works. If their paranoid, they can sanitise a copy of the file first using sed and grep, but most don't bother.
> It's a lot like getopt(). A long time ago coders all rolled their own CLI option parsers, and it was bad. Then getopt() came along, and it was better. It's a bit pathetic we still have things like dd floating around which use their own parsing, because it only makes the interface even more inconsistent.
>
> > Some programs are not binaries, but rather, are shell scripts.
>
> You can use getopt in shell scripts. Now, why not do the same for configuration? Well, other than the obvious fact that Bash and friends should all be thrown away, but I digress.
Actually... you don't need getopt in shell scripts. case, shift and pattern matching will do that all for you:
while [ $# -gt 0 ]; do
argument=$1
shift;
case $argument in
--foo|-f)
do_something $1 $2 $3
shift 3
;;
--bar|-b)
do_something_else
shift
;;
*)
show_help
echo "unrecognised option: $argument"
exit 1
;;
esac
done> > How many web applications use a script in PHP or Perl for their configuration files?
>
> To be honest, that's both ugly, error-prone, and horribly brittle. Ignoring that, perl and php scripts are hardly the norm. Servers serving webpages use it, but most applications don't. Even so, if there was a uniform API for gathering options, I'd use it. A couple perl scripts I've written in the past had their own config formats, and it would have been nice if I didn't have to do that.
I put it as a fringe example. :-) There are other examples out there.
jabberd2 uses XML for its config file... which while it looks fugly (IMHO), is understandable because Jabber is in fact based on XML. So they're not dragging in any additional libs by using it.
Apache has been using its HTML-like config file format for years. As have proftpd. Actually, it's a nice comprimise between XML and HTML. Nested blocks are contained within HTML-like tags, with directives being the usual Argument [ Param1 ] [ Param2 ]... format. It's syntactically clean, and works well for both projects.
Samba, RSYNC, PHP and WINE all use the Windows INI config file format. WINE in particular uses it for good reason -- it's used with Windows. It also happens to be a fairly simple, easily parsed config file format that works for the other projects too. Unlike the previous two examples, this is a flat file structure, which suits the needs of these projects just fine.
Gentoo uses Bourne-shell syntax, because most of its management and startup scripts are Bourne shell scripts. You can't get a more bug-free parser in bash than the shell program itself. Hence they just source the config file, which sets global variables in the program in question.
Many of the core programs on most Unix and Linux derivatives use whitespace/colon delimited text files because (1) they're easy to parse, (2) they aren't too bad to read, and (3) it's what's been used historically. The more complex the file, the more likely bugs will crop up.
Now, putting this all in a single library will help reduce bugs in the sense that all the parsing logic in one place. But it will introduce bugs, because the parsing logic has to be adapted to use the new library. In fact, things like core system utilities will have to be backward compatable. So you're not really removing code/bugs, you're adding code. Logic to call the functions in libconfig, as well as file format detection logic so it doesn't try to parse a new-style config file using the legacy file parser.
> Well, you mentioned a couple of libraries, that could be used as a standard API. The fact is, they aren't used as a standard API, because (1) none of us can be bothered, but also (2) sometimes there are good reasons for doing things differently.
No, that's missing the point. libxml isn't suitable as a standard config file API, because there's still a huge amount of code needed to correctly parse your files. What is needed is a library specifically made to easily store data in some format - XML is likely, since it is popular and there are good libraries to parse it, but it could use something else.
Mac OS X programs don't read and write XML files for their config info. That would be horribly cumbersome and inefficient. They use much higher-level APIs to read and parse the contents of a plist file, which just happens to be XML, but the program never needs to worry about that. The program pretty much just creates a single object that that provides all the information in the file in a convenient format.
> And yes... everything can use cut, and grep, or an inbuilt equivalent. A version of grep with the complexity required for this task is very trivial. Bloat? What's 1kB on most machines? libxml2's shared library weighs in at a whopping 2.1MB on my machine.
First off, 2.1 meg isn't anywhere near "whopping" these days, not if it's a shared library installed by default. And as dmpk2k pointed out, you can shrink that. And finally, I seriously doubt most programs use as little as 1kb of code to parse their config files. Now, try to imagine how many programs you have on your machine that have their own code for parsing config files.
Right... The fact is... even if such a config file API did exist, you still have to convince the masses that they should use it.
This is a point I've been trying to make all along. And, as I mentioned, some use whatever format... because that's what suits their application. It's as simple as that.
I don't doubt at all, that a config API could help reduce bugs. But... (1) it will introduce bugs itself as it'll be new code, and (2) it will introduce bugs into programs ported to it, because again -- it's new code. In programs that need to be backward-compatable, it will introduce even more bugs, because there's not just the logic to use the new library, but also detection logic to work out which library to use.
> Right... The fact is... even if such a config file API did exist, you still have to convince the masses that they should use it.
Which is why *nix land is ugly as sin.
OSX can get away with it because of a central authority, but OSS is still bickering over GTK/Qt (and now EFL and GNUstep), there are three mediocre desktop environments (and countless window managers), each app has its own ideas of usability (despite things like HIG), the command line is a mess, and we're stuck with dinosaur relics from several decades ago that are held together by ugly hacks several layers deep.
A lot of great ideas get thrown out because of inertia and a lack of central authority. If the car industry worked the same way as OSS we'd be driving turbo-charged Model T's made out of composites.
Also, I explicitly mentioned that & doesn't cut it. If gentoo uses & to parallelize, then it's obviously a half-baked solution. Yet another ugly hack.
> > Right... The fact is... even if such a config file API did exist, you still have to convince the masses that they should use it.
> Which is why *nix land is ugly as sin.
I don't question this at all. The OSS community is about choice and freedom. People do what they please for the most part. As such, trying to get everyone to do something a particular way can be likened to hearding cats.
If there was to be a governing body though... who do you suggest that should be?
> Also, I explicitly mentioned that & doesn't cut it. If gentoo uses & to parallelize, then it's obviously a half-baked solution. Yet another ugly hack.
You did mention that it was a hack... correct. How would you do it better?
This hack does work fine for our needs though. I've seen other solutions, such as using Makefiles as init scripts... so the rc script just changes to a particular directory and runs make boot or something similar. This would be better... except now make would have to be installed into / rather than /usr where it normally exists.
> who do you suggest that should be?
Maybe a stronger freedesktop. They've achieved a lot in a short time, and they're forward-looking. I'd say LSB too, except they're stuck in the past.
> How would you do it better?
launchd would be a start.
Ohh dear... looks like this argument's going to go back around in a loop again.
No, launchd is not the magical silver bullet to solve all problems.
Well, this was the issue to begin with. Apple didn't decide to build launchd just because.
And while it's no silver bullet, it's a step in the right direction. Ruby isn't a silver bullet either, but it's a far more pleasant language than COBOL.
What I haven't heard... is what we're gaining, by combining the roles of inetd, init and cron into one overglorified program?
They are different. Wildly different.
How about parallelized loading that isn't a bad hack? Dramatically reduced boot times? And the convenience of having a single too to launch programs automatically?
I think it'd reduce bugs, both in the programs themselves, and problems caused by the hackery currently needed. One reason why MPI is eating PVM's cake in the parallel-computational world is for exactly this reason.
Nor are they wildly different. They all serve one role: starting programs based on specific criteria, whether that be a timing or network event. So you end up with shared config, shared event system, shared security kernel, shared error reporting, shared criteria processing, and probably a few other things.
You'd only need to abstract the timer and network handling.
I don't doubt there are some overlaps... Yeah, they all start programs... So do shells.
Does that mean bash should be munged in there as well? So it too can benefit from all of the above?
This is an argument for having a common library shared between different binaries... but having separate programs IMHO is better than one overglorified program doing everything. For starters, it's less code to duplicate when the program does a fork before execing a program. :-)
Individual programs that do one thing well is after all a major part of the Unix philosophy. :-) Look at how well Multics(sp?) did.
> So do shells.
Shell provides two other significant items: scriptability, and a command-line (which can be largely considered a subset of scriptability). Scriptability adds a large hunk of overhead.
> less code to duplicate when the program does a fork before execing a program.
All modern OS use copy-on-write. So, no, not really.
> Individual programs that do one thing well is after all a major part of the Unix philosophy.
Define "one thing". Does this one thing work in isolation? What if multiple one things were better of being a single one thing?
In any case, the Unix philosophy is being sodomized by the OSS community anyway.
Rejecting ideas based on vague arguments about "philosophy" is nothing but dogma. I don't have much respect for dogma.
Okay... how about this... come up with a decent implementation of launchd that doesn't require fugly config files and huge parsing libs... and maybe the Linux community will consider it.
I say, maybe. And you'll have a lot of convincing and evangelism to do. There's over 300 distributions. And many of them have backward compatability to consider -- something that would be potentially broken by replacing init.
"Huge parsing libs" is not a problem for the vast majority of distributions. That's just a red herring, most distros already include it anyway.
The config files are incredibly fugly as it is. Changing to XML would make them more readable to someone like me. And putting together a plist editor for easier editing of them would take a decent programmer a day or two.
Compared to CSV?? I'm sorry... no, launchd's format is fugly. CSV has a very simple syntax. In fact, it doesn't get much simpler. It's not so pretty to look at, but it's not that difficult to work with.
I have no problems reading the existing format -- and the same goes for the majority of Linux devs and sysadmins out there.
Apple's plist format is an eyesore. And I shouldn't need a plist editor... otherwise why bother making it human readable?
The point is that is is easily machine-readable so you can have editors that are easier to use than a text editor, and human-readable so you can use a text editor when you have to. Contrary to popular unix belief, text editors are not good for editing config files of any format.
I disagree. CSV and cut(1)/paste(1) type formats are ideally edited in a text editor, and the fact that you don't need a new editor for each and every type of file is one of UNIX's greatest strengths. When a file format is designed to be edited with a text editor, that means top-notch editors for the file format already exist, and no time needs to be spent waiting for them, or programming effort writing them.
Things that are inherently visual (i.e. an image, a musical score, a diagram) deserve their own editor, but for everything else, text editors ought to be used so we don't need a new editor for each and every format that someone invents, including XML configuration files.
Now, just to get this thread back on topic, I'll complain about Debian:
The first Linux distro I attempted to install was Debian. I burned a CD and tried to install from that. It proceeded to the point where it asked me what install media I want to use, which, according to the instructions, it shouldn't have done -- it was supposed to know that I was installing from CD. When I manually selected CD media, it told me it could not read from the CD drive, even though it was running off the CD drive and had already copied some files!
So I posted to the mailing list about this problem, providing as much information as possible. Nobody replied, of course.
>Shell provides two other significant items: scriptability, and a command-line (which can be largely considered a subset of scriptability). Scriptability adds a large hunk of overhead.
I like my scriptability, and command line. It's my preferred interface. So, despite it having overhead, I'd like to keep it. :P
>>55 It offers you a choice, because some people just download the installer CD and install over the internet. Or you might have a CD which is a little old -- provided the installer is recent enough, you can still install the latest version of Debian using that CD to boot.