Slashdot Mirror
Does launchd Beat cron?
Blamemyparents writes "For those who aren't Appleheads, you may not have heard that with Tiger, Apple swapped out old Unix standby cron for their own creation, launchd (Apple mentions it on their OS X page and has the man page for it up as well). Seems like it's a bit nerdy, but this changes a LOT about how *nix systems have done things for many years. Launchd is Apple's replacement for quite a few utilities, including launching and quitting quite a few different things, and getting info from the system and other running processes. This page from Ars Technica talks a bit more in depth about it. Apple has open sourced the thing, and is apparently hoping all the unix kids will take a look."
Based on what I've read about it, it's more a replacement for xinetd and the sysv init scripts than cron.
B
But can it be piped?
Rather than have one system to rule them all, we will now have one more system to use, complain about, introduce new problems, and work with.
Simply referring to launchd as a cron replacement is a major understatement. launchd runs as the init process and according to TFA was primarily made to replace the /etc/rc.d scripts during startup.
/etc/rc.d scripts (considering the length of pause an fsck would take--users would certainly assume there system hung during boot).
This is somewhat understandable for something like OS X. Doing something simple like displaying a GUI detailing startup is terribly difficult with
I'm not sure launchd is something you'd want in 99% of Linux installs but if you're looking for a end-to-end user-oriented desktop I can see how a technology like this is necessary.
I'm not sure Apple Gets It though. Why in the world would they use XML configs? Gesh.
the machine boots to a desktop (auto log in and all) in less than 15 seconds.
I am the Alpha and the Omega-3
let me know when its in ports and ill try it out
freebsd gets no love around here
I have nothing to contribute to this discussion, except for my opinion on how ambiguous headlines are. For example, "Does launched beat cron?" has the following possible meanings (yes, I see it's launchd, but listen):
1) Does as a verb, launchd as n, beat as v, cron as n. That is, a question whether or not the thing "launchd" beats the thing "cron".
2) Does as a verb, launched as adj, Beat as n, cron as v. That is, a question whether or not thing Beat, which has been launched, crons. (Well, "croon" is a verb, so maybe "cron" is too).
3) Does as a noun, launched as v, beat as adj, cron as n. That is, a statement that female deer have launched "Beat cron" -- cron that has been beaten, perhaps.
Any others?
Launchd provides faster startup through a unified framework for starting, stopping and managing daemons, and incorporates inetd, init, mach_init, System Starter and related services.
To make matters worse, current frontends to cron specifically require an executable. If this executable needs to have some input, matters become kind-of complex, at least for me.
If launchd can save me this misery, that would be a very good thing. The problem though is that I can hardly afford a Mac but I recognize that this is a nother matter altogether.
Sun came up with (at first glance) a similar thing called Service Management Facility in Solaris 10.
Apple is doing a good thing here is shaking up the administrative and setup side of the UNIX world. Most of their work was actually NeXT's, but their "Application as directory" concept is wonderful in a lot of ways, and their reorganizing of the filesystem so that it makes more sense to users is probably a good move in the long run.
What makes UNIX superior for management and power-users is the ability to do everything you need to from command-line tools and options, and the fact that the storage for configuration is in understandable, alterable files. If those are still there...if I can still run my Apple from the shell--I'm a happy man.
The only exception to this would be cases where a vendor deliberately makes a deviation simply to introduce incompatibilities. I don't see that as the case here.
Gentoo has a nice system for init dependencies. However, they don't start independant services in parallel like they should..=/
that the submitter simply couldn't spell or capitalise correctly?
"Does launchd Beat cron?"
What is that? Some new form of AOL speak?
Looks cool? Based on what?
4 lines on apple page? 20 lines man page? or brief description on Arstechnica (which could be more or less read as "Apple did it, so it is got to be cool")?
I would rather see D/BUS version of system wide launching mechanism. Unfortunatelly, that woulld mean that everything would have to support D/BUS, which would require a lot of rewriting.
D/BUS has very low requirements, it is running on *X and soon on Win too. What it would be nice it would be a possibility to access and work with D/BUS from low scripting level (bash, shell...). If you could register your script with system based D/BUS event?? That would be something.
Signature Pro version 1.13.2-3 release 83.5 beta3try7 after-breakfast edition
Sure you can start them concurrently! Just add strategic "&" signs after the commands that start them up and they will start up in background processes of their own.
did you RTFA? launchd seems to be a system wide super program launcher. startup, timed, event driven (plug in a usb memory stick and get a pop up window asking what you want to do).
from reading the article, launchd sounds like a viable technology to replace quite a few convoluted system on my linux machines.
More like, "it's a single, consistent format and therefore inherently better than anything else".
Isn't half the attraction to OS X for geeks how its not that much different from Linux or BSD from the console? And that many/most Linux/BSD scripts and apps would work with just a few, if any changes? I don't see how making it more different really helps it. Not trying to be a troll, but I got to assume if all or most the other Unixes work with what launchd replaced just fine, that OS X could as well.
Every time you post an article on Slashdot, I kill a server. Think of the servers!
Adding XML to to core services like init is beyond stupid, and merging several independant utilities into one monolithic tool is the exact opposite of how unix works. A single, simple tool to do a single simple task. I can't imagine why any other unix system would want this thing.
The job: To automatically start services. The tool: launchd.
Does it make sense to have four different tools to start tasks at three different times? (Boot, login, network invocation, periodic.)
- really wasteful
- it takes a long time to parse
- inconsistent (like, the sometimes-freeform-sometimes-not issue)
- quite human-unreadable
Sure, it's better thanThe creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Windows .ini files are consistent too, but you don't find fanboys harping that they're the best format since the parting of the red sea. The thing that both XML and .ini files lack is any self-documenting: you still need to know what options are supported and what values are useful for those options. XML for configs solves nothing new, and makes things more bloated by far. You move away from human readability/editability and into the realm where only a machine can fathom the format.
[
Doesn't need it? I'd say this is a quite good use of XML.
It's easily read and written by both humans (with only a text editor) and programs. I presume (but I haven't checked) that the XML is in plist format, which maps nicely to CoreFoundation/NS data types. This makes it even simpler for programs to read the format.
Sig Nature
WTF do you want to launch an interactive gui mail program in a script for?
Ever hear of the "mail" command?
Is it?
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Actually, 15 seconds sounds really wrong to me.
To keep things simple, we divide the boot process into two halves: the hardware half and the software half. The hardware half involves power-on self-tests, and the time it takes varies wildly from computer type to computer type, or even from configuration to configuration. It takes longer to test 8 GB of RAM than 512 MB of RAM.
The software half begins with the grey Apple-logo screen turns blue and the progress window appears.
From the time that happens to the time the menu bar appears (via autologin) should be four seconds on a stock Mac OS X install with middle-of-the-road hardware (dual 1 GHz G4).
that's because gentoo can't figure a good way to determine the dependancies between services so they throw their hands up and just say "parallel starting of services is bad".
i also like the way their portage system by default will upgrade an installed library and uninstall the previous version which has many binaries statically linked to it. the "solution" that keeps getting thrown around is to run some revdep-rebuild (which never seems to work for me). revdep-rebuild is suppose to find and rebuild the apps that portage broke.
Nice to see Apple take a page out of Sun's book...
Seems like it's a bit nerdy,
Oh God, no! *exits window*
Uh, the code is licensed under the BSD model. So Apple will get in trouble as well if there is patent trouble. /. will get you modded up automatically, but come on people....
I know making the statement, "boo patents!" on
Monstar L
That's what a DTD is for.
And ini files are nowhere near good enough. Read "The Art of Unix programming" for a good description of the subtle ways in which ini sucks.
Plus the not-so-subtle ways: as soon as you want to make your config file format support repeating data (eg, >= 2 mail servers where you only had one before) you have to resort to ugly hacks like:
[servers]
server1.host = foo
server1.username = bar
server2.host = baz
server2.username = qux
or
[server1]
host = foo
username = bar
[server2]
host = baz
username = qux
You move away from human readability/editability and into the realm where only a machine can fathom the format.
.whateverrc start with a hash mark? A semicolon? A double slash? C-style /* ... */ delimiters? XML-style ? Are you even allowed to have comments? Can you use nested parentheses? Are angle brackets a symbol for redirecting i/o or do they delimit XML tags? Does a pipe chain the output of cone command to the input of another, or is it a logical or operator? Replacing that mess with a single standard format will make things *more* human readable IMHO, and it will certainly make it easier to have a single integrated pointy-clicky interface for changing all those configuration options.
You're looking at this from the perspective of someone who understands and remembers the differences in a dozen config file formats. Most people don't.
Do comments in my
0 1 - just my two bits
if you want to document your xml config file format, you can give a schema (xsd) or dtd for your document. you can give all the information about al l the supported options for the config file in your schema definition.
xml is more robust than its property file counterpart.
Pet buzzword?
Signature Pro version 1.13.2-3 release 83.5 beta3try7 after-breakfast edition
.ini has the serious disadvantage of not allowing for more than two levels of properties.
:p
But don't worry. I've once used a mmapped structure to make sure the config gets preserved over crashed -- but fortunately, someone beat me back into the senses. Try to exceed _this_ level of brain-damage
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
We do need a replacement for our boot process. Boot GNU/Linux systems is slow. We want processes to be able to start concurrently, or in some cases, with specified pauses. If non-essentials (print server, etc.) start a few seconds after the log-in screen appears, I can be functional faster. We don't have a good system in place now.
We need a replacement. launchd isn't it. The problem, fundamentally, is XML. XML is a problem since, fundamentally, it is very flexible formatting, and so doesn't play nice with shell scripts. You can't easily cut/sed/etc. xml files. Until we get a suite of replacement tools that can easily modify XML files from shell scripts, XML won't cut it.
One of the key things to a good system is to make easy, common things fast and easy. The minimal overhead for any program that modifies an XML file is way, way, way to large to want to use it as the standard system format.
But it's more than cron, it "incorporates inetd, init, mach_init, System Starter and related services" according to apple... I'm not sure I'm that happy with it including everything but it's features sound damn impressive, and I do hope we see something like this for Linux/et-all.
Speaking of which, back in about 1995, I think it was, I installed my first Linux distro that I actually used on a daily basis. It was an early version of SuSE linux. Anyway, as I scratched deeper and deeper under the surface, I came to the conclusion that the init system was a mess... the entire system's functionality was implemented as piles upon piles of shell scripts, organized neatly into a whole bunch of directories, and activated according to their name and whatnot. This seemed kind of dumb, actually, because it meant that startup, shutdown, and switching runmodes were a lot less efficient than necessary, and also because you'd have to search through a zillion (that's a big number) scripts to find what you need.
A few years later, in 1999 or so, I tried FreeBSD for the first time. (Here it comes, I'm gonna be modded troll for starting another BSD- vs. SYSV-style init script war...) There, the functionality is still implemented in scripts, but there was a much more sane system. There is one script that is the same across all FreeBSD installs of that version. Then, there's the script you get to customize if you want. There's one more file, and that's where you simply give yes or no answers, or provide other data, in the form of environment variables that influence the running of those two scripts. It's so simple, and works quite quickly. Also, since you really only mess with one file, and two if you modify the script, it's much easier to find where things are. It's more efficient, from many standpoints.
So I don't blame Apple for getting rid of that SYSV stuff. It might have been cool back in the day, but it has lost its luster.
Macs don't have hibernation. They have sleep and that only takes a couple seconds to fully wake from.
I think I was going for like a book title, where all imporant words are capitalized, but I think I was also trying to stick to the Unix style 'all program names are lowercase' thing (even though OS X, which this is all about, isn't case sensitive). It was all kinda subconcious. Ah well. =3
Not only that but looking at the rest of the plist syntax reveals that this thing is waaay cooler than cron. It allows you to set user, group, chroot, check dependencies, designate where to send input and output, set resource limits and whole crapload of other things. Sure you can do this all from within a script, but this thing gives you all that for free.
This thread, so far, seems to be filled mostly with "Ah! Someone's doing something differently than UNIX has for 30 years! My knee is jerking!" So I feel I should respond.
launchd is neat. It's not simply a different way of doing the same things, it lets you do different things.
Like automatically evaluating dependencies between daemons, starting them in the right order, and running them in parallel if needed. FreeBSD's the only other OSS system I've ever seen do this; Gentoo does the dependencies but not the parallel startup. (Which is annoying while it's, say, trying to get an address from a nonexistent DHCP server.) Long story short, it dramatically reduces boot time, while eliminating dependency hacks like runlevels and numbered scripts. (Not that BSD had them.)
For those of you who posted without reading the manpage (or administering an OSX system), it also lets you do init-style startup tasks on a per-user basis. You can configure it to start daemons and other processes on the behalf of users as the log in, and shut them down -- gracefully, not by TERM; KILL -- when the user logs out.
Anyone who's ever dealt with the myriad of hacks to get ssh-agent in place will understand why this is good.
There's a lot of resentment these days toward anyone who does something that's perceived as "not the UNIX way." Change is the only way to innovation, people; perhaps the UNIX way is broader than you thought?
Yes!
If you provide an XSD Schema someone can easily load up the configuration file in an editor that knows how to provide xml completion for your xml config file if it knows what the schema is.
So if I type tag.
XML is a GREAT configuration format. Plus people say xml is hard to parse? What the heck!?!? It's the most parsable format out there with dozens of FAST parsers and tools for dealing with it. There could be nothing more open and less proprietary than XML.
No, you've covered them all.
Yeah but that's only one widget a time, you can't modify the one I tested (sticky notes). There's got to be a hack for this.
This guy is way out there
Statically linked binaries don't care if the system libraries move. That's what static linking is - the opposite of dynmaic linking. Upgrading libraries that are dynamically linked can cause problems if the upgraded libraries change the interface in a non-upgradeable way, but that doesn't happen often.
You need to get rid of the tilde and run stable, among other things (such as using "uppercase" in sentences).
Then why not YAML? YAML is as flexible as XML and has the benefit of not being a hugely wasteful format, spacewise. YAML is sort of a text representation of the [String, Hash, Array] layout that Perl and Ruby use. It would work very, very well for a config file.
Are you familiar with init? inittab is extremely simple if you're not braindead; the same goes for SysV rc scripts. There's no compelling reason to use XML here. OK, maybe it was easier---"we'll just drop an XML interpreter into init."
No bloat there.
-rsw
Good thing i did not forget my tin-foil hat!!
Why the hell is the user forced to wait through the RAM test? All that has to be tested is the portion needed for booting, and the rest can proceed in the background, with RAM becoming incrementally available to the system as it finishes testing.
This takes a significant portion of the boot time, and is nothing but piss-poor lazy design. If you add all the minutes wasted over all the people who use the OS over its life, that's a hell of a lot of man-hours.
I don't understand the guts of launchd, but wouldn't it be possible to recode it to use simple (and in my opinion, superior) text-files?
When a true genius appears, you can know him by this sign: that all the dunces are in a confederacy against him.
It all sounds more or less like the servicemanager under windows nt+ (or whatever it is called). That one also(?) keeps asking the 'daemon' (or service as they call it) what it is doing if it has sent it a startup or shutdown message.
I might be wrong though, has been a while since I wrote a service for windows.
www.vanheusden.com - home of Multitail, HTTPing, CoffeeSaint, EntropyBroker, rsstail, bsod, listener, nagcon, nagi
Is there a way to make Dashboard widgets sticky on the desktop?
You don't want them to. One of the benefits of the Dashboard layer is the fact that when the Dashboard isn't visible, the widgets are completely suspended, consuming no CPU cycles at all. If you put a widget on the screen outside the Dasboard layer --which of course you can do, if you run Dashboard in debug mode --it'll execute its run loop all the time, sucking up CPU cycles unnecessarily.
There is a method for detaching Dashboard widgets described here.
This lets you keep as many widgets as you want on your desktop, and they don't jump back into the Dashboard every time you display it.
The one remaining annoyance is that they float above all of your other windows. Hopefully there will be a hack for this soon.
It replaces cron too
The article summary wasn't incorrect, it was just incomplete
Well, not exactly what you want, but the Stickies program is still there... so you could just use the old stickies.
Repetition does not transform a lie into the truth. - FDR
Oh yeah?? Well...
</paranoia mode>
So there.
In my opinion, XML is a lousy design for human text editing. Way too unvieldy. Look at e.g. YAML (http://www.yaml.org/) for an example of how to do this more human-friendly (and with less waste for the machines involved.)
Alas, XML became a standard and Apple use it all through OSX, so it's reasonable that they use it here, too.
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
And your system won't work anymore, either. The order is important, and if you just add a "&" to the end of the commands, you lose control of that. Conventional init satisfies dependencies by prefixing the scripts with numbers indicating when they are to be launched - S10network, S12syslog, etc - and doing so sequentially. But this is overly conservative; the whole system doesn't start until a single service does, even if nothing depends on it. It also means you have to maintain a total order instead of a DAG, which sucks.
NetBSD 1.5 replaced init, too. See The Design and Implementation of the NetBSD rc.d system for details.
There was also an IBM article called Boot Linux faster on replacing initscripts with make. (This is less weird than it seems. Correctly resolving parallel dependencies is what make was designed to do.)
So Apple's not the only one to see a problem here and replace it. I don't know why the major Linux distributions haven't yet; the init system really sucks. Hopefully they'll take a look at launchd, which I believe is open source.
They are just programs. There's no way for it to tell how they relate.
You're looking at this from the perspective of someone who understands and remembers the differences in a dozen config file formats. Most people don't.
Dozen file formats? um no, only one format, just plain text. And actually he's looking at it from the perspective of someone who can read text files. Making the text files huge and cryptic, humanly speaking, does make it harder for remote administration by humans
Be that as it may, apple is probably more concerned with making it easy to configure all that with a local GUI tool, than they are with any sort of remote administration manageability
daemontools and the free-er clone runit which both give you the advantages of a non-linear system startup process, automatic service restarting, no need to write daemon-ising code in each program etc. Each author also has common tools to use with these service supervision programs to ensure network-based daemons don't need to write network code: ucspi-tcp and ipsvd respectively.
/sbin/runit instead of init from then on; we tend to use it on top of the existing init scripts.
:-)
Brave Deian owners can apt-get install runit-run which will start your system with
And the system that's had such a sensible service supervision system since the year dot? Windows NT and its service control manager. Of course you could argue a centrally-controlled daemon restarter is much more of a priority when you expect your daemons to crash more
Matthew @ Bytemark Hosting
Ye Olde cron is still there and running. My Bashpodder script still runs on Tiger. As for launchd, I am going to have to read up on that. Sounds interesting.
Are there schedulers better then cron? You bet. As a scheduler for home use, cron is fine. We are currently trying to find a ore robust replacement for cron that will attempt to correct things before reattempting a script and with dependency checking. When I used to be a operator on a DOS/VSE based mainframe, our scheduler had a dependcy check that would hold jobs from running at thier assigned time if the previous job did not finish and other things like that. It had very robust logging to. No e-mails to root. I could just run a report. There are schedulers that come close to this on UNIX but cron is a very basic scheduler that is flexible which is a saving grace.
Gorkman
cron, init, et al. were all doing basically the same thing: starting up processes. Quite frankly, I think this system is great; I'm no Apple-head, but I have to confess that *nix boot-up can be nightmarish. On a server that's rebooted maybe once or twice a year, this is acceptable, but on a laptop, something more substantial is needed. launchd seems to provide this, and while it may do separate tasks and violate the "UNIX philosophy" to some extent, there are cases when having a unified tool for separate but similar tasks can make a system run much more cleanly.
Solaris 10 has something very similar to launchd called SMF: Service Management Framework. It doesn't replace cron but it does replace init.d and inetd. It also provides backwards compatibility so that existing init.d scripts and run and existing inetd entries are migrated to SMF on upgrade.
SMF also does dependancy checks and auto matic restart on failure (or some other conditions). It also uses XML for its configuration but imports that into an SQlite database so that it doesn't need to reparse the XML on every service restart or system boot.
For more information on SMF in Solaris see the links in the main architect/developers blog .
Your reply sounds like it comes from a geek, or perhaps wannabe geek. Well, just check out the source and tell us. http://www.opensource.apple.com/darwinsource/10.4/ launchd-106
gentoo can't figure a good way to determine the dependancies
Thats wrong, it can and does. It also does parallel startup....
which has many binaries statically linked to it
You mean dynamic linking, not static.
the "solution" that keeps getting thrown around is to run some revdep-rebuild (which never seems to work for me).
The "problem" only exists if you do things that have a "DO NOT DO THIS IF YOU DONT KNOW EXACTLY WHAT IT DOES" written all over them (like emerge -C dependencies).
revdep-rebuild is suppose to find and rebuild the apps that portage broke.
And it does - by analysing the packages with ldd. If that doesnt solve you problem, you fucked up your system pretty bad (unmerging stuff from 'system', compiling 'system' packages with ggc4 or the like). Just because you can do it, it doesnt mean its a good idea.
There have been several comments along these lines. I don't understand them at all.
The launchd configuration files are property lists, which are serialized Core Foundation data structures. They consist of key-value pairs. They map directly to data structures in memory. The code for parsing them is used all over the place in Mac OS X, and is very old. It dates all the way back to the first development in the late 1990s. It's highly optimized, and it's reused over and over and over and over again.
The second advantage to plists is that they're self-validating. When a program tries to load a plist, if the file doesn't validate against the PropertyList-1.0 DTD, nothing happens. An error is returned, and the program (in this case, launchd) moves on. No chance of a corrupt file producing unexpected results.
The third advantage is that we ship a handy property-list editor with our operating system. This makes it easy for developers to create and modify plists.
Finally, plists are always in UTF-8 format. That's vitally important for us, because our system is fully localized. We have to be able to launch services with names that don't fit into the ASCII/Latin-1 character set. Using plists ensures that we can do that, and gives us that capability for free.
The question here is, why would anybody want to invent their own proprietary ASCII-only, non-validating file format for something as important as system startup control?
"So, for the next few years, we will now have one more system to use, complain about, introduce new problems, and work with."
This system replaces a *handful* of systems. You're content with having four, five, six systems to deal with, but not with another one that, while obviously not perfect, can *potentially* do a good job in replacing the rest of them, already has proven to increase performance wildly and is open for modifications?
Over the last 15 years using UNIX on everything from System V on an At&T 3b20, Dec VAX, Sun/dec workstations, HP mainframe class machines, and of course linux/x86 my conclusion is that through inertia we are still stuck with many of the terrible to use UNIX utilities.
With some luck, LSB or equivalent project will figure out that bad directory structure + lack of decent system configuration utilities + bad command line utilities == end user unfriendly systems.
The problem with XML is that it is big and bulky. It will take the system sometime to parse through the whole thing.
Um, yeah, parsing XML on a 486 would be pretty slow. Apple doesn't ship computers that slow anymore.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
The plist format can easily be parsed into the standard system collection opaque types (dictionaries, arrays, strings, numbers, etc) by the frameworks.
There are a bunch of things in UNIX that are, well, showing their age: cron, init (in its various forms), inetd, etc. It's not hard to improve on them. In fact, there have been lots of improved versions. But, in the end, it doesn't make enough of a difference for people to break compatibility.
Apple should think carefully whether they want to move even further away from UNIX sysadmin standards as they already have.
MacOSX programs make frequent use of NSDictionary, a Objective C collection class. There's also a C version, known as CFDictionary. It's worth noting that most of the relevant C interfaces, known collectively as "CoreFoundation" are open source
The CoreFoundation interface to MacOSX's built in XML parser is described here.
Upgrading to Tiger moved my cron jobs over to launchd. No problem, but now the scheduled jobs seems to run an hour later than they should. Something scheduled for 3:15 runs at 4:15, for example. Not a huge issue, but my Mac is set to wake up at night to run these jobs - doesn't work so well if they don't fire at the right time.
Has anyone else seen this? Any ideas?
Crond works, but it's old and outdated. The wheel was the meca of inventions, but I'm damn happy someone decided to create the rubber tire as a stone wheel on my car would suck!
:P
I'm not a Mac guy. I don't even really like Steve Jobs, but this is a good thing. I'm not a Windows Server guru either, but this appears to have many similarities to the Windows Services. I'm not going to give Apple credit for the innovation of such a service, but I will give them lots of credit for bringing it to *nix.
Thanks Apple.
btw, just because I'm not a Mac guy doesn't mean I don't want a dual G5 running OS X
SRC's been around for a while (AIX 3?). The Solaris widget looks like Sun thought it was a good idea.
I'm not entirely sure I like it but it's there and it pretty much works. It does mean there are different start/stop widgets on different operating systems and as an administrator that pisses me off.
Deleted
Back on topic, I hope other *nix take a similar approach. Perhaps Apple could Open source it. How about instead of being an annoying and negative ass, try reserving judgement until you see it in action?
Jesus was a compassionate social conservative who called individuals to sin no more.
the code is licensed under the BSD model
No, not really. It's licensed under APSL, which is (as far as I understand the license) very simmilar to the LGPL.
I was counting the entire process.. from the time I hit the button on the computer to the time I get a desktop.
I am the Alpha and the Omega-3
Hmm. So you think that this XML-based solution is bad because XML makes everything slooow. Interesting. Especially considering the fact that launchd reduces boot time from a minute to under 15 seconds. While XML itself might make some things slower, in this case it allows for processes to be launched concurrently on startup, rather than one at a time. The overhead of parsing an XML file is minimal compared to the speed gains launchd allows.
Pack up your anti-XML trolling and bring it elsewhere. It has some good uses. I very much doubt that you'd be happier with it if they used some proprietary, non-readable format instead of XML since it would save them all of 0.025 more seconds on boot.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
I'm not an expert, but from what I read of the XML files, launchd seems more of a wrapper program than a replacement for cron. Translated: ProgramArguments = /usr/sbin/cron;
QueueDirectories = /var/cron/tabs;
ps -wwax|grep cron # shows two cron processes in memory;
So launchd takes the place of init, and starts up cron, with the proper arguments. Cron then takes care of its own.
Put away your "windoze suxors" fanboy attitude for a moment and take a look at the bloody thing before you judge.
Jesus was a compassionate social conservative who called individuals to sin no more.
Basically, cron needs higher resolution, that's my only beef with it. It also seems like to do anything facny with cron you end up writing a program to do it and it's not that uncommon to do that.
The startup scripts need an all together different kind of overhaul. I've been working on Linux appliances for over 6 years now, without exception, it seems like someone ends up writing some kind of "health script" that is kicked off by cron every minute or a few or is a daemon in it's own right that watches for things to crash or not be running and then it restarts them. I've seen it in a production set-top box based on Linux where we essentially wrote our own init and had it treat some processes special and 5 different software appliances. Fact of life is software crashes from time to time. These scripts then do something else, like ping the gateway or something stupid to check if the network went down before they do what it is that they do. To make matters worse, they are always written in Perl by some guy who doesn't know Bourne shell to write a good startup script in the first place; that's the part that chaps me. Rather than contaminate the system with all this extra shit we should just have an easily extensible and configurable system process starter and monitor and it shouldn't require scripting to do anything advanced.
There are probably some things I forgot, it's really not that much, I could see bangin' this out in Python or java in not that much code. My thinking is that instead of checking for a PID file or grepping through ps outout to provide "status" you query a running process and it tells you your proc is up and running. Yeah yeah, I know, shit shouldn't crash and whatever. I've just seen such a shitty job of this stuff being done over and over and even on fairly stock installs of major linux distributions I've seen service
Yeah, no kidding. I must boot at least once every few months or so, so pretty soon that's going to add up to...uh, a couple of minutes.
An Apple developer posted to the darwin-users list, what now seems like donkey's years ago, that the idea was eventually /etc/rc would go away, and SystemStarter or something like it would do all that init stuff. I kept remembering this all thru the 10.3.x upgrades as /etc/rc got bigger and more convoluted with all sorts of crap being written in there.
You misspelled "also" as "only". Having a featureful editor than groks every single config file on my system, supports context-sensitive help for each possible option, and shows me what values are legal for all of them sounds like a Good Thing. Wouldn't you like an "etc-mode" for Emacs, or GEtcEditor, or KonfigEditor, or similar?
This should also be eagerly awaited by network administrators who occasionally have to roll out the same config change to hundreds of servers. A command-line XML config file editor should be trivially easy to write, and I image "GNU etcmanager" would be available in a few months' time.
Dewey, what part of this looks like authorities should be involved?
.ini file or any other key=value file IS in fact an XML file. It just has invisible tags ;-)
Well architected XML with a schema is designed for human readability and to let you know what options are available, as opposed to most config files, which give you the most minimal of hints as to what you can do. Rather than having to dig through obscure manuals to find out what options are available, you could look at the schema, or better yet, open it in your favorite validating editor (emacs has a nice plugin for that). You'd never have another invalid config file, with proper use of validation.
:)
Mind you, no one seems to be using schemas for config files yet. But I predict that it will come.
And I'm not sure why you would think a human would have trouble editing XML. Angle brackets just aren't that complicated.
To truly understand recursion, you must first truly understand recursion.
Having an application as a directory is not really an apple innovation, but has existed before in RISC OS and the related ROX. Look up this page and search for 'application directory'.
That's the article excerpt in a nutshell. It doesn't explain what it does or how it does it.
Yup, that's exactly how I feel. Aside from the part about using a new XML-based config file format (I can pretty much imagine how that will look), there aren't a lot of details.
For example, startup scripts are called that because they are scripts. Sometimes they do more than just launch a program (e.g. a firewall script which sets a bunch of ipfw rules). Somehow I do not associate XML config files with scriptability. Based on what I've read so far, I have the feeling that I'm going to end up just "launching" several of my old scripts.
Likewise, I wonder what happens when you add some weird new third-party service to your machine. How does launchd know that my distributed batch scheduler needs several NFS mounts to have completed successfully? If launchd can't auto-detect this sort of thing, then we're back to scripting again, either by me or by that third-party developer.
What it boils down to is that I need to see this thing in action.
Apple has open sourced the thing, and is apparently hoping all the unix kids will take a look.
I've been poking around at Apple's Open Source page and fail to see launchd, SystemStartup, or anything else thereabouts. Does anybody have a URL for this, or know of the specifics of getting the source? It looks like promising technology, and I'd love to get my hands on a copy to play with. I would also hate to think that we're being strung along with promises of an Open system that turns out to be only partially open (like the recent KHTML/Safari issue).
As far as I know, the parting of the Red Sea -if it happened at all- wasn't related to fileformats in any way :-)
.ini files. First of all, XML allows you to store information in a more structured way: you can store it a tree, whereas a .ini file allows only one level deep "trees". Obviously, and specifically for large projects, having just one nesting level is very limiting in structuring the configuration information. This is likely one of the reasons Microsoft switched to the registry which allows the information to be stored in a treestructure, similar to XML. And projects such as Apache already use a XML-like format because it makes structuring configuration information a lot easier.
.ini files aren't. XML schemas -such as DTDs- describe what an adhering XML file should look like. So, in an XML based configuration file, you could demand that the user provides a username and petname for example, by creating a DTD demanding this information to be available. Furthermore, self-documenting formats are in generally considered files which describe the field that are contained in them. So, as an example, file "a.dat" would not be self-documenting while file "b.dat" would be self documenting:
o me_user=1: favorite_pet=dog
.ini files can't do. .ini files.
.ini-fanboys shouldn't complain to much about their beloved .ini fileformat, as the main/user and designer of that format replaced the format too.
Furthermore, you seem to miss the point about XML. There's huge differences between XML and
Secondly, XML _is_ self-documenting while
a.dat:
123:12:adf:0:1:dog
b.dat:
userid=123:age=12:name=adf:vi_user=0:gn
And yes, self-documenting formats are indeed less compact. But the "bloat" serves a purpose: Understanding the format is easy.
So, XML does indeed solve several things. Yes, files adhering to the XML specification are a lot less compact then a file containing the pure information would be, but the "bloat" is there for a reason. I'm not a XML "fanboy" at all, and I'm certainly critical in regards to the justifyability of using XML for any and all formats, but for config files, I don't see a real problem. There's projects encoding large datafiles intirely in XML, thereby tripling the size of the datafiles... that's indeed something the phrase "unnecessary bloat" could be applied for. But for configfiles... With the average size of a configfile being what... 1K, 2K, 10K? And disks being many gigabytes large...
Lastly, XML files are both readable and editable by humans as it's a true textformat. It's not a binary file which is truly unreadable and uneditable by userfriendly texteditors, nor is it someting like a BASE64 encoded binary file. So, again I can't agree with that point either.
So, to summarize:
1. XML files are easier to store information consistently, as they allow you to put more structure in your stored information by storing it in a tree structure, which
2. XML files are self-documenting, the DTD files describe the contents the XML file should follow, and shows the user which options are available as well.
3. XML files _are_ readable and editable by humans as they are plain textfiles.
4. XML files are "bloated" because they offer _more_ then plain textfiles or minimally structured files such as
So, the
Actually, after reading a bit further, it sounds like they are using schemas for validation. So, you have a simple, readable, and automatically validated config file, that can use standard parsing tools. How is this a bad thing again? Yes, your config files are, on the average, about half again as long. They're also in ASCII, so it's a drop in the bucket compared to your MP3 collection.
To truly understand recursion, you must first truly understand recursion.
We did open-source launchd. It's part of Darwin 8.
Would it be possible to convert a standard linux installation of, say, Slackware, to use launchd instead of rc.d and such? I can't see why not, supposing of course that one is a wise enough unix-fu master to actually do it. I would sure like to learn how you would go about that... I barely understand the init scripts as it is, so it would probably take me a long time to figure out. Yet, that's why I have a linux box in the first place: so I can mess with it.
--The universe will not be altered by forum threads, even those which are very wry. --Tycho Brahe (Penny Arcade)
Cron and init and rc.X work fine, I'm not a hater. However I do think it's time to move forward.
/etc/conf.d on Gentoo.
Fine, I'll bite. Here's why you're just talking out of your ass.
* Use XML for configuration, it's easy to parse, it's here to stay and I think it's a little bit better than the columns of a crontab because it's more verbose.
Ok, everyone, repeat after me, XML is *not* easy to parse. I don't understand why anyone says this. Write an XML parser. No, not some silly thing you did for some crappy college project but a real XML parser that supports namespaces, various encoding types, DTD validation, etc.
The problem with having a standard like XML is that at this point, it's incredibly heavy-weight. Hell, there's even a standard API (Dom) that's a pain in the ass for every language I've ever tried to use it for.
* Have variable restart behavior, restart, restart and restart dependancies, reboot, just let processes die, etc..
Dependencies are hiearchical. Do you mean restart everything that depends on process? That's already in, at least, the Gentoo init scripts.
* Have dependancies (start the database before the shit that inserts data in to it, even though it shouldn't matter, it does) and start them in the right order.
This is supported in a lot of init scripts including Gentoo's.
* Kill dependencies when I kill a process
Again, it's in Gentoo's scripts at least.
* Smart killing, if something doesn't gracefully go down, 9 it down.
kill -9 is never a good idea. You're dancing with the devil if you do this. You risk massive corruption of your system.
* Have some kind of health monitoring call back, at a time I specify, execute a program that will check to see if a process is okay.
This is a feature of launchd. However, I'm not a huge fan. I don't think it will help. Most apps would probably just spawn another thread to respond to these things. If another thread got hung, you would never know.
* Once all this is done, maybe support something like soft cycling, kill everything down to single user mode and then bring it all back.
It's called the 'init' command. You can already do this.
* Variable dependency notification, if I restart my database allow me to do nothing to dependant processes, restart them, or HUP them, or something I define.
You can modify the startup scripts to implement whatever behavior you want.
* Full featured logging.
As opposed to...? Have you not heard of syslog?
* At some configurable interval, sniff out all of the XML configs in this "next gen startup proc" config directory, like every 5 minutes just check for changes and if needed, start something new up.
How do you know whether when you look at the files, they aren't in an inconsistent state? Say you've got vi open on a file (and I bet you use vi) and in the process of editting and haven't closed a tag you're entering but you save because you've made a lot of other changes. What happens when the config is now reread?
* Allow for user to be specified in the config
This is already supported. See
* Allow for end users to have thier own daemons defined by files in their home directories.* Then finally, allow for cron like behavior and run tranient tasks with all the flexibility of cron.
Why even bother combining? What benefit do you get?
* Proc specific ulimits would be nice also...
ulimits on what??
* And some form of runlevel logic still.
So, reinvent what we already have?
* And startup and kill in parallel if allowed by the depends...
Gentoo supports this.
* And it should have a template for common daemon type things I should just provide a startup command, arguments, a user to run it as, and a r
I would imagine any XML config format is designed to be accessed by a GUI interface.
Yes, it sucks for terminal using monkeys, but for the 99.99999% of the people who use a GUI on their desktop, it's just fine.
Democrats or Republicans. They are both taking us to the same place and they are not afraid of us anymore.
Why would you want to waste CPU like that? If you want widgets on the desktop, look at Konfabulator.
Jesus was a compassionate social conservative who called individuals to sin no more.
Cold boot.
I am the Alpha and the Omega-3
Please note that I don't want in no way to start a flame but...
My (pretty good) experience with Konfabulator taught me that many well-designed widgets are well worth a few cycles (iCal-related ones come to mind.)
I'll be upgrading to Tiger, soon, but if there's something that disappoints me is the inability to have widgets always on screen at "topmost" level -- well, at least until 30 seconds ago when I read that I can have that via the debug options! Thanks for sharing...
At the risk of being offtopic, I'll shoot a question here right from the Ars Technica article: why no user-defined arbitrary metadata manipulation (e.g. [username]_project: 'ACME presentation' or kMyUserDefinedProperty: 'ACME presentation')? I guess that may come with third-party apps, but it seems a basic ability you'd expect from the OS...
It seems pretty well organized, but very osx specific. I wonder how much the directory structure, and the Agent vs Daemon thing can be reconfigured.
In 10.0 lookupd was launched with flags and fanfares as the way to find anything network or directory related. It had agents and lookup orders, and command line config tools. But it took Apple 4 years (= 4 major OS revisions) to realise that nobody else would use NetInfo, and Open Directory was a safer bet.
launchd has its own lists of agents and daemons each with their xml config (plist). Expect to see launchd shuffling its options for maybe four years before it too settles down.
Er... Why pay extra money for Konfabulator when I have Dashboard that could easily do the same thing? Actually, persistent widgets seemed obvious to me, I'm surprised you need to 'hack' Dashboard to have them...
(no "who copied whom" flames please!)"
http://arstechnica.com/reviews/os/macosx-10.4.ars
It's a long read, but it's engaging and very informative. I cannot recommend the article more highly.
It's part of Darwin. Try this page: http://www.opensource.apple.com/darwinsource/10.4/
From your example I can see you don't know much about XML. Or about config files.
:host "foo" :username "bar") :host "baz" :username "qux"))
<servers>
<server>
<host>foo</host>
<username>bar</username>
</server>
<server>
<host>baz</host>
<username>qux</username>
</server>
</servers>
See the way that the "servers" element can contain *any number of* "server" elements? *That* is why XML beats ini files for all but the most trivial configuration files.
Of course, all applications start out with simple files. But as they grow, the files get more complex, and the programmer inevitably ends up kludging together their own ways to extend their ad-hoc format.
Since the feature creep in the ad-hoc configuration file format is occurs gradually over time, the programmers who implemented it don't notice that they have wasted so much time writing their own lexers, parsers, preprocessors, processors and so on. Nor do they care that their configuration language now requires a newbie to invest quite some time in learning all its ins and outs.
Wait a second, this sounds familiar... ah yes, Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden and slow implementation of half of Common Lisp."
Speaking of which, I'd be just as happy if the above config file contained:
(servers
(server
(server
By the way, any XML parser would have told you the exact row and column in which you screwed up your XML.
That sounds like marketing talk to me, although I don't know how resource intensive Konfabulator is on the mac. In Windows XP with 3 widgets open, each of them has used A WHOLE SECOND of CPU time for 25 hours uptime. Big deal.
Adding dependancies to core services is always bad. It adds potential bugs, security and reliability issues, etc. Its all just a question of wether or not that new dependancy adds enough benefit to outweigh the downsides. XML does not add anything here, the tools involved are not using all kinds of different config file formats or any other such nonsense, they are simple shell scripts. And just because the XML you make is valid, doesn't mean it will actually do what you think it will, you still have to test your changes just like you do now. Downsides and no upsides add up to a stupid idea.
And no, init and cron do not do the same task, saying "they both start services" shows a complete lack of understanding. Starting a program is just fork(); exec();, this is trivial, done by tons of software, and is the only thing they have in common. The majority of the code of init and cron have nothing to do with this, and are not at all the same.
Your shell does fork(); exec(); all the time, but that doesn't mean its "pretty much the same" as init, cron, sendmail, and apache. Or did you guys want to mash all those together with an XML library too?
And none of this is needed to be able to start services in parallel. Shell scripts can do this just fine, and that's what you init scripts are. Just because current linux distros seem to universally choose hideous sysv style init scripts, doesn't mean they couldn't do it another way. NetBSD's init scripts could easily be changed to add parallel service starting, if it doesn't already support it.
Just curious... got some examples that show he's *not* from Apple?
I'm guessing the fact that he posts consistent, clear thoughts that illustrate his point of view is reason enough to label him a troll. I mean, he doesn't misspell words AND he dares to challenge long-standing *nix groupthinks - what more evidence do you need?
In short, all I'm seeing so far towards the guy is backlash from people mired in groupthink. They like doing things they way they've always done things, and there's no reason to change things at all - and let's not even get started on that GUI fad, it'll be gone tomorrow, CLI is king.
You're making a big assumption here - that the previous system was well organised and correct.
...then launchd still seems like a good idea as it reduces unnecessary daemons.
If it's all about kicking off processes, then launchd seems like a good solution. If it's about kicking off processes at boot-time, kicking off processes periodically, kicking off processes at others times, etc...
I'd say that it's in-line with the UNIX philosophy - it's all the same task, after all. One task, one tool.
In all fairness, it sounds like you're the one who's ignoring the elephant in the room. If it's taking five minutes for your laptop to pass POST, you need to take it in for repair. It's obviously got a hardware problem.
> You don't want them to.
Says you. I could see the point of many dashboard widgets being simple, easy to access utilities. My 'killer app' would be the calculator.
However, calculators don't work in a vacume. I would want it to be visible while I am working in my other application (say OpenOffice), so that I can use it in conjunction with my main app.
Yes, yes. I know that OSX has a perfectly functional calculator appliation. The point is that I don't want to hunt the dang thing down to use it. I want it in a place where it's easily available (and I don't mean the limited real estate of the dock).
Having the OPTION of making a dashboard widget 'sticky' to the desktop (at least temporarily) would be very desirable, indeed. And it should be as easily banished to the Dashboard layer, so that the Dashboard engine no longer sucks up CPU cycles.
And if you don't mind me saying so, "You don't want them to." smacks of hubris to me. You don't know exactly what I want, do you?
jf
launchd is also capable of automatically checking for dependencies and scheduling services to startup in the correct order. It can even start services in parallel which speeds up the boot process.
If you'd like one of your Dashboard widgets to be available all the time, instead of only when you have activated Dashboard via F12, then activate the Dashboard dvelopment mode. Open the Terminal and type
defaults write com.apple.Dashboard devmode YES
and press Return. Then logout and log back in again. Now debugging mode is activated. To get a widget off of the Dashboard and onto your desktop, just do the following:
Activate Dashboard by pressing F12 (or whatever key you've assigned to Dashboard).
Begin dragging the widget.
Press F12 again, before letting up on the mouse button.
Drop the widget wherever you want it.
You can do the same thing in reverse to drag the widget back onto the Dashboard. Also of interest: while a widget is frontmost, you can press Command-R to reload it. (This may be necessary if a widget is buggy and gets messed up somehow.) There's even a nifty Core Image-based twirl effect to accompany the reload.
If you are one in a million, then there are six thousand people who are just like you.
Activity Monitor says that's wrong. I decided not to use at least one 3rd-party widget because it was using a few % of CPU in the background. Several of the widgets showed above 0%, actually.
Shouldn't that be "1 0 Just my two bits?"
I did some poking around my laptop and see that for all of the events that were previously, by default, in /etc/crontab now have individual plist files in /System/Library/LaunchDaemons . Makes it kind of difficult to manage your schedule, but now it's less likely for a ham hand to screw up the crontab. I fail to see how having scads of plist files is better then just putting a entry into /etc/crontab for each thing that needs run. One upside is that Apple does provide a plist editor that works pretty well and makes editing the files much easier. At least if you put a entry in your user crontab it still works. In one of my earlier posts I had misunderstood the poster as saying everything was in a single plist file which would be bad, but I am not sure on how this would appear to be better then just the files we have always used.
Gorkman
If you can't figure out an xml plist config, then you are not smart enough to be in the shell.
I'd rather deal with "hard" stuff like xml tags than "easy" stuff like switching with screen to the man page over and over again...
You scared people clearly don't understand plist files and how they represent records and lists.
plists should be used MORE than just infrequent things like rc/cron... as far as I'm concerned all configs should be plists.
As for xml being slow...a standard parser may beat a custom parser; besides, configs are not read constantly, which is why xml is well suited. (especially for rc/cron...cron: I doubt it parses unchanged files repeatedly)
Democracy Now! - uncensored, anti-establishment news
Just be glad I didn't throw a comma in there somewhere. You're like Magneto in a sea of mutants.
WARNING: Smartphones have side effects--most of them undocumented.
It seems some moderators have not read the Moderator guidelines. You should not mod people down, because you disagree with their opinions.
Apple's plist stuff is an abuse of XML. All those keys should have been XML elements so that I can actually validate the configuration using a DTD or a schema, not just the key/value structure.
It's also maddening to use XPath on a plist. I once needed to use Apple's iTunes export format to programmatically recover from a disk failure. The plist format made it difficult to get at the information associated with each file that I was missing.
I've used sed on XML files before, in a pinch. It works, as long as the XML has decent per-line formatting.
What would be cool is versions of Awk and Sed that XML aware extensions and could do things like identify and work on or replace tagged sections.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
If you are looking for something like launchd, consider using just that - in the Ars Technica article recently posted (a good starting point to read up on what it does) they mention that in a rare move for Apple they are offering it as a standalone open source project for anyone to use. I've not looked into the details yet.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I got Trolled for yes a bit of a rant but not way overbord the other day it's a Mac Snob thing.
Luckly I said enough about Linux in the same rant some one moded me back up as intresting. then back to a new one came back and trolled me again 70% troll 30% intresting.
Who cares what the mod is it was a good question about the article.
Thanks
I'd Tell you all my secrets but I lie about my past
....with middle-of-the-road hardware (dual 1 GHz G4).
Oh heck
What license? You know the community doesn't like the Apple open source license much.. Not to sound ungrateful if it is under the APSL then I doubt there will be much acceptance from the linux guys.
*All* macs I've come across since OS X debuted have this problem.
Mine doesn't, and I'm still on Panther.
There are two things you can do. One, hold Command-V to boot in Verbose mode and watch Unix stream by, which might show you what the problem is. Or, since it might go by too fast, you can just go to Applications->Utilites->Console and look at the System Log from there. It might help to go there, clean it, and reboot since I'm not sure if it cleans itself each time.
Did you install OS X on an older system, or did it come dual-bootable? If the former, there may be a disk error that fsck catches each boot but can't fix if you never enabled journalling. You may need to boot into single user mode and repeatedly run fsck. I used to have to occasionally on my iMac up to 10.2; I think older programs running from booted in OS 9 would do 'odd' things. I know running OS 9 Norton really messed it up once; never run it's optimizer/defragger again! OS X doesn't need it, and running in OS 9 only introduces problems.
Anyway, It does sound like it's your computer, whether it has problems or is simply old.
R: That voice. Where have I heard that voice before? B: In about 365 other episodes. But I don't know who it is either.
Ah, excellent. Thanks for the info!
1. It's not about figuring it out. Just because you can figure something out doesn't make it optimal or even non-crap.
2. The grandparent post was talking about XML in general and how it's great for configuration data. That is what I was taking issue with. You can build record/list support on top of XML, but it doesn't fit in naturally.
3. I still think the property list XML format is crap. Property lists are decent; they're not perfect, but their extreme simplicity makes them very useful. The ASCII format is great, so why would you want an XML format?
Does having an XML format lets you leverage XML tools? It might have if property list XML worked with XML instead of simply beating it into submission. Apple created a completely opaque layer on top of XML instead of integrating directly.
A natural XML equivalent would be a little more verbose: Using Apple's XML format, you'll get:The result: something that's more verbose and harder to read than even a natural XML format.
What's worse is that you can't leverage DTD/Schema as much as you could with a natural XML format.
If you turn off your computer when you're not using it, thus saving the environment, then by reading slashdot you are harming the environment. Is it really worth it to you to damage the planet over just slashdot?! How can you be so selfish?
And oh yeah, my computer does a lot of stuff, even when I'm not in front of it.
With the average file it takes less than a second for a person to figure out how things are delimited.
Not if that format is XML.
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
Haha. I didn't know we looked like that. Wasn't it the pro-XML people that were the rabbid ones? I wonder when the tables turned.
In my defence, I was only responding to a very pro-XML comment. The again, the guy who brought XML up in the first place was a member of "our" camp, I suppose.
If you think this was just a coincidence, you're fooling yourself. We're happy to share code with people who don't compete with us.
according to googlefight...
no!
that's a hell of a lot of man-hours.
It's precisely zero man-hours, unless some person is bent on staring at the computer while it boots.
Flamebait!? As far as I know:
Hibernate -> write contents of RAM to disk and power off; restore contents early during boot up and resume
Standby -> put CPU and other peripherals that eat power to sleep, maintain contents of RAM
Why don't you...
... and save the rest of us the irrelevance of your pathetic posts.
* print out your post
* take the page outside and find the tallest tree you can find
* nail the page to the tree
* wrap it around with barbed wire
* stick the whole thing up your arse
* think about how pointless your life is
* die in agony
The part where it seems to have gotten hung up (big gaps between timestamps) is here:
Any idea what that means?
(full log follows)
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Why share the code at all if it's license is designed not to be liked by any of the linux people? Who else will use the code?
I can't see the motivation.
For those of us who don't use Notepad, it's also fine.
Oh, key-value pairs! It was really hard to handle those before XML!
This is retarded... how hard was it to validate text config files before you started using XML? Each line either has a properly delimited key-value pair, or not. The values are either useful to the program, or not. It's not brain surgery.
AWESOME!
Like you needed the XML albatross for that.
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
Are you running Tiger? Or are you running 10.3.x? And if you're running 10.3.8 make sure you update to 10.3.9. I was having long login time issues (> 1 minute 30 seconds) and after update to 10.3.9 it went down to 8 seconds.
http://www.rootstrikers.org/
To make it easy to edit the files both by hand and via utilities which can be written very easily by leveraging existing XML parsing libraries?
Sorry but I have to agree with the grandparent. XML for configs is a HORRIBLE choice. Here's some reasons why:
Personally I would actually prefer a binary format to XML. If you can't read it or script it you might as well get the speed of a binary format.
Actually what really bugs me about using XML for configuration data is that shows that the designer did not understand that the FORMAT of the data is not the problem. It's the INTERFACE that matters. If they had they would realize that DOM and SAX are horrible generic faceless interfaces. Store it however you like but provide INTELLIGENT APIs for querying and storing the information.
Admittedly, they are still easier to use than the majority of the admin tools out there that do the same things... but damn, if Apple normally only did 'better than the majority', they'd be out of business five times over by now.
-fred
Sign #11 of Slashdot overdose: You see the phrase 'moderate Republican' and you wonder if that would be a +1 or a -1.
An hour? Just how did you measure that?
What percentage of the boot process is the RAM test? I have no idea, but let's pretend it's 5%. And let's say they could cut down the RAM test by, say, 80%. That means the boot time would be 96% of what it was. If that saves you an hour a week, that means you currently spend 25 hours a week just booting up.
I'm taking the unders.
Some PCs have an option where you can basically skip all the tests and go straight to booting. When I turn on my crappy Dell box, it's well on the way of booting the OS once the monitor has warmed up (and that's about the only thing that Dell is fast at...)
On the other hand, I have a HP Vectra with 1GB of ram, and it insists on testing every byte of it every time it's turned on. Very annoying.
That is actually not true if by "the hardware half" you mean the procedures that are actually burned into a ROM (the program called the BIOS on IBM PC derivatives).
You can boot OS X in "verbose" mode (it's something like holding Ctrl-Super-Alt-Meta-Cokebottle-V, or maybe just Cmd-Opt-V, during the boot chime) and see the console output that the grey apple logo hides from you. It does come from OS X, and it is not the same as what you get if you run, say, Linux or BSD.
I do think that very likely the grey->blue transition you speak of marks the transition between the initialization of the kernel proper and the running of the init scripts, but I am not 100% sure of that.
/usr/share/morlock
This isn't really a problem for most people, anyway, since RAM tests are only done upon "cold boot" (turning the computer on after a complete power-off).
Because the source is easier to understand? If there is a problem with one subsystem you can turn it off without affecting another? I can turn off atd and have cron running. I can turn off inetd if I don't need it. I can modify inetd without worrying about messing init.
What if there is a security hole in their daemon? I can't turn it off (or remove it) because that would kill the system. If there is a security hole in cron or inetd, I can remove those.
Put away your "windoze suxors" fanboy attitude for a moment and take a look at the bloody thing before you judge.
Where did I say "windoze suxors"? I think you need to lay off that acid a bit (or crack!) My post implied I didn't like Windows methodology (which I don't), not that "widoze suxors".
One problem with cron is you can't run something on a specific date if that date is too far out.
For example, let's say you need to run a job in 3 weeks. Easy, right? How about run it in 12 months and 1 day from today. Well hmm, looks like there's no way to specify that, because if you specify it the way you think, it'll run tomorrow. Doh!
That's an irritating limitation that you can get around by using "at". The problem with 'at' is you have no idea what queue number your file is, so if you want to cancel a job you have to run through the at queue, look for a telltale, then use that to figure out the queue number.
Gee, what a PITA.
Why not have the ability to schedule a job at a specific time (returning a token), then be able to manipulate that job using that particular token?
I have no idea if launchd does that, but pratically every other scheduler on earth does. -That's- why it's better to replace all those annoying and limited utils with one that's built-in and supported.
Apple's original plist files (from the NeXt days) used a syntax similar to Perl's arrays and hashes, so the parent's example would look like this (roughly, I'm typing from a hazy memory):
{
"Label" = "com.example.exampled";
"ProgramArguments" = ( "exampled" );
"OnDemand" = "false";
};
This format is backward compatible, so if you hate XML (or Apple's XML-Lite) you could use this format for configuration files.
launchd summary:
- Not Free Software.
- Violates Unix Design Ethics.
- Proof that even the best proprietary development teams still don't "get it".
Thanks, Steve, please try again.
This is retarded... how hard was it to validate text config files before you started using XML?
Harder than using an already existing XML parser and validater.
Like you needed the XML albatross for that.
Yeah, it might take a whole 8 milliseconds to parse an XML file when it could parse a flat text file in 4.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
Yeah, no shit. It's not like D/BUS has ever been been mentioned on slashdot.
Stating on Slashdot that I like cheese since 1997.
It runs things at specified times
Exactly, but when cron was written ages ago, UNIX mainframes were not portable and ran 24/7. If I shut off my laptop overnight and start it up at 9 am, my 3 am cron job will never run. Wouldn't it be nice if my delayed cron jobs could run on startup?
Right now, I use cron to run a script to process files dumped into a directory, but it does not run less than once a minute and it will run every minute, even if the directory is empty. I'd like a cron job that runs only when there is something in the directory and can run multiple times per minute to process multiple files.
launchd can do this and more.
Why share the code at all if it's license is designed not to be liked by any of the linux people?
I'm gonna let you figure that one out yourself. The answer is pretty obvious if you ponder it for a sec.
Who else will use the code?
Anyone who wants it.
I don't know what you're doing with your machine, but my iBook G3 / 700 only waits about 5-10 seconds at the grey screen.
YOUR WORDS WOUND ME.
Yes, receiving positive moderation is the height of achievement. Why didn't that ever occur to me?
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
On a modern desktop OS, how often do you start the system without cron or inetd?
Oh, that's right: never.
For OS X users, combining the functions into one program that handles failure gracefully is the right call.
Hmm, I cannot see Sun or IBM, both hardware manufacturers, using code that their right to it would be revoked if they sue apple for anything at all.
BSD people... I would guess they feel the same as the linux people - but that's just a guess.
It's part of Darwin (the free, APSL base of OS X.) The source is included in the other source files of Darwin.
Well
The format we're talking about here is what we call a "property list," a serialized data structure that's written out to disk in XML format. Here's an example. This is the launchd config file for KernelEventAgent, an important Mac OS X system service.This files are generated by the serialization functions in Core Foundation. You create a data structure, in this case a CFDictionary. Then you populate it with objects. In this example, that's four key-value pairs. The keys are "Label," "ProgramArguments," "OnDemand" and "ServiceIPC." The values are a CFString, a CFArray of CFStrings (with just one object in this case), and two CFBooleans. Then you issue one function call to serialize that property list to XML and another to write it to disk as a file.
Of course, in this particular case you wouldn't go through that trouble. But the important part is the other part of the process. You make one function call, passing it a path to a file, and you get back a de-serialized Core Foundation data structure, all type-checked and everything. If at any point the property list fails --if it fails in the XML validation or the static type checking --then you get back null and an error. All atomic, no muss, no fuss.
That's what launchd does. All clear now?
And shipping one of those implies there's difficulty in editing or reading the configs manually.
Look at it and you tell me. How daunted are you?
If you're building better solutions, maybe you can architect them to work well for most unixes?
We're releasing launchd, we're releasing Core Foundation, the property list format is both wide-ass open and fully documented in many different places. What else do you want?
FWIW, I use Fefe's Minit, which is based on daemontools. And it was probably the first attempt at speeding up boot times in Linuxland. Good to see things like this going mainstream.
See what happens when you ask people to ponder? :-)
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
You can ensure that the file is a valid property list XML file, but you can't make sure that it contains launchd configuration info
Of course you can. A launchd configuration property list de-serializes to a CFDictionary. If the CFDictionary doesn't include the required key-value pairs, it's not a valid launchd configuration file.
Syntactic and semantic structure happen in two different places. One happens as the file is de-serialized in Core Foundation. The other happens inside the launchd code itself.
DTD/Schema sensitive editors still wont help you out with semantic structure.
Technically this is a valid point, I agree. But property lists are almost always so incredibly simple that this objection is purely academic.
My favorite line from the article: "For Tiger, Apple created launchd: one launch daemon to rule them all."
whoa
Are the tags in my XML file <foo> or <bar>? Is it okay to leave off attribute "baz" or not? How do I know it's okay to set it to zero?
Since when does XML have this miraculous property that allows you to avoid *thinking*?
Actually, in Apple's case, all the tags are pretty much the same set of key/value pairs. So you're actually going three levels deep. You know XML structure (tags, angle brackets, etc). You know XML plist structure (type, key name, key value). But do you know all the valid types, keys, valid values, what order they should be in? No, you still have to *understand* each one.
Where do people get this idea that XML somehow solves all these problems, I have no idea. Have you actually *worked* with this stuff? It's just as hard to remember all these XML files as it is all the different Unix config files. Show me a big Ant build.xml, and I'll show you a bunch of gobbledygook.
At least the old fashion config files aren't polluted with all these extra noise characters.
XML solves some problems, but not the one you describe.
And what happens when you miss a > in XML, or mistype any tag name? These sorts of error are what validators were made for. The vasyt majority of programs should refuse improper input, as in the long term that's the only way to stay sane.
You're looking at this from the perspective of someone who understands and remembers the differences in a dozen config file formats. Most people don't.
RTFM!!
Seriously, if you're going to be editing a file.. XML doesn't make it easier to understand the contents. Having an XSD or DTD doesn't really help you to know what is supposed to go into the material (and XSD is harder to read than a man page, thank you very much).
-Michael
Everything you said is true, but possibly misleading. Nobody needs Core Foundation's XML parser to use property list files. Property list files are created through serialization and "parsed" through de-serialization. You don't need to hand it to an XML parser or run Xpath on it or any of that poop. You just pass the file to CFURLCreateDataAndPropertiesFromResource, then pass the resulting data to CFPropertyListCreateFromXMLData. What you get back is a CFPropertyListRef which can be cast to a CFDictionaryRef.
Like you said, all that's open source.
Unfortunately, machine generated XML is rarely as pretty as your format, and in the case of Apple has far less meaningful tags denoting only names and types of properties. i.e. it throws out the parts of XML that are actually nice.
What self-respecting OpenSource developer would even care to link with the NS junk?
"You can lead a horse to water, but you can't make him drink."
Since XML is an abstraction on top of plain text files, there's absolutely no way it could be simpler than a plain text file to begin with!
Not true. By text files, we tend to mean line-oriented files. Often to be useful, it must also be field-delimited files.. colon-delimited in password files, or worse with cron-files a mixture of space-delimiting and position-dependence. (after first sevearl spaces, remaining spaces are no longer delimiters).
With XML you are no longer rectangular in your data-structure; no longer rows and columns (and potentially sub-colums), but instead you can more naturally represent the data however complexly it needs, and not have to worry about escaping arbitrarily complex characters, because all XML files use the same escaping.
-Michael
because you're just that awesome.
sigs are for fools and trolls. no signature is *always* appropriate. you should turn them off in your preferences.
Shhhhhh.
(Except when spreading WHOLLY UNRELIABLE rumors about this that I will OFFICIALLY DENY, please don't call it Linux. It's definitely not Linux. Or wouldn't be, if it existed. Which I have to say that it doesn't.)
With .plists, you do know exactly which is which and you can validate to ensure that you don't attempt to load a value as a key or visa versa.
You're argument is a straw man when scripting languages other than bog standard shell scripts have parsing routines for you to use. If you want to use stone knives and skins, go ahead but don't attempt to use it as an argument against using more advanced technology.
Look around you. The .NET Framework is using XML, Web services are using XML, OS X uses XML and Solaris currently use something similar to launchd instead of standard shell scripts. Is that crap too?
I don't get how you are so dead set on writing parsers from scratch for every bloody script and configuration format. How the hell can anyone besides a zealot call that better?
Jesus was a compassionate social conservative who called individuals to sin no more.
Well, RTFM the XML manual and move on. The benefit to having launchd is that you RTFM once instead of multiple times. Every year, a new crop of computer users/operators/programmers learns *nix. With launchd the exact same amount of RTFM leaves them more educated about their system because they've read the launchd manual and 3 or 4 other manuals while their classic *nix compatriots are still stuck on launching and stopping daemons.
The program called the BIOS is, in this case, Open Firmware or IEEE 1275.
Did you read the man pages for this? Does Apple have some Tcl stuff now associated with their daemons? What possiblities does this open up?
I know the guy who does the Darwin releases.
You're not him.
I know the guy who has been working on launchd for over two years now.
You're not him.
I know the guys who work on the BSD Technology Team.
You're not any of them.
So what I want to know is, where do you get off using "we" every time you open your mouth about Apple? You didn't write it. You didn't think of it. I doubt you could do either. The credit isn't yours, and I have a feeling that Corporate Security is bearing down upon your desk in the QA department right about now.
If I were you I'd shut my trap and cover my ass.
-- AC
With entities and namespaces and schemas and all that, XML is hardly the 'most parseable format'. Frankly, you can't beat CSV at that.
The second advantage to plists is that they're self-validating. When a program tries to load a plist, if the file doesn't validate against the PropertyList-1.0 DTD, nothing happens. An error is returned, and the program (in this case, launchd) moves on. No chance of a corrupt file producing unexpected results.
So it can validate syntax, just like cron does, brilliant.
There seems to be two distict camps in this topic. The detractors would probably be less detracting if launchd supported the status quo.
Why is adding XML to core services bad?
/lib or static linking into init. I doubt many sysadmins will trust that. Think evolving standards, evolving implementations and new bugs versus KISS.
One problem is with raising libxml/libxslt to the rank of 'core libs' - meaning
On the other hand, for stuff that runs AFTER the basic system is set up, XML configs aren't that bad.
It's definitely not Linux. Or wouldn't be, if it existed. Which I have to say that it doesn't.
Sure it does, it's right here: Download Darwin
I believe you can just download the x86 iso, and install darwinports. That'd pretty much give you a BSD-like distro of Darwin with not quite-so-many available packages, but all the cool unixy features of OS X, including launchd, right?
Of course, this isn't as simple or as organized as installing Debian, but, well, it's there for the downloading.
Unnecessarily? based on what, a hunch? Or have you investigated the boot process and found places where you could make it faster? If you mean to say undesireably slow, then yeah, I'm with you all the way. I'd like it to be as ready in the same way a light bulb is ready. In fact, if it were I'd be more inclined to shut it down occasionally.
So, the .ini-fanboys shouldn't complain to much about their beloved .ini fileformat, as the main/user and designer of that format replaced the format too.
Ah. So Microsoft, and now Apple, have abandoned something. We are to take from it that the that 'something' was bad.
I see.
Hmm, I cannot see Sun or IBM, both hardware manufacturers, using code that their right to it would be revoked if they sue apple for anything at all.
That clause only refers to patents, and if Apple first sues you, you can sue back and not violate the APSL.
Although I can't find the details, I believe IBM's grant of patents to the OSS community has a similar requirement. The reasoning is that while most legitimate technology companies realize software patents are fundamentally foolish, they also realize they *must* acquire patents to use as defense against being sued for violating patents. If everyone is in patent violation, any lawsuit opens the doors to MAD. At least, that's the idea.
Back to Apple. The APSL grants the recipient of the code to use any relevant patents. In exchange for that "gift" (same as IBM's patent "gift"), you have to agree not to use patents against Apple. You still can, though, if you decide the infringement is serious enough to stop using ASPL licensed code.
On the whole, this is a good thing. Although it doesn't *eliminate* software patents (Apple can't do that, only Congress can), it does make them even less likely to be abused.
BSD people... I would guess they feel the same as the linux people - but that's just a guess.
The FSF says there's no problem with joining in with an APSL project. They do say you can't copy code between APSL and GPL licensed code, though, but that's pretty much the case with almost every OSS license and the GPL.
The Linux folks (not quite as unified as is being implied, but let's just generalize here for simplicity) have no problem including non-GPL software with their distributions. They also don't tend to take out patents (and especially don't sue over them!), so this clause isn't an issue.
The BSD folks are like the Linux folks, except more unified, and a bit more libertarian WRT the licensing of software.
And if you don't like the license, you can just re-implement launchd as a GPL or BSD licensed program. It duplicates effort, and I don't think the license is so unpalatable as to motivate such an undertaking, but the technology is pretty exciting. The license is a valid OSS license, so let's take advantage of it! (Ubuntu, I'm looking at *you*)
I've used Apple's mDNSResponder and Darwin Streaming Server under Linux, and it doesn't taint the license of any Linux (kernel or distribution) code, and really works *great* for the tasks at hand.
If Apple ever decided to take an adversarial stance with the OSS to any large extent, well, just remember that SCO was pretty cool back in the day.
The detractors would probably be less detracting if launchd supported the status quo.
But launchd has obsoleted and replaced what used to be the status quo. Now it's the status quo.
You do realize that we're not talking about some kind of abstract proposal here, yes? This isn't something somebody might implement someday. It's done, over, released.
The .NET Framework [...] Is that crap too?
Yes.
What else do you want?
I'd like a property list format that was compatible with XPath.
At the moment, I can only retrieve values from a property list either by using the CFDictionary interface, or by processing it with custom code.
If property lists were structured better, then I could do easily retrieve data values with XPaths, easily pretty print them with XSL, etc.
My basic point is that while they are indeed XML, they don't even come close to best practice.
There is one thing that should bug every SysAdmin: in case of a problem, will the programs that are mentioned in this thread be available? I do NOT talk about trying to find a CD with the necessary editors, etc. Every SysAdmin worth his/her paycheck can make sense out of the usual config-files in /etc, try the config of EtherShare to get an idea about the adverse (there is a program to make sense of the config, something every SysAdmins likes to use, don't they?). .NET uses something do not make it viable for *NIX
When the users are breathing into your neck because they need access to their files, messing around in XML using vi/emacs or worse ex, just is not funny.
The fact that
my 2 cents
The only concern I have is how bloody ugly/unreadable the config files are. There's so much noise from the tags that one's hard pressed to read the entries. I don't care if there's an editor for it, when I have to do it by hand with a text editor the file format's fluff gets in the way.
That sounds like a complaint made up to have something to complain about.
The idea is that you *don't* edit plists by hand, but if you have to, you can.
So, under all normal circumstances, you do things via preference panes, plist editors, the "defaults" command, etc. But if things are hosed and all you have is a boot floppy or CD with vi on it, you *can* recover the system back to a fully operational state. And more to the point, launchd helps minimize the potential for being in such a hosed state.
All this is academic, of course. The question to ask is how often do people find OS X to be in a hosed state, where the system is unrecoverable without resorting to such extreme measures? And how often does this happen in Linux? The answer for OS X is essentially "never", and under Linux it's "every now and then".
So perhaps your trepidation is because you are used to having to fix a hosed Linux system by hand via a boot floppy?
But it isn't restricted to just software patents. What about hardware patents? Like I've been saying, Apple is mostly a hardware company.
Say IBM rolls out some distro on a large number of machines and the distro they use uses mDNSResponder.
Say now Apple violates one of IBM's hardware patents.
What should IBM do now?
And the BSD folks are more libertarian like you say - exactly why they are even less likely to accept such draconian licencing.
Btw as for reimplementing, yeah it can be done. Both gnome and kde development on zeroconf is pretty much waiting for the reimplementation of mDNSResponder.
First of all, I'm not saying that property lists themselves are bad. I'm just saying that the old format is more readable and property list XML is useless. The rest of my post focused on preempting arguments that might claim that the use of XML gives you additional functionality for free (which may be valid in some situations, but not this one).
I meant to say that you can't leverage the DTD/Schema stuff to perform validation. (The line above the one you quoted was indented to establish that, but I suppose I probably should have ended it with a colon, huh?) And, like you said, you can do all your validation operationally if you want. Or you could create a declarative system just for property lists. But you can't leverage existing DTD/Schema libraries to handle this for you.
Well, if you don't need editor support, that's great. And it just may be the case that nobody will ever want code-completion-like editor support when editing your configuration files, but I doubt it. You can create a custom editor that understands your custom declarative type system for property lists -- and that's perfectly fine -- but the use of XML achieves nothing here (just decreased readability and a slight performance degredation).Actually you don't need to activate devmode on the Dashboard. You can just start dragging a widget from the widget drawer, hit F12 and let it go on your desktop. This works with just one widget at the time as the next time you activate Dashboard, it will "suck" it back in.
"I tend to think of OS X as Linux with QA and Taste", James Gosling, creator of Java
root@darkstar:/etc/rc.d# ls
rc.0@ rc.M* rc.gpm* rc.inet1.conf
rc.local* rc.sshd* rc.4*
rc.S* rc.hotplug* rc.inet2*
rc.modules* rc.syslog* rc.6*
rc.alsa* rc.httpd rc.inetd
rc.sendmail rc.sysvinit* rc.K*
rc.font.new* rc.inet1* rc.ip_forward
rc.serial* rc.udev*
So to start at boot I have to figure out this whole chmod 755 rc.whatever thing? Yep too difficult, what I really need is some extremely bloated, one size fits all pile of crap that only a machine can edit. BTW cron works just fine. If it doesn't work its usually caused by a malfunction in the script its told to run. Cron is just fine, however many of the people using it are severely b0rked.
UNIX: A set of Linux-like operating systems that grew out of an original version written by some guys at a phone company
Well, since you mention it.. If you're reading this, ASOTV, please drop me an email. Nobody's going to eat you, but we'd like to have a discrete word... Thanks.
- Jordan Hubbard co-founder, the FreeBSD Project. Director, UNIX Technology. Apple Computer
But it isn't restricted to just software patents.
Right, but what you said is: "their right to it would be revoked if they sue apple for anything at all."
That's a whole different reason.
Say now Apple violates one of IBM's hardware patents.
What should IBM do now?
If the patent is important enough, IBM should sue Apple. They'd lose the license to the APSL code, but if the patent is important enough, and the violation clear enough, Apple can be held liable for the resulting damages, including the damages incurred by the revocation of the APSL licensed code.
Think about it. If it's an important patent, Apple won't want to nick it for their PowerBooks (for example) and risk being forced to stop selling their PowerBooks indefinitely. So, in practice, I don't see this being a problem.
Which is, as I understand it, the same situation any OSS project is in with IBM's patent gift. What if Apple uses an IBM granted patent in Darwin? Apple won't be able to sue IBM either, without the resulting consequences.
Agreed, though, Apple should limit the scope to software patents.
And the BSD folks are more libertarian like you say - exactly why they are even less likely to accept such draconian licencing.
You've got libertarian backwards. They *support* corporate rights, which is why the BSD license lets a corporation use their code in proprietary software.
Btw as for reimplementing, yeah it can be done. Both gnome and kde development on zeroconf is pretty much waiting for the reimplementation of mDNSResponder.
mDNSResponder doesn't have to be compiled into GNOME or KDE (KDE getting huffy about a license?). You run it like you do bind, and nsswitch.conf takes care of redirecting lookups (you get it for free in GNOME, no recompiling required). As for GNOME advertising services, they *should* just tie into the system mDNSResponder daemon, but if they want to compile the code in, yeah, they have to re-implement. That's not a big deal. In that case, the reason isn't because the license states you can't sue over patents, but that it's not GPL compatible, which puts the APSL in the same boat as just about every other OSS license aside from the GPL and the BSD licenses. No big deal, and that's the way it's *supposed* to work in OSS. Different implementations of the same thing for different reasons. Various MTAs, many DNS servers, and yes, many ZeroConf servers. As long as the protocol is open (and it is), then there's no worry that Apple's mDNSResponder will "embrace and extend", breaking GNOME's built-in ZeroConf services.
That is what atd is for
UNIX: A set of Linux-like operating systems that grew out of an original version written by some guys at a phone company
To me, your schema seems like an ideal location to enumerate and document your preferences. But let's say you don't give a crap about that; you want to add new preferences by updating the config-file-loading code, but the validator isn't letting your new tags through. Turn off the validator. You don't need it. Just let your config-file-loading code look directly at the XML and take the elements it wants. (BTW, what do you mean by "schema parsing"?)
Correct. And so why can't you just give the storage layer arbitrary XML and tell it to store that? Why have the extra layer of indirection ("dict", "array", etc.)?
People (like you and the guys at Apple) are building generic layers on top of XML and building their domain-specific data types on top of that new layer. XML was supposed to be that generic layer, but you guys have implicitly decided that XML sucks too hard to serve that purpose. I totally agree.
If not YAML, there is no shortage of alternatives to address any issues you might have with it.t ml
http://www.pault.com/pault/pxml/xmlalternatives.h
Because configs aren't generally speed critical, the XML parsing library should figure out the format type and use the appropriate parser. A program using it wouldn't care which XMLish format its config is in, unlike a user who might like to edit said config easily.
One of my favourites is Sorta Like Python:
http://www.scottsweeney.com/projects/slip
While I know the syntactic overloading of leading whitespace is a bit evil, it turns out to be not a problem as most Pythonistas will tell you. It encourages consistent formatting without including more syntactic squiggles, which improves readability of configs as much as code.
I have had the very occasional stuffup in copying python code straight off a browser window, its usually best to do it from source or saving as text.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
And yes, in plaintext view, this is definitely more readable than XML. With syntax highlighting XML does become more readable, but you don't always have that (vim is not as universal as vi!).
"It's better to keep your mouth shut and be thought a fool than to open it and remove all doubt."
How did they resist calling it iLaunch? Must be some new guy working there.
In addition to what the other guy said, it is possible to take an XML file and work out exactly what encoding it is in. This is not possible with a "plain text" file.
The default encoding for an XML file is UTF-8.
If encoded in UCS-16, XML files must begin with a byte order marker, which tells the reader whether bytes in the file are to be interpreted as little endian or big endian.
If any other encoding is used, it must be given in the XML prologue:
Finally, I forgot to include variations on the line separator character(s) in my list: are lines terminated by a CR, LF, or both?
Yes, it includes launchd, but it doesn't, for example, include any GUI whatsoever.
IOW, aside from a different architecture, it will feel like just another open source BSD-style OS.
If you're not starting the config file from scratch (which is the common case) you can generally figure this out pretty quick by looking at the bloody file...
It sounds to me like Something That XML Isn't Going To Magically Give You. See, for example, the XML format in question--it doesn't have a structure that lends itself to autocompleting anything useful. Just because something is in XML doesn't make it better--it just makes it XML. I've found it much more common for XML config files to be of the type
<item>
<key>foo</key>
<attribute>fooatt</attribute>
<key>bar</key>
<attribute>baratt</attribute>
</item>
(which is definitely harder to read than
foo: fooatt
bar: baratt
with no added value) than something useful like
<item>
<foo>fooatt</foo>
<bar>baratt</bar>
</item>
which might actually be useful, but would also be way more work than most companies are going to put into things once they've got the "XML" checkbox filled in.
"Apple can be held liable for the resulting damages, including the damages incurred by the revocation of the APSL licensed code."
:) :)
:)
Really? This would be very interesting
I tried reading the wikipedia article on libertarianism but my eyes just kinda glossed over about half way through, so I'll just cede the point.
About the KDE getting huffy about a license.. well I'm a KDE developer and have done a tiny bit coding with mdnsresponder but we are hoping to see what the gnome guys produce as a replacement.
I realise what you are saying, but can you imagine handing out CD's and saying "Here use this nice new kde live cd! You can use it as long as your company doesn't sue apple!"
And if you can't stomach the soul-eating registration, use the OpenDarwin mirror (or get the tarball).
So, you'd prefer to have DTDs for every item that you want to manage with launchd? I wouldn't.
mbbac
(about being able to sue Apple for damages) :) :)
:-)
Really? This would be very interesting
In all fairness, I'm not a lawyer. It just seems that if someone violates your patent, you'd be able to recoup all related costs. However, the law hasn't always followed my sense of reason and right-and-wrong!
About the KDE getting huffy about a license.. well I'm a KDE developer and have done a tiny bit coding with mdnsresponder but we are hoping to see what the gnome guys produce as a replacement.
It was meant as a little joke, given KDE's use of Qt, which has caused some issues due to the dual-license nature of Qt, and the fear that Trolltech could revoke the license, or otherwise leave KDE hanging (not entirely unlike what happened with BitKeeper).
I realise what you are saying, but can you imagine handing out CD's and saying "Here use this nice new kde live cd! You can use it as long as your company doesn't sue apple!"
That would make for a humorous CD handout session, but there are plenty of strange license requirements in your standard Linux distro. It's not like your average users are all going around bringing patent suits against Apple.
I would wholeheartedly support a campaign to get Apple to limit the scope of the patent lawsuit exception to apply solely to software patents.
I will admit that I wasn't the clearest. However, if you use XML as you suggested. Then for each version of your program which adds preferences you need a new DTD in order for you to fully validate. Since a program should be able to handle all versions of its preferences. You now need to check against multiple DTDs.
If I turn off the validator... well that seems to go counter to your desire to validate against the DTD.
The application in question is lame. There is no separation of preferences storage and application specific details so it is completely aware of the program domain. Need to add a new preference? You have to add it to the raw code that reads/writes preferences (2 places in that program).
I highly suspect the program doesn't handle new versions of the program reading older preferences or the like.
I admit that if the storage was at least an isolated component, it could spit out arbitrary XML. But it would be a lot harder to find the right DTD.
Side question: Hmm, does an XML DTD itself even state what a value of a field should be, or is it always tags about strings? The property list DTD at least has a description for each value of whether it's a string, array, int, hash (dictionary), or boolean.
I decided to go with an Apple Property List in a cross-platform program, without using Apple's Preferences API, because I wanted better preferences than a memory dump. (what my program had been doing.) Because I wanted them human readable. And because I wanted room for growth without having to flex the DTD for every internal and external release of the program.
Basically, I saw what the other program was doing and desperately wanted to avoid what it had done and I was willing to make an isolated storage layer. Property lists fit what I needed out of my storage layer (application shouldn't care about how preferences are stored, preferences shouldn't care what is stored.) And as an added bonus, because of the ubiquity of property lists on MacOS X, there are already tools to work not just with XML, but explicitly with Property Lists.
I'm no XML God, but just a young programmer. And what Apple was doing with the property lists made a heck of a lot more sense than anything else I had seen. And most likely much more sense than anything I could design as well.
How about you back up a little bit in this thread, for just one simple example? There's much, much more but I'll leave the digging to you.
Unless, that is, you're so lazy that you'd blindly believe someone like ASOTV (who, BTW, hasn't posted any creds to date). I guessing laziness wins. It sure seems to for the moderators around here (cf: grandfather post).
At the moment, I can only retrieve values from a property list either by using the CFDictionary interface
That's exactly how you're supposed to do it. It's not meant to be done in another way. Why would you want to do it any other way?
My basic point is that while they are indeed XML, they don't even come close to best practice.
Your whole concept of "best practice" seems to revolve around some ideas that simply don't apply. You want to "pretty print" your property lists? What?
Do us both a favor: Stop inventing abstract points about which to argue. You obviously don't know anything about property lists or the programmatic interfaces surrounding them. If you did, you wouldn't be making nonsense comments like that one. So do us both a favor and go read the Core Foundation documentation about property lists. Okay? Seriously, that's not too much to ask.
I've been working on Linux appliances for over 6 years now, without exception, it seems like someone ends up writing some kind of "health script" that is kicked off by cron every minute or a few or is a daemon in it's own right that watches for things to crash or not be running and then it restarts them. I've seen it in a production set-top box based on Linux where we essentially wrote our own init and had it treat some processes special and 5 different software appliances. Fact of life is software crashes from time to time.
You do realize that you can just use init to do this, right?
/etc/inittab:
For instance, I have a client with a dialup server and several USB modems for his clients to connect to. mgetty is only good for one connection, it doesn't reset itself. So I added these lines to
S0:345:respawn:/sbin/mgetty ttyUSB0
S1:345:respawn:/sbin/mgetty ttyUSB1
S2:345:respawn:/sbin/mgetty ttyUSB2
etc.
Just because you (not you personally, but whoever is duplicating init's functionality in other programs) don't know how to use the existing tools, it's not an excuse to write your own, non-peer-reviewed code with potential security problems.
In post-9/11 America, the CIA interrogates YOU!
Calm down. Tiger still includes cron, so it's perfectly backwards-compatible. You never need to touch launchd, if you don't want to.
Signature.
Amazing. I've just read four or five comments on launchd from people diminishing how boot time has been decreased (by roughly an order of magnitude, it seems) by Apple. How would you like a car that took two minutes to "boot?" Resistance to change seems to be human nature to some. The arrogance is so palpable one could cut it with a knife.
My debian linux firewall/gateway box has been booting with runit as process 1 for years. Most of the "services" on the box are controlled by runit/daemontools. It has worked flawlessly for me. launchd seems to extend this paradigm very elegantly. I welcome launchd with open arms, and I hope a debian package is available at some point. BTW, 10.4 server is using lanchd, too. This is not just for desktops.
Think about all the customers who will boot their new mac and be amazed by the quick startup. Seems like Apple has their priorities straight. It's hard for me to see a downside to faster boot. Perhaps the more anxiety-prone will wonder if something is wrong?
"Mit der Dummheit kaempfen Goetter selbst vergebens." - Schiller
Yes, it is easy to parse, because Apple's plist file is not full blown XML, it is a subset. It only has a few "types": dictionary, array, string, integer, real and boolean.
/usr/bin/plutil, which you can use to check the syntax of a plist file, it weighs in at 30K. My version of libexpat.a is 410K.
Apple has a utility
Then, of course, it's open source, so you can modify the configuration file parser any way you want.
If you want to process plist files, you can use this Perl module:
Mac::PropertyList
The time to parse XML is utterly negligible compared to the time needed to start the proceses specified by the XML.
I'm sorry you've been put in defense mode. Allow me to attempt to assuage your
pains: You have done a good thing. Really. The thing you have built is quite
keen, there's no doubt about it. There is great, thoughtful, capable
craftmanship evident in it. It well suits your needs and the needs of many.
Doubtlessly you have been suffering quite a bit defending your ideas against a
firestorm of both idiocy and valid concerns. Sorry about that. I hope you come
away from the experience ultimately strengthened and without overly long-lasting
trauma.
I am interested in a startup system improvement for my OS like what you've built
for your OS. Please try to read my message not in a mode where you must defend
your creation, and thus are attempting to discredit my needs and reasons, but in
a mode where you attempt to defend my viewpoint. That may make it easier for
you to understand me. Antagonism, however, is appropriate for most of the crap
you'll have to endure here.
I fully understand that this system works very well for Mac OS X. I also
understand that other OSs could adopt the required infrastructure with hardly
any cost and that the availability of the Core Foundation and launchd code
facilitates this. (Sadly, they're not directly usable by me or many advocates
of free software because of the pro-corporate, pro-IP licensing aspects of the
Public Source license, specifically clause 12.1.c.) I feel, though, that my
real concerns might not have been clearly presented.
I should perhaps state one of my concerns this way: The expat distribution is
larger than my OS.
Another point of mine was the ease of read/edit. I suspect that one could
develop a format that allowed for validation without the obscuring tags of an
XML language. Obviously some markup is required, but how much so for a startup
system? Isn't whitespace a great tool for both markup and visually delimiting?
You ask me how daunted I am at reading/editing the example XML doc as if freedom
from discouragement were enough. Might I suggest that there's much more room
for facility than just getting past dismay? Perhaps you meant "daunting" in
exaggeration. From your perspective XML is far from confusing. Is it possible
to create a markup that lends itself to immediate comprehension instead of
requiring the amount of time you've spent to learn XML?
What you've done suits your needs and the needs of many well. You were not
developing with me in mind, so you have not failed in this regard. I will say,
however, that I believe there is a yet better solution that would satisfy your
requirements of serializing and validation while also satisfying my desires of
of small parser, legibility, editability, and format intuitiveness. It would
not, however, satisfy your desire for cleanly using your existing
infrastructure, which you haven't stated explicitly that I can see.
Why release the code at all if you want to maintain control over it?
The GPL does "limit" those who can make use of the code.
Jesus was a compassionate social conservative who called individuals to sin no more.
That is true. But I think it would have been a much better idea to simply transition to UTF-8 (or to specify the encoding at the top).
Not sure what you mean here. If you chose to go the DTD route, youd only have a DTD for every type of launchd config file, not for every program you want to launch.
That is correct. If your preference parsing code needs to be that flexible, then I don't know of any current XML typing system that can handle it (DTD, Schema, Relax NG, etc). Thats why you shouldn't use one.
My desire to use a form of declarative typing only applies if you can use declarative typing. If you feel you need things to be more flexible and are willing to check everything operationally, then check the XML directly. Property list XML creates an entire layer on top of plain XML and then uses a DTD to validate that extra layer. It's a zero-sum setup. All they added was overhead.
I'm not sure what you mean. If you're going to use arbitrary XML, why would you need a DTD?
I don't think DTD allows this, but XML Schema or Relax NG might.
The original format was much simpler to read and parse. In your case, you can claim that you didn't feel like writing a parser for the original format (even though I guarantee you could have done it in less than a day) and wanted to use an off-the-shelf XML parser. Apple, however, already has a working parser. There was no reason for them to create the property list XML format.
Please read my post. I'm not saying property lists suck. I'm saying property list XML is pointless.
The only people making a big deal over his employment is the /. peanut gallery.
Free Mac Mini Yeah, it's
Yeah, I read that part. How does it make a difference, exactly?
That's exactly how you're supposed to do it. It's not meant to be done in another way. Why would you want to do it any other way?
Because maybe I don't want to learn yet another API for no good reason. What's the point of having it written in XML if the only way to conveniently access it is by using a different API? It's a PITA if I need to track down a module for accessing property lists in every tool I use.
Your whole concept of "best practice" seems to revolve around some ideas that simply don't apply. You want to "pretty print" your property lists? What?Sure, why not. Let's say I want to write a utility that lets me view all of my launchd config files.
Do I want the end-user to see raw XML? No. So I write an XSL template to reformat the data into something more presentable and present it in a web view. Whoops! Can't do it - have to write code instead (the separation of keys and values prevents me from doing any useful reformatting).
Another example: I want to find the launchd items that directly depend on another item - and there isn't a CFDictionary implementation in the tool I'm using, but it has a perfectly good XML implementation.
Because the property list XML isn't structured properly, I have to write a chunk of pointless deserialization code to get to the data I need, while if the data was formatted correctly in the first place, it would be a trivial one liner.
The strength of XML isn't just the data format - it's the wealth of tools that exist for operating on arbitrary XML data. The damage was limited when it was an Apple specific mechanism, but now they are presenting this to the wider community.
My idea of best practice in XML is the ability to leverage the tools that exist for operating on XML. Your argument that validation is the only thing that anybody would ever want is just closed-minded and your assertion that every development tool should include a CFDictionary implementation to deal with the format's deficiency is just silly.
It's not hard to fix the property list format. Just make the values and keys more strongly bound - eg something like: <item key="blah">value xml data here</item>. There is nothing lost by doing this - and everything to gain. CFDictionary is no longer required to easily access property lists, and they are easily transformable.
Say I have a couple of widgets that display continuously updated information from the Net. Say one's a weather app, and another is a news or stock ticker. Now let's say that I'm on a laptop that's on a slow modem connection (or a fast connection accessing a busy, laggy server). When I bring up the Dashboard, I want those widgets to be displayed instantly with up-to-date information. If it's been 30 minutes since I last looked at them, I don't want to wait 5 seconds or however long it takes to update those widgets. I want them to be updated regularly so that when I activate the Dashboard, they are already up-to-date.
This applies for many, many things, like weather apps, stock tickers, news tickers, flight trackers, buddy lists...just about anything that gets info from the Net.
It's a very basic concept. Geez, how much CPU time does it take to download some XML data file, process it, and update a widget off-screen? Run it with a low priority and it will slow nothing down. Write the widget well and it won't waste CPU time in some continuous "do I need to update myself now?" loop.
"Those who consume the bulk of goods are those who make them. We must never forget this secret of our prosperity."
Why is it that people like you can't put two and two together? Why is it you can't face the possibility (the very strong possiblity) that the guy doesn't work for Apple at all and has all of you fooled?
Personally, I think it's because you want so much to believe in this guy that you just blindly accept whatever he says (even if it's plain wrong).
Because maybe I don't want to learn yet another API for no good reason.
You don't have to. We're talking about launchd, remember. No APIs to learn.
What's the point of having it written in XML if the only way to conveniently access it is by using a different API?
We've been over this and over this and over this. The point is that XML files are self-validating.
Let's say I want to write a utility that lets me view all of my launchd config files.
That would be a spectacular waste of time. There's no real-world reason to do that.
Another example: I want to find the launchd items that directly depend on another item
Dependencies are determined automatically at boot time. They're not static.
You continue to try to come up with contrived, artificial examples. Why? Don't you understand that by definition, a contrived, artificial example isn't representative of how people actually use property lists, and therefore isn't going to convince anybody of anything.
Just make the values and keys more strongly bound - eg something like: value xml data here
Impossible. No type checking that way. Remember, property lists are serialized data structures. They have to preserve type data and be compliant with a well-defined and universal DTD.
As a far a whats he's saying? Hell, I don't know enough about unix services to tell. Could be wrong.
Free Mac Mini Yeah, it's
When I used gentoo several about 2 years ago that didn't exist. It's news to me. I'm glad they added it. However, I still think emerge is horrible. Stuff was always breaking on my system. Even Debian unstable isn't as bad as standard gentoo.
The topic is my ability to write a tool that can read property lists without using a new API.
You never would. Read on.
Is there somehow one magic configuration tool that performs every operation that one would every desire, every reporting capability you would desire?
I feel that you have lost sight of the ball. We are talking about configuration files here, specifically configuration files for launchd. There are no operations to be performed on them, no reports to be generated that launchctl doesn't do for you already.
I propose that somebody might want to write a utility that lets them easily display the current set of tasks that launchd has been tasked with
You mean "launchctl list?"
Somebody wants to write a system-wide policy tool that will disable a particular daemon, but only if it isn't depended on by any other service.
You mean "launchctl stop (servicename)?"
I'm writing a configuration tool for a daemon that I've written and I want to edit the property list for my tool to configure the parameters.
Groovy. Core Foundation is your friend.
The current property list mechanism does not use good XML.
Sorry, but "Some guy on Slashdot would like it to be different" isn't that convincing. Remember, please, that we've been using XML property lists for six years now. Somehow the Earth has continued to orbit the sun.
I'm sorry, but your argument that nobody could ever want to check how launchd is currently configured and so it's fine that the configuration data is poorly encoded is just silly.
And your authoring a lengthy and multi-part excoriation of the launchd configuration file format without ever stumbling upon awareness of launchctl, which does precisely what you insist can only be done by examining configuration files, is at least as silly.
Does launctl be run as a web service?
Is the output easy to parse so I can get it into the form I want?
Can launctl stop service be run automatically and log something to a postgresql if it couldn't be run for some reason?
Apparently in your world all software is completely perfect and doesn't require custom applications to be written. Apparently I've been wasting my time writing development tools.
I didn't way the propertly list xml was unable to do the job, just that it was badly structured - a concept that you seem to take personally.
My issue here is that while it's previous scope was limited to application manifests, preferences, etc, the issues were limited, but as part of a bold new platform for process launching - something that is far more likely to want some degree of customized reporting within the enterprise, its shortcomings are painfully apparent.
And ultimately my point that it's silly that you should be forced to resort to CFDictionary to do anything with a property list that isn't provided by launchctl can't be countered with "you should use CFDictionary".
If I want to write a web service using PHP that wants to access config data, where's my CFDictionary interface?
If I'm writing something with Java under Linux, where's my CFDictionary interface?
If you want something closer to home, where's my CFDictionary interface in RealBasic?
The fact that you can obviously spend so much time posting to slashdot indicates that you don't do much of importance. I do.
Does launctl be run as a web service?
I think there's a syntax error in there somewhere.
Is the output easy to parse so I can get it into the form I want?
What form do you want? I'm fairly certain, based on your comments so far, that your answer is going to be something ridiculous, so before I even go down that road, what form do you want?
I didn't way the propertly list xml was unable to do the job
Have you been drinking? You shouldn't post while you've been drinking.
My issue here is that while it's previous scope was limited to application manifests, preferences, etc, the issues were limited, but as part of a bold new platform for process launching
"Bold new platform?" You do know that we've been using property lists everywhere since 1999, right? Including as SystemStarter configuration files. Using them in launchd is neither bold or new.
If I want to write a web service using PHP that wants to access config data
On what planet would you ever write a PHP application that gives any random Web user access to your computer's system configuration? No, that's (as I predicted) a ridiculous example.
If I'm writing something with Java under Linux, where's my CFDictionary interface?
In the Core Foundation bindings for Java.
If you want something closer to home, where's my CFDictionary interface in RealBasic?
Because that's a third-party application I can't speak authoritatively, but if it doesn't provide access to Core Foundation, it's not a very useful tool, is it? Seeing as how every Mac OS X application uses Core Foundation and all.
The fact that you can obviously spend so much time posting to slashdot indicates that you don't do much of importance. I do.
Are you also going to tell me that I'm ugly and that my mother wears army boots? Is that the point we've reached?
For example, the ssh-agent daemon (think "keychain for ssh passwords") needs to launch once, and only once for each user login session. Shell startup files are read every time a shell is started. Multiple terminal windows means multiple shells, but still only one login session.
.bashrc or .cshrc; someone tell him about .login or .profile.
Apparently Siracusa hasn't advanced beyond
It's a new twist to old-school Unix hackers, and the initial reaction is predictably cautious.
It's not just a "new twist", it breaks dozens of system management frameworks.
I scanned through the man pages but didn't see how to use launchd as a cron replacement. I'm about to upgrade to 10.4 and currently use cron to run my nightly backups. Does 10.4 no longer provide cron? How do I configure launchd to run my nightly script? Can someone point me to the appropriate FM?
Don't underestimate the power of The Source
Debian unstable is generally stuff that's actually pretty stable compared to what goes in to other distros, and my experience with Gentoo has been different from yours. I have had 0 problems from emerge (portage). None. Granted, I've been using Linux for over a decade, but I don't believe that my success with Gentoo is based entirely on my experience with Linux.
I've never seen anyone who had problems with emerge breaking anything actually say what those problems were, though, so I'm a bit disinclined to believe the emerge was so much the problem as the user behind the keyboard. Two years ago, things may have been different, but so far teh only package-manager problems I've had were 1) the RPM database becomes corrupt, royally screwing my redhat system (would've screwed SuSE/etc just as hard), and 2) screwed up dependencies between RPMs.
I'm inclined to think that the problems people have on Gentoo are related to messing with things outside of the "Gentoo" way. Install a package outside of emerge without injecting it / making an eBuild? Move some config files around? Mixing stable with unstable? Problems might happen.
Like I said, two years ago things may have been different, or you might have hit a real bug, but I'm running 12 Gentoo machines right now on a mixture of architectures (x86 and PPC), and with sane CFLAGS / USE options I've not seen a single problem in the year or so that they've been up. During that year, most all of the packages have been updated at least once, including things like baselayout.
YMMV.
I'm not smug!
But launchd has obsoleted and replaced what used to be the status quo. Now it's the status quo.
I was refering to the status quo in the wider unix comunity and not specifically tiger.
I wish I could help, but no. My thoughts were to look for any glaring obvious problems, but I see nothing here blatant. Maybe try an Apple support board.
R: That voice. Where have I heard that voice before? B: In about 365 other episodes. But I don't know who it is either.
My only experience with emerge actually BREAKING was that portage's database of what was installed became corrupt and I had to rebuild it. (But this has happened to me on debian once before also.) The issue I was having was that the packages that were being chosen were causing problems. As in, nobody checked very well to see how they functioned before they were put into the main distro.
I did like alto of stuff about gentoo though. Such as their init scripts, and also the etc-update program. Those were handy. etc-update was kind of clumsy to begin with when you wanted to see diffs of the files. I eventually modified it so it would display them side-by-side in emacs.
Yes, programming declaratively (when you can) has many benefits over programming operationally. But remember that DTD, while declarative, isn't the most powerful declarative type system. Like you said, it can't handle multiple similar versions efficiently.
And remember, I'm not saying that you must use DTD. If it's not convenient, don't use it. I only brought this up to demonstrate that you can't use DTD to validate your plist XML data (in response to someone saying that using plist XML gives you validation for free).
Well, you can either write a declarative specification for every single type, or you can write code to manually validate every single type. Take your pick. Though DTD has its problems, this isn't one of them.
Their plist API gets no benefit, but I think you meant plist implementation. Old-style plists already have a well-tested parser (which, I'm guessing, they still have to support).
Besides, writing a parser is the uncommon case. You essentially only have to do it once. Writing and reading plists is an overwhelmingly more common case. I think the imbalance is high enough to warrant an specialized syntax for plists that is more readable (old-style plists) and efficient (binary plists). XML is neither (and, in fact, worse than old-style plists on both counts).
Also, parsing old-style plists is very easy. Sure, an XML library will let you avoid dealing with the low-level tokenizing details, but it's nothing that a 100-line Lex file couldn't handle for you. Now that I think about it, it might even be less work to parse old-style plists directly than to interface with an XML library and parse plist XML.
Even with the old format, the App's perspective is the exact same. Why do you keep talking about how plists are so great? The question here is whether plist XML is better than the old plist syntax (and answer no :).
The only thing they got was Unicode, which could have been trivially added to the old plist format. I agree that the performance degredation is tiny, but relative to the benefit (zero), it is infinite.
Not only wordier, but less readable. Because of the way Apple designed the format the only thing XML tools can do is try to offset the overhead created by XML in the first place. It's a net loss.
Think about what would happen if C++ was written in XML form. It might look something like this pile of crap. Would you rather edit that stuff in an XML editor or edit C++ in a text editor? It doesn't matter how good your
Man, you really can't take any criticism of your holy cow, can you?
Apparently Siracusa hasn't advanced beyond .bashrc or .cshrc; someone tell him about .login or .profile.
It's been at least 20 years since you could depend on programs that start your first shell of a session to correctly figure out whether they should start a login shell or not. And I've had them fail both ways. The only thing I've found that's at all workable is to have an environment variable that's got the PID of my login shell in it, and use that to figure out which kind of startup I should do.
That's right, any patent-related lawsuit against Apple voids the license.
Well, I'll set aside the "there's other kinds of patent-related lawsuits" bit, and get right to the point. And that is, I'm trying to see the downside to this clause for anyone who is acting ethically.
You're OK with the GPL, I take it. You don't consider the GPL a Trojan Horse or whatever it is you see in the APSL that bothers you, even though the GPL has a key clause that maks it a trjan horse, and the GNU manifesto makes clear that aspect of the GPL is one of the main reasons for it existing. Now, I'm not making a statement about whether the GPL is good or not, the GPL is clearly useful for a lot of people and has been an effective open source license. But it is a clear precedent that just being a trojan horse is not enough to make a license "non-free".
This clause prevents you from filing a patent infringement case against Apple except defensively. This is a problem if there's a good reason for filing a patent infringement case against Apple, other than defensively... IF you're in a business where access to Apple's source code is sufficiently important that this is a deterrent.
The distance between existing practice and the goal of the patent system... particularly in the areas of patent law that Apple is likely to violate... is so huge that while I am open to being convinced that this is a bad thing it'll take some doing. I don't see how this can be used effectively against individual creators, or against companies whose use of Apple's source code is an incidental part of their business, it's only useful against companies for which the software they're getting from Apple is going into their core business.
Now, what kind of patents are they likely to be holding?
Like, say, when I shut the lid of my powerbook? ;)
You think I'm talking about "using OS X" ? No, sorry, this is about using Apple's "open source" code. Might be on OS X, might be elsewhere.