I believe the OP meant that the qwerty keyboard is only available in landscape mode for Safari. One cannot, for instance use the wider landscape mode for keyboard input for Mail, etc. at this point.
I am not concerned by this. It is obvious that there will be many software releases in iPhone's future even for these 1.0 devices. If it is a big deal for many people, it can be fixed in the field.
Yes, Fred Anderson's lawyer did claim that he had warned Job's about the issue in 2001, and implied that Job's had misled Anderson.
However, in a press release today, the SEC made several statements that flatly contradict the CNN story.
The SEC said it isn't bringing enforcement action against Apple "based in part on its swift, extensive, and extraordinary cooperation in the commission's investigation."
They also stated that, "Apple's cooperation consisted of, among other things, prompt self-reporting, an independent internal investigation, the sharing of the results of that investigation with the government, and the implementation of new controls designed to prevent the recurrence of fraudulent conduct."
In short, the SEC stance appears to be that Anderson and Apple's former general counsel Nancy Heinen had the direct responsibility to review the board's decisions in this matter and make sure that Apple complied with reporting requirements. The SEC publicly stated that they are not bringing any action against Apple, they have settled with Anderson already, and will continue prosecuting Heinen (since she has chosen to fight the charges against her.
This is poor reporting on CNNs part, not a real story.
In your pathetic straw-man argument, you failed to acknowledge the fact that Apple refuses to license their DRM scheme to other mp3 players in order to form a monopoly, whereas Microsoft happily licenses their DRM scheme to whoever asks for it in order to encourage interoperability. I think you are seriously mistaken on both the points you tried to make.
1. You claim that Apple refuses to license FairPlay DRM in order to form a monopoly. While this is, indeed, a possible interpretation it is unlikely. Remember that when the iTunes music store launched, Apple needed to negotiate with the studios to reach agreement about iTunes DRM. At that date, the only alternatives were to create a new standard or use a form of DRM licensed from a third party (e.g. Microsoft, Real Media, etc.) Since Apple hoped the market would grow rapidly, it would have been foolish for them to pay royalties on the format as well as the content to third parties on each song sold. Also note, that at the time (and to my knowledge to this date) no DRM format developed for windows has been ported by a third party to work on the Mac. There is no need to suspect them of trying to form a DRM monopoly when simpler and less sinister motives explain the matter well. Apple has always claimed that they wanted to make DRM as open as possible given the restrictions imposed by the Media companies. Jobs then posted an open letter claiming that Apple would love to sell DRM free music and encouraged the Media owners to let them do so. He also explained (on technical rather than marketing grounds) why licensing fairplay DRM made no sense for Apple. Now that higher quality, DRM free music is available, Apple is the first to offer it.
All of this contradicts your claim that Apple refuses to license for reasons of forming a monopoly in a DRM format.
2. You praise Microsoft for "happily licensing their DRM scheme" to all other parties. That is currently not the case. In order to compete with the iPod an iTunes Microsoft developed the "Plays for sure" campaign using a proprietary DRM which worked only on Windows and on compliant players. They then licensed this to player manufacturers. This not only did not "Play for sure" since some puchased media would not play on all supposedly compliant devices. When the attempt to control the software and media format failed to gain share against iPod+iTunes, Microsoft then came up with the Zune approach.
Their DRM is more restrictive and less portable on computers than Apple's (Apple DRM also works on PCs but Microsoft DRM does not support Macs). They screwed their partners by dropping support for play for sure media in their hardware product, and not licensing Zune media to third party players.
How can you claim that Microsoft's foray into the music space was more open than Apple?
Besides, isn't TiVo the brand that removed 30-second forward skip, forces you to watch commercials, and auto-deletes programs?
Wow! How do you pack so much misinformation in one sentence?
You can enable 30 second skip on all models they have ever sold.
Tivo has never forced anyone to watch commercials.
If your Tivo is out of disk space it will remove the oldest recording that it is allowed to delete and reuse that space. If all of your recordings are marked "Keep until I delete" it will warn you (in advance) that it might not be able to record a scheduled program unless you delete some things.
In his paper "On the Cause of Geodetic Satellite Accelerations and Other Correlated Unmodeled Phenomena", via the American Geophysical Union in December 2005, he outlined specific modifications to general relativity. The paper's Abstract begins:
"An oversight in the development of the Einstein field equations requires a well-defined amendment to general relativity that very slightly modifies the weak-field Schwarzschild geometry yielding unambiguous new predictions of gravitational relativistic phenomena."
The result of this amendment is an additional relativistic effect. As you may know, in general relativity, the velocity of light is a constant. Thus one's velocity relative to a photon can result in a shift of measured frequency, i.e. the red-shift, or blue-shift of spectra. Also, since the theory claims that accelerated reference frames are identical, this shift is also observed due to gravitational acceleration.
The author claims that gravitationally induced red-shifting is also dependent on the angle through which a photon travels in a gravitational field. In addition, the theory discusses gravity and angular momentum. An accelerating electric charge emits electromagnetic energy. Though long theorized, a similar gravity wave has never been observed. The author suggests that angular momentum, e.g. spinning and orbiting masses emit electromagnetic energy as well. Thus, orbits even in a perfect vacuum will decay. As a spinning body slows, or orbital momentum decays, this energy will be balanced by radiation in the microwave range.
The additional source relativistic red shift, and the additional changes with respect to conservation of momentum, have profound cosmological import, if true. The theory passes the simplicity and beauty tests admirably. What I particularly like about his presentation has to do with testability.
He discusses numerous problems with the GPS and geodetic satellite systems, various puzzling data from several deep space missions, the orbits of planets and moons, and show how his equations account for the discrepancies in the data. He also proposes a number of simple experiments which could prove or disprove his theory. He predicts what to look for in terrestrial microwave radiation, and suggests experiments that could be run using existing satellites which could prove or disprove his theory. He also suggest that other scientist look at data which has already been collected but which he has never seen, and predicts what patterns might confirm the theory.
From the ground up, the ideas are well reasoned, and his approach seems scientifically sound.
Time gets into the mix, because the broader ramifications of the theory are large. Imagine a space ship under constant acceleration. On the floor (aft bulkhead) place two clocks communicating via pulses of light. He shows how each clock (even though they share the same acceleration reference frame) will each view the other as slow. By virtue of general relativity, pairs of clocks on earth should likewise each view the ticks of another clock as slow. Thus, there is no common, universal time. The rate of time is a local attribute at each location.
The cosmological implications if this theory are also impressive.
There is no need to posit dark matter or dark energy. They are discussed only to account for missing matter and the expansion of the universe. However, if this theory is true, the universe is not expanding, thus removing the need to postulate dark energy. The matter needed to keep galaxies from flying apart is no longer needed. Rotating galaxies are radiating microwaves and slowing down, not being gripped by dark matter. The universe finite and unbounded. It is neither expanding nor contracting.
No big bang would have happened. Remember the history of the theory? It was attempting to account for red shifted stellar spectra and for the microwave background. If the red shift is a relativistic phenomenon (not the result of unive
It does not matter whether Fox would be interested in another season.
Joss Whedon has stated numerous times, that he will never work with Fox again. He wants to do more with Firefly, but says that he refuses to do so unless Fox will relinquish the rights. If another studio buys the rights from Fox, the series might have a future. If Fox wanted him (or probably any original cast members) to make more episodes, they would refuse.
G) The CEO realizes that it is not about selling a mouse and sees the bigger picture.
Many people look at this mouse, compare it to other offerings, and are puzzled. It is not revolutionary, other mice offer far more features at a lower price. This is not a big deal. Those people are correct. This is just a mouse. Compared to other mice on various features it is not very compelling. Thus, in this context, it is not a big deal.
Other people look at the mouse and comment on Apple as a company. They observe that this product is neither innovative nor particularly novel. They conclude that Apple has failed to provide anything "insanely great", and either wonder why this news is worthy of attention or deride the company and its users for various reasons. These people have a point. This mouse is neither innovative nor "insanely great. Again, this is not a big deal.
However, since the late 90s, most product releases by Apple have been far more important in context than in isolation. I think this small product is more important than is obvious under casual scrutiny.
Apple tends to develop all its products by focusing on the interactions of individual users with Hardware+Software systems. They spend less time than other companies thinking about feature checklists. They spend less time on the impact of hardware or software in isolation, and focus more on how they are used together. Also, though they do attend to the desires of power users, they never place this goal above the requirements of ease of use and productivity for the majority of users.
In recent years users have realized that support for both scrolling and pointing improves ease of use. They added scrolling support to the laptop systems recently. This mouse adds that for their other products. Second, many users buy third party mice both for scrolling support and for one-click access to contextual menus. Thus, adding an option for right click operation makes sense. Finally, recent additions to the operating system have become very popular. Dashboard widgets and Expose are used frequently by many users. Providing a way to improve the speed of and reduce the effort for accessing these features would improve productivity and ease of use for many.
The design of this mouse meets all of these primary goals admirably. It provides scrolling support. It provides simple access to dashboard and expose functionality. It provides one button Control-Click functionality for those users who want it. Users who are prefer (are are only familiar with) single button mice, will not have to unlearn any old habits or have difficulty understanding or using the new scrolling, Dashboard, or Expose functionality.
A user of an off-the-shelf 4 button mouse (or 3 real buttons and a clickable scroll wheel) can configure their mouse to provide equivalent functionality already. So, even in the broader context, they can get similar functionality at a lower price from a third party. However, for a large proportion of the user base, I suspect that this mouse may be a better option. Is it significantly better than the alternatives? Will this mouse sell well? Since it is largely Windows compatible, will many PC users buy them? My guess is that the answer to each of these questions is largely irrelevant. Apple would obviously to prefer to sell more mice rather than fewer mice. In the big picture, however, I think this is insignificant. I also think Apple knows this.
The revenue from selling these mice, even at $50 is insignificant. Taking market share away from third party mouse vendors is insignificant. Is anything significant here? I think so.
1. Apple looked at ways to improve user interaction with Macos X and the most commonly used bundled apps and iLife. They designed a mouse that provides significant benefits to most users performing common activities with bundled apps and iLife. 2. Apple is aware that multi-button vs. single button mice has long been a source of both misconception and controversy, even though for most users and for Apple
People have been selling movies for years, people have been recording from radio for years. Now I guess because its on the internet its somehow different? Whats the difference? This isnt new.
A vanishingly small minority of people were abusing fair use privileges with VCRs and audio cassettes. They typically recorded broadcast material for personal use. With audio tapes many people also made mix tapes or transcribed albums onto cassette to play in their cars, walk-man devices, etc. Your claim that "people have been selling movies for years" is specious. That practice was always expressly forbidden and the vast majority of user never did so. Most people who recorded material from radio broadcasts also did so in a fashion that was similar to time-shifting. They did so for personal use, not for sale to others.
It is not that the internet is different. The issue is the use to which it is being put. Using a recording/playback mechanism for personal use is still fair game. It is fine to back things up, to record and play back for purposes of time-shifting, and to transfer media you own to another format for more flexible personal use.
There are a number of file sharing networks and P2P products which were expressly designed, and marketed to end-users for the purpose of ripping and sharing copyrighted material with others. This is not "fair use" by any stretch of the imagination. The problem is not the internet per se, or even P2P networks per se. The problem is programs and networks whose design, marketing, and substantial use have no legal justification under the fair use provisions of copyright law.
Your words strike me as disingenuous (and frankly dishonest). Attempting to justify unethical behavior by citing a prior illegal practice (recording and selling movies) is rather childish. Comparing the practice of recording music from the radio for personal use to uploading and downloading music ripped from CDs for the sole purpose of indiscriminate sharing with others is tenuous.
Grokster and certain other programs+networks are clearly promoting copyright infringement. They are not innocent bystanders to their users' infringing activity. The vast majority of users are stealing music rather than using the tools in ways which are covered by fair use provisions. Do you honestly think that the tool was not expressly designed to support this activity? Do you believe that the advertising did not explicitly encourage such use? Are you naive enough to believe that the majority of users do not use the program primarily to trade copyrighted material in ways which are expressly forbidden?
Grokster was promoting copyright infringement. They did everyone a disservice by attempting to hide behind the Sony/Betamax decision. The Supreme court called a spade a spade and sent it back to the lower court. The decision seems fair and reasonable.
The stated purpose of video recorders was to enable users to record over-the-air broadcast signals for viewing at a later time. The behavior of the vast majority off users was consistent with this declaration of intent.
Most people did record programming off the air, and replay it one or more times. They did not, duplicate the recording and subsequently sell or trade those tapes with others. Their application of the technology was clearly an issue of fair use under the copyright laws.
Music sharing software has been marketed for a number of years with the clear understanding that the user will gain access to a large number of songs that they may download for free. Making a copy of your music, as a backup copy, or as a means of enabling you to listen to it on other devices you own is a fair use. Providing copies of the music to numerous others people, who do not own legal copies of a work, is clearly a different matter. It goes against both the letter of the law, and the underlying intent of copyright law.
The white-paper and the web pages on the company site which describe the implementation talk about how this is done.
This card, and the software which drives it, differ from traditional ethernet accellerator cards and from alternative network protocols (like myrinet and iWarp) in several ways.
Alternative protocols not only require using a different software API but also require custom hardware at both communication endpoints.
Traditional hardware TCP/IP accelerators run the bottom half of the stack in custom silicon. This does tend to help reduce host CPU load but suffer from a number of problems. Since host CPU speeds have tended to increase regularly, they often helped for only a brief period of time. They also tended to help most for large packets but helped little or not at all for small packets.
This technology claims to help large and small packets equally well, and also claims to reduce packet latency across the board. It does so by running the bulk of the TCP/IP stack in user space rather than via system calls. The hardware runs ethernet Rx and Tx processing but does not implement the higher level IP protocol processing. Instead, once connections are established, the ethernet frames coming from the hardware, are fed via a system call interface to the application process to which they belong. Then, no further context switching between kernel and the process are required. The top end of the hardware driver and all of the subsequent IP layers, are executed in the context of the user space process. They are linked to the app via shared libraries.
Basically, instead of the linking the IP calls against code which requires frequent switching between user and kernel space, the entire upper half of the stack is run by the application sending and receiving the packets. This offers uniform benefits in packet latency across all packet sizes, and offers improvement in throughput as well.
I assume that all that is required is to link against a different set of shared libraries to gain these benefits (and of course to have the custom hardware on at least one side of the comm. link). This looks very good in principle.
It would help if Apple were very very clear on why this option was chosen and what they intend to do.
Jobs was very clear about that in the keynote speech.
By 2006 and beyond, Intel chips will have much better Performance/Watt ratios than PowerPC.
That seems pretty clear to me.
What does that mean?
The Power architecture does have a number of strengths. However, the roadmap for future improvements to the PowerPC line will lag significantly behind future chips from Intel in that regard.
Cooling, noise, and the increasing prevalence of portable computers make Intel more favorable in the long run for the types of products that Apple wants to build.
G5 laptops were too hungry and dissipated too much heat to put in a laptop. 'Nuff said.
However, it's not likely to affect many people. I, and most people that I know, use macs because the software (both OS and Apps) are so pleasant and reliable to use.
The thought of being able to run really crappy software again doesn't float many boats.
They've been building everything on PowerPC and Intel at the same time for five years.
How is that surprising. The bulk of the OS is the direct descendant of NeXTStep.
The base development tools have compiler flags to select processor family and subtype. They can compile natively, cross compile for another type, or do both simultaneously to create a fat binary (now called a Universal Binary).
The initial apple developer releases (pre 2000) all shipped for both intel and PPC.
The base OS, Darwin, has always been supplied for both architectures.
All of the code used for reading and writing objects and data files, or communicating via remote objects has always been endian neutral.
None of this ever changed.
Wow, would be a natural response only if they had deliberately abandoned that testing/support internally.
They're all things that were imported from FreeBSD and given a GUI.
Incorrect. Some are things which derived from the Mach BSD roots on which NeXTStep -> OPENSTEP rested.
For instance mach ports are used to provide another layer of privilege separation which are a superset of the unix world. This one is equivalent to a capability model and is based on mach ports.
One way this is used is to provide a means to define separate domains of privilege for tasks which are spawned at boot time or via other daemons, those which relate to remote logins, and those which are related to the window manager or login domain.
It is fundamentally impossible for a task in one domain to forge or acquire the mach port of another domain.
FreeBSD was used as a base for updating Unix components from 4.3 BSD to 4.4 BSD.
On the PC, I have to troubleshoot all the time...I don't look at it as time unproductive, I look at it as time educating myself for when it happens to the next person at work, or friends, or next door neighbors.
Macs? I'll see a problem and it is a waste of my time...I'll never find anyone with that exact problem again and its 3 hours wasted.
What a narrow, misguided viewpoint.
1. You have to solve problems all the time. 2. Your co-workers, friends and neighbors have problems frequently.
You consider solving rare and infrequent problems a waste of time, and yet don't consider the problems you claim to solve frequently to be a waste of time. Rare and infrequent problems rarely and frequently are encountered by either you or by others, thus represent time which you and they can use at their discretion. In comparison this seems like the opposite of "wasted time"
It is sad that you and others are forced to devote so much of your time to problems. It is misguided, because you rationalize the real time wasted and fail to see real underlying situation.
I grant that you may prove helpful to others by helping them solve similar problems in the future. This is beneficial to you by improving other's sense of your worth. You gain both social and psychological benefit from this. You benefit indirectly from the misfortune of others and justify your own (inherently unproductive) effort by marginally reducing the perceived cost of other people's problems. Actually, both you and your cohorts are collectively wasting a great deal of time. This is OK with you, because you get some other benefits from it. I don't denigrate you for this, it is a natural and basic part of being human. Just don't delude yourself. You don't consider it a waste of time for you because it is paid for by a larger volume of other people's wasted time.
This is not a zero sum game. Each of you collectively are taxed with a huge burden in wasted time, effort, and enjoyment. Use whatever hardware and software you wish, I honestly don't care. However, at least be honest. Both you and they are wasting a great deal of time compared to equivalent groups of Mac users.
The risk-reward ratio is way too low on this one. Basically, they're asking for a technological innovation on par with the light bulb
This is not grand innovation by any interpretation. This challenge, like the others, is about incrementally extending the state of the art. It is about practical, innovative application of technology, not about science.
Basically, the moon contains a great deal of oxygen, but the vast majority of it is found in molecules which bind the oxygen tightly. Some metallic oxides like iron oxide are fairly easy to crack. On the surface of the earth, iron oxide is abundant. On the moon, however, the most common oxides are of silicon, aluminum, calcium and titanium. These elements are bound very tightly to their oxygen, and require either great deals of energy and/or powerful chemical reagents (reducing agents) to liberate.
This explains why these elements were not isolated in pure form by chemists until the the first quarter of the 19th century, and in the case of aluminum, why it was far more valuable than gold until the dam at niagara falls produced sufficient cheap power to make production worth while.
Using Hydrogen as the reducing agent liberates some oxygen cheaply but leaves a great deal behind, but is easier to work with. More powerful agents such as fluorine, or sodium hydroxide are far more effective at reducing these oxides into oxygen and metal. However they are extremely corrosive and pose some tricky engineering challenges.
For instance, sodium hydroxide is great but requires the use of nickel electrode which are consumed by the reaction. Nickel is very rare on the lunar surface.
Chlorine, and even carbon based reactions are possible.
So the challenge is to explore the various engineering trade-offs. Weight, energy input, size, speed, and the amount of raw materials brought from earth and consumed by the process all need to be balanced.
$250 grand is surely a decent incentive for chemists and engineers to tinker with various designs.
By strip mining the surface of the moon we might end up with large areas of the surface which are barren expanses of rock and dust, devoid of soil or life...
You have provided some good information, but it is incomplete. You probably are doing the right things to analyze this problem but in the absense of explicit statements I have no information on which to determine that.
It is imperative to determine whether the executable is being called, to determine that launchd is listening, and that you are connecting the the right port. Your xinetd configuration specified that the pop server was not using ssl and was listening on port 110 only. Your launchd configuration is listening on port 995 but not on 110. Since you did not specify what program or what port you were using to test the localhost connection, I cannot determine if the fault is with launchd or some other configuration problem.
1. I suggest you use telnet to determine if if you can connect to port 995. You can also use netstat -a and lsof to verify that launchd is or is not listening to the port. If it is listening, verify that your mail programs are attempting to connect via the SSL port not the vanilla imap port (110). 2. Use log files to verify that neither launchd nor pop3 are throwing errors.
You claim that the plist file you created is working fine.
If that is the case, the first thing to check is the firewall. In Preferences.app check the firewall settings and verify that ports used by ipop are open. Open both 110 (pop3) and 995 (pop3s which is SSL/TLS protected).
If you have difficulty connecting after verifying the firewall permissions, I suggest you try connecting to localhost to test the server. If localhost connections are not working, go back to the plist file until you can connect locally.
No it was not a "copy-and-paste" job. I wrote it while reading the source code and documentation for the launchd module. It is open source after all.
The parent to my post, and the grandparent as well, had commented on the parallelism and boot speed of the Macos X boot process. Those comments suggested to me that they were posting based on familiarity with SystemStarter, and confusion about launchd. Even the Subject seemed to indicate this confusion. Not a cron relacement, a init replacement is false. Yes, it is partly an init replacement, but also a cron replacement, xinetd replacement, and several other things which have no direct counterpart in other unices - such as a means of writing ad hoc queue processing scripts.
launchd is about generalizing process launching regardless of whether a process is run based on a temporal trigger or request for service. SystemStarter provides relative ordering of scripts based on a graph of Requires/Provides definitions. I realize that SystemStarter is deprecated for most tasks for which it was historically used. However, the need for both SystemStarter and launchd seems clear.
I see no means within the launchd subsystem of cleanly specifying dependancies among different daemon plists (or groups of them). For this SystemStarter still seems appropriate. Launchd will of course be the preferred choice for most tasks, not least because it encourages a pattern of lazy evaluation for most system services and obviates the need for scores of daemons to poll or sleep until they have work to do.
Without requires/provides, however, launchd cannot do everything. Until it does, SystemStarter (also distributed in the launchd-106 tar ball) is still needed. On my primary Panther install there are 33 StartupItems in/System/Library. On my Tiger partition there are 17. Launchd replaces SystemStarter for the majority of both system and third party uses. It does not replace it entirely yet. With the absence of dependency ordering, I do not see how it could replace the rest.
However, the question is are we losing simplicity for features?
Good question.
Let's look at it. When are programs run? The simplest answer is "when they need to."
No, I'm not being snide, merely rhetorical. When do programs need to run?
Programs need to run for a variety of reasons. Some need to to run when the machine is booted. Others need to run at particular times. Some, like certain network server processes are needed only when a user or another program requests service (e.g. accept connections on protocol/port). Others are spool oriented programs where files in a queue directory need to be processed when present but have no work to do when the queue is empty.
So rc scripts run programs at boot time which either do some work and die or act as standalone servers which are intended to live forever (or until they are explicitly told to stop). init runs programs (like getty processes) which are long lived and are respawned when they die. inetd/xinetd listens for connection attempts to network ports and spawns server processes on ports. cron runs programs based on a schedule, the passage across a point in time triggers execution.
launchd provides a superset of the above triggers for spawning programs.
Think of it as Run Program [ProgramArgs] [ TemporalTrigger | ServiceRequiredTrigger ]
By default, the simplest launchd file says "Run this program now just once.". It is thus a simple rc script which, at boot time, runs something and at shutdown time can be told to stop. Adding a further key/value pair can say "restart on exit," thus replacing inittab/init based functionality. Specifying a family/protocol/port says listen and start me when needed to serve a network request al a inet. Adding a qualifier to this type of socket definition says connect() to an address, instead of the more typical bind()/listen()/accept(). Specifying time based activation covers cron functionality, if you need at functionality specify the environment variable and working directory as well. To enable spool-like behavior or programs tied to arbitrary file system activity watch a file or directory for changes.
Most Unix subsytems only support system level operation. launchd distinguishes whether a process description is system wide or based on user login simply by where the file is found. A launchd plist file found in a LaunchDaemons directory will be loaded on system startup. One found in a LaunchAgents directory will load when a user logs in, and unload on logout. The syntax of the file will be identical in either case.
So, the launchd plist files (short for property lists) contain a set of key/value pairs describing what to run, and when to run it. Beyond this, launchd defines keys which tailor how the program is run, all of which are optional. These include specifying: user and group by either name or uig/gid; working directory, chroot directory, a dictionary of environment variables, CPU niceness, umask. Do you want to limit how much memory or stack it uses, prevent it from wiring system memory? Do you want limit the number of children it can spawn, or treat its IO requests as low priority as urgent? Keys are available for that.
So is this simpler or more complex? In the big picture I believe that this simplifies things tremendously. Launchd defines a tiny language for specifying how and when to run processes. It covers all the traditional triggers of init, rc files, cron, and inetd. It specifies the environmental and security issues of su/sudo, chroot, ulimit, umask, nice and at. It covers both system level startup/shutdown as well as user level login/logout.
Because of well chosen defaults, most launchd input files will be very short and to the point, only specifying the direct functionality they need. Adding just a few more key/value pairs can obviate the need for the majority of moderately complex rc and daemon startup files. Since launchd also obviates the need to daemonize, close files descriptors, fo
Re:Not a cron replacement, a init replacement
on
Does launchd Beat cron?
·
· Score: 5, Informative
The launchd source code is a collection of programs which span several related areas. In the broadest terms the contents of the distribution cover init, SystemStarter, and launchd.
Most people talking about launchd in the context of parallel system startup are actually talking about SystemStarter. Also note that the plist files which drive SystemStarter can be in one of two forms. The most common of these is the NeXT style textual plist format which is very human friendly and is not XML-like in structure or appearance.
As a replacement for aither BSD style or System 5 style rc scripts, SystemStarter is a definite improvement, both in terms of ease of use, speed, and reliability. The launchd subsystem uses XML formatted property lists. I am unsure whether NeXT style plists are supported for these.
Regardless, you were dismissive of launchd claiming that it was mere init replacement. You thought you were speaking about launchd but sound like you had only heard about SystemStarter.
launchd itself it a super-server which reads process definitions. These definitions can describe processes to be run using a set of predefined keys. Some examples of key value pairs are: Program/ (path to executable), or ProgramArguments/ (The array of strings to pass as arguments to the program). The interesting thing about launchd is that the predefined key/value space is so rich, and so well considered.
The keys span several related domains which Unix users associate with a number of different tools and data sources. Here are a list of some interesting areas covered.
like sudo or vixie cron the user and group under which to launch the program can be specified using any of { UserName, UID, GroupName, GID }
WorkingDirectory causes a chdir(2) before executing the job. RootDirectory specieis a chroot(2) for the child process.
StdOutPath and StdErrPath can specify where to redirect output of the program.
OnDemand specifies whether to run only as needed or ensure that a server process should always be available, thus respawned.
Labels and Groups provide a way to refer to processes with greater specificity or to group related processes together for reporting or action using launchctl.
A set of time specific keywords cover a superset of at and cron time specification.
Soft and hard resource limits for the job can be tuned using keys that provide acces to all ulimit functionality (file descriptor file size, memory footprint, core size, etc.. Similarly the nice value can be specified to constrain CPU usage, and the *PriorityIO keys specify what priority the kernel should use for scheduling disk IO for this task.
The Socket Key defines an optional dictionary defining IPC behaviors controlling combinations of open/bind/connect/listen. (think inetd and xinetd). Beyond this you can also specify other things here like "Bonjour" to register this service with mDNSResponder. If a SockPathName is specified attempts to open a named unix domain socket will cause this program to launch.
If these are not enough, a launchd plist can start/stop a program when a watched file changes. When passed the path to a directory, the program can be started when the program is not running and the directory is not empty. Think about this one... A robust queue processing program might be simply: #!/bin/sh lockfile $SOMELOCKFILE for file in * do
process "$file" done
WorkingDirectory and a watched directory path, along with whatever CPU/Disk IO/Memory/user/group are all handled by launchd. Similarly launchd ensures that the process runs when there is work to do, and is never launched unless there is work to do.
Finally, if the predefined keys and actions are insufficient you can call a small number of stubs implemented in Tcl to set either one shot timers or interval timers at which point the scripts is re-interpreted. You can pass messages to syslogd, start or stop jobs. A form of system introspection is also pr
I am interested in the metadata aspects also, but my view on where it is going differs from yours. You state that: this is just crying out for a BeOS style arbitrary metadata creation/editing application. I like the functionality that has been added, but do not wish a return to the older MacOS uses of metadata or a BeFS-like set of functionality.
Those nostalgic for BeFS might wish to see more low level use of metadata in ways that integrate it tightly into the underlying file system. In BeFS the underlying disk format was a Btree varant that supported arbitrary key value pairs on each node. Each key was indexed subsequent to being added, thus each new type of metadata became a first class citizen with the standard metadata predefined by the file system.
The Old-school Macintosh metadata camp liked the resource fork, which enabled developers to define additional data to be associated with file contents using key/value pairs. In this case the keys were not arbitrary like in BeOS, but limited to 4byte quantities (or in the case of Creator/Type codes pairs of 4 bytes keys). When HFS became HFS+ the underlying storage system was extended so that data/resource forks were suplemented by an arbitrary number of additional named resource forks. MacOS 9 and earilier versions of MacOS X never made use of this.
What I disliked about these earlier implementations of metadata was that they isolated MacOS and BeOS users from other systems. Copying a file from system to system either lost the metadata or resource information or made the information less accessible to users of other systems. Additionally, the native code to make use of this functionality was part of the Be C++ libraries or, on the Mac, part of what is now Carbon. Thus, even in MacOS X, using such functionality required linking to additional libraries which were pretty much guaranteed not to exist anywhere else. Writing otherwise portable Unix code, or Cocoa code (which could theoretically run on GnuStep) still required Carbon calls to make use of the old style metadata.
This strikes me as bad news. Similarly, writing low level BeFS-like functionality on top of this seems equally ill-conceived.
This implementation of metadata appears fundamentally different. The underlying storage mechanism leverages the named resource fork functionality of HFS+ (which is local to the MacOS X space). Despite this, the software mechanism for storing and querying this information is based on the POSIX extended attributes model. This means that programs which want to use new metadata on MacOS X can be ported to systems that implement the POSIX(1e) attribute model. It resides in the BSD space, not in the Cocoa, Carbon, or even HFS specific space. This is the right way to do it.
The primary goal for using this approach was probably not to increase the use of metada at all, but to add support for Access Control Lists (ACLs). Both Linux and FreeBSD have implemented ACLs based on the storage of ACL information in the form of posix extended attributes. This leveraged the fine wok done by Watson et al for the BSD world in security, it made the most sense to implement posix style extended attributes in MacOS X. Viola, nearly for free, by exposing this underlying storage to the command line, we now have an arbitrary resource subsystem where Unicode string keys can hold arbitrary values for filesystem objects.
The long term ramifications of this are that NFSv4 implementations which support the optional metadata extensions will interoperate well. BSD* and MacOS X based clients and servers will have complementary access to both ACL information and other metadata. Likewise Samba ACLs will interoperate between Mac and Windows networks. If you write an executable to store and retrieve this information it should be portable to FreeBSD, LInux, or any commercial Unix which implements the Posix extended attributes in a clean way. The storage for this metadata may be part of the native file system (as it is in HFS+), but need not be.
Slashdot Mirror
I believe the OP meant that the qwerty keyboard is only available in landscape mode for Safari. One cannot, for instance use the wider landscape mode for keyboard input for Mail, etc. at this point.
I am not concerned by this. It is obvious that there will be many software releases in iPhone's future even for these 1.0 devices. If it is a big deal for many people, it can be fixed in the field.
CNN is not reporting the whole story.
Yes, Fred Anderson's lawyer did claim that he had warned Job's about the issue in 2001, and implied that Job's had misled Anderson.
However, in a press release today, the SEC made several statements that flatly contradict the CNN story.
The SEC said it isn't bringing enforcement action against Apple "based in part on its swift, extensive, and extraordinary cooperation in the commission's investigation."
They also stated that, "Apple's cooperation consisted of, among other things, prompt self-reporting, an independent internal investigation, the sharing of the results of that investigation with the government, and the implementation of new controls designed to prevent the recurrence of fraudulent conduct."
In short, the SEC stance appears to be that Anderson and Apple's former general counsel Nancy Heinen had the direct responsibility to review the board's decisions in this matter and make sure that Apple complied with reporting requirements. The SEC publicly stated that they are not bringing any action against Apple, they have settled with Anderson already, and will continue prosecuting Heinen (since she has chosen to fight the charges against her.
This is poor reporting on CNNs part, not a real story.
1. You claim that Apple refuses to license FairPlay DRM in order to form a monopoly. While this is, indeed, a possible interpretation it is unlikely. Remember that when the iTunes music store launched, Apple needed to negotiate with the studios to reach agreement about iTunes DRM. At that date, the only alternatives were to create a new standard or use a form of DRM licensed from a third party (e.g. Microsoft, Real Media, etc.) Since Apple hoped the market would grow rapidly, it would have been foolish for them to pay royalties on the format as well as the content to third parties on each song sold. Also note, that at the time (and to my knowledge to this date) no DRM format developed for windows has been ported by a third party to work on the Mac. There is no need to suspect them of trying to form a DRM monopoly when simpler and less sinister motives explain the matter well. Apple has always claimed that they wanted to make DRM as open as possible given the restrictions imposed by the Media companies. Jobs then posted an open letter claiming that Apple would love to sell DRM free music and encouraged the Media owners to let them do so. He also explained (on technical rather than marketing grounds) why licensing fairplay DRM made no sense for Apple. Now that higher quality, DRM free music is available, Apple is the first to offer it.
All of this contradicts your claim that Apple refuses to license for reasons of forming a monopoly in a DRM format.
2. You praise Microsoft for "happily licensing their DRM scheme" to all other parties. That is currently not the case. In order to compete with the iPod an iTunes Microsoft developed the "Plays for sure" campaign using a proprietary DRM which worked only on Windows and on compliant players. They then licensed this to player manufacturers. This not only did not "Play for sure" since some puchased media would not play on all supposedly compliant devices. When the attempt to control the software and media format failed to gain share against iPod+iTunes, Microsoft then came up with the Zune approach.
Their DRM is more restrictive and less portable on computers than Apple's (Apple DRM also works on PCs but Microsoft DRM does not support Macs). They screwed their partners by dropping support for play for sure media in their hardware product, and not licensing Zune media to third party players.
How can you claim that Microsoft's foray into the music space was more open than Apple?
Besides, isn't TiVo the brand that removed 30-second forward skip, forces you to watch commercials, and auto-deletes programs?
Wow! How do you pack so much misinformation in one sentence?
You can enable 30 second skip on all models they have ever sold.
Tivo has never forced anyone to watch commercials.
If your Tivo is out of disk space it will remove the oldest recording that it is allowed to delete and reuse that space. If all of your recordings are marked "Keep until I delete" it will warn you (in advance) that it might not be able to record a scheduled program unless you delete some things.
Please stop harping about Lorenz and time.
In his paper "On the Cause of Geodetic Satellite Accelerations and Other Correlated Unmodeled Phenomena", via the American Geophysical Union in December 2005, he outlined specific modifications to general relativity. The paper's Abstract begins:
"An oversight in the development of the Einstein field equations requires a well-defined amendment to general relativity that very slightly modifies the weak-field Schwarzschild geometry yielding unambiguous new predictions of gravitational relativistic phenomena."
The result of this amendment is an additional relativistic effect. As you may know, in general relativity, the velocity of light is a constant. Thus one's velocity relative to a photon can result in a shift of measured frequency, i.e. the red-shift, or blue-shift of spectra. Also, since the theory claims that accelerated reference frames are identical, this shift is also observed due to gravitational acceleration.
The author claims that gravitationally induced red-shifting is also dependent on the angle through which a photon travels in a gravitational field. In addition, the theory discusses gravity and angular momentum. An accelerating electric charge emits electromagnetic energy. Though long theorized, a similar gravity wave has never been observed. The author suggests that angular momentum, e.g. spinning and orbiting masses emit electromagnetic energy as well. Thus, orbits even in a perfect vacuum will decay. As a spinning body slows, or orbital momentum decays, this energy will be balanced by radiation in the microwave range.
The additional source relativistic red shift, and the additional changes with respect to conservation of momentum, have profound cosmological import, if true. The theory passes the simplicity and beauty tests admirably. What I particularly like about his presentation has to do with testability.
He discusses numerous problems with the GPS and geodetic satellite systems, various puzzling data from several deep space missions, the orbits of planets and moons, and show how his equations account for the discrepancies in the data. He also proposes a number of simple experiments which could prove or disprove his theory. He predicts what to look for in terrestrial microwave radiation, and suggests experiments that could be run using existing satellites which could prove or disprove his theory. He also suggest that other scientist look at data which has already been collected but which he has never seen, and predicts what patterns might confirm the theory.
From the ground up, the ideas are well reasoned, and his approach seems scientifically sound.
Time gets into the mix, because the broader ramifications of the theory are large. Imagine a space ship under constant acceleration. On the floor (aft bulkhead) place two clocks communicating via pulses of light. He shows how each clock (even though they share the same acceleration reference frame) will each view the other as slow. By virtue of general relativity, pairs of clocks on earth should likewise each view the ticks of another clock as slow. Thus, there is no common, universal time. The rate of time is a local attribute at each location.
The cosmological implications if this theory are also impressive.
There is no need to posit dark matter or dark energy. They are discussed only to account for missing matter and the expansion of the universe. However, if this theory is true, the universe is not expanding, thus removing the need to postulate dark energy. The matter needed to keep galaxies from flying apart is no longer needed. Rotating galaxies are radiating microwaves and slowing down, not being gripped by dark matter. The universe finite and unbounded. It is neither expanding nor contracting.
No big bang would have happened. Remember the history of the theory? It was attempting to account for red shifted stellar spectra and for the microwave background. If the red shift is a relativistic phenomenon (not the result of unive
It does not matter whether Fox would be interested in another season.
Joss Whedon has stated numerous times, that he will never work with Fox again. He wants to do more with Firefly, but says that he refuses to do so unless Fox will relinquish the rights. If another studio buys the rights from Fox, the series might have a future. If Fox wanted him (or probably any original cast members) to make more episodes, they would refuse.
G) The CEO realizes that it is not about selling a mouse and sees the bigger picture.
Many people look at this mouse, compare it to other offerings, and are puzzled. It is not revolutionary, other mice offer far more features at a lower price. This is not a big deal. Those people are correct. This is just a mouse. Compared to other mice on various features it is not very compelling. Thus, in this context, it is not a big deal.
Other people look at the mouse and comment on Apple as a company. They observe that this product is neither innovative nor particularly novel. They conclude that Apple has failed to provide anything "insanely great", and either wonder why this news is worthy of attention or deride the company and its users for various reasons. These people have a point. This mouse is neither innovative nor "insanely great. Again, this is not a big deal.
However, since the late 90s, most product releases by Apple have been far more important in context than in isolation. I think this small product is more important than is obvious under casual scrutiny.
Apple tends to develop all its products by focusing on the interactions of individual users with Hardware+Software systems. They spend less time than other companies thinking about feature checklists. They spend less time on the impact of hardware or software in isolation, and focus more on how they are used together. Also, though they do attend to the desires of power users, they never place this goal above the requirements of ease of use and productivity for the majority of users.
In recent years users have realized that support for both scrolling and pointing improves ease of use. They added scrolling support to the laptop systems recently. This mouse adds that for their other products. Second, many users buy third party mice both for scrolling support and for one-click access to contextual menus. Thus, adding an option for right click operation makes sense. Finally, recent additions to the operating system have become very popular. Dashboard widgets and Expose are used frequently by many users. Providing a way to improve the speed of and reduce the effort for accessing these features would improve productivity and ease of use for many.
The design of this mouse meets all of these primary goals admirably. It provides scrolling support. It provides simple access to dashboard and expose functionality. It provides one button Control-Click functionality for those users who want it. Users who are prefer (are are only familiar with) single button mice, will not have to unlearn any old habits or have difficulty understanding or using the new scrolling, Dashboard, or Expose functionality.
A user of an off-the-shelf 4 button mouse (or 3 real buttons and a clickable scroll wheel) can configure their mouse to provide equivalent functionality already. So, even in the broader context, they can get similar functionality at a lower price from a third party. However, for a large proportion of the user base, I suspect that this mouse may be a better option. Is it significantly better than the alternatives? Will this mouse sell well? Since it is largely Windows compatible, will many PC users buy them? My guess is that the answer to each of these questions is largely irrelevant. Apple would obviously to prefer to sell more mice rather than fewer mice. In the big picture, however, I think this is insignificant. I also think Apple knows this.
The revenue from selling these mice, even at $50 is insignificant. Taking market share away from third party mouse vendors is insignificant. Is anything significant here? I think so.
1. Apple looked at ways to improve user interaction with Macos X and the most commonly used bundled apps and iLife. They designed a mouse that provides significant benefits to most users performing common activities with bundled apps and iLife.
2. Apple is aware that multi-button vs. single button mice has long been a source of both misconception and controversy, even though for most users and for Apple
People have been selling movies for years, people have been recording from radio for years. Now I guess because its on the internet its somehow different? Whats the difference? This isnt new.
A vanishingly small minority of people were abusing fair use privileges with VCRs and audio cassettes. They typically recorded broadcast material for personal use. With audio tapes many people also made mix tapes or transcribed albums onto cassette to play in their cars, walk-man devices, etc. Your claim that "people have been selling movies for years" is specious. That practice was always expressly forbidden and the vast majority of user never did so. Most people who recorded material from radio broadcasts also did so in a fashion that was similar to time-shifting. They did so for personal use, not for sale to others.
It is not that the internet is different. The issue is the use to which it is being put. Using a recording/playback mechanism for personal use is still fair game. It is fine to back things up, to record and play back for purposes of time-shifting, and to transfer media you own to another format for more flexible personal use.
There are a number of file sharing networks and P2P products which were expressly designed, and marketed to end-users for the purpose of ripping and sharing copyrighted material with others. This is not "fair use" by any stretch of the imagination. The problem is not the internet per se, or even P2P networks per se. The problem is programs and networks whose design, marketing, and substantial use have no legal justification under the fair use provisions of copyright law.
Your words strike me as disingenuous (and frankly dishonest). Attempting to justify unethical behavior by citing a prior illegal practice (recording and selling movies) is rather childish. Comparing the practice of recording music from the radio for personal use to uploading and downloading music ripped from CDs for the sole purpose of indiscriminate sharing with others is tenuous.
Grokster and certain other programs+networks are clearly promoting copyright infringement. They are not innocent bystanders to their users' infringing activity. The vast majority of users are stealing music rather than using the tools in ways which are covered by fair use provisions. Do you honestly think that the tool was not expressly designed to support this activity? Do you believe that the advertising did not explicitly encourage such use? Are you naive enough to believe that the majority of users do not use the program primarily to trade copyrighted material in ways which are expressly forbidden?
Grokster was promoting copyright infringement. They did everyone a disservice by attempting to hide behind the Sony/Betamax decision. The Supreme court called a spade a spade and sent it back to the lower court. The decision seems fair and reasonable.
The stated purpose of video recorders was to enable users to record over-the-air broadcast signals for viewing at a later time. The behavior of the vast majority off users was consistent with this declaration of intent.
Most people did record programming off the air, and replay it one or more times. They did not, duplicate the recording and subsequently sell or trade those tapes with others. Their application of the technology was clearly an issue of fair use under the copyright laws.
Music sharing software has been marketed for a number of years with the clear understanding that the user will gain access to a large number of songs that they may download for free. Making a copy of your music, as a backup copy, or as a means of enabling you to listen to it on other devices you own is a fair use. Providing copies of the music to numerous others people, who do not own legal copies of a work, is clearly a different matter. It goes against both the letter of the law, and the underlying intent of copyright law.
The white-paper and the web pages on the company site which describe the implementation talk about how this is done.
This card, and the software which drives it, differ from traditional ethernet accellerator cards and from alternative network protocols (like myrinet and iWarp) in several ways.
Alternative protocols not only require using a different software API but also require custom hardware at both communication endpoints.
Traditional hardware TCP/IP accelerators run the bottom half of the stack in custom silicon. This does tend to help reduce host CPU load but suffer from a number of problems. Since host CPU speeds have tended to increase regularly, they often helped for only a brief period of time. They also tended to help most for large packets but helped little or not at all for small packets.
This technology claims to help large and small packets equally well, and also claims to reduce packet latency across the board. It does so by running the bulk of the TCP/IP stack in user space rather than via system calls. The hardware runs ethernet Rx and Tx processing but does not implement the higher level IP protocol processing. Instead, once connections are established, the ethernet frames coming from the hardware, are fed via a system call interface to the application process to which they belong. Then, no further context switching between kernel and the process are required. The top end of the hardware driver and all of the subsequent IP layers, are executed in the context of the user space process. They are linked to the app via shared libraries.
Basically, instead of the linking the IP calls against code which requires frequent switching between user and kernel space, the entire upper half of the stack is run by the application sending and receiving the packets. This offers uniform benefits in packet latency across all packet sizes, and offers improvement in throughput as well.
I assume that all that is required is to link against a different set of shared libraries to gain these benefits (and of course to have the custom hardware on at least one side of the comm. link). This looks very good in principle.
The following page provides an overview of the technology and compares it to each of the competing mechanisms.
http://www.level5networks.com/sol_approaches.htm
Anyone (like me) who has used Pages, Apple's Layout/WP application, will gladly match that bet. Care to make it a bit bigger? I'm game.
The thought that apple would base a future word processing app on either Open Office or Koffice, is not very plausible.
It would help if Apple were very very clear on why this option was chosen and what they intend to do.
Jobs was very clear about that in the keynote speech.
By 2006 and beyond, Intel chips will have much better Performance/Watt ratios than PowerPC.
That seems pretty clear to me.
What does that mean?
The Power architecture does have a number of strengths. However, the roadmap for future improvements to the PowerPC line will lag significantly behind future chips from Intel in that regard.
Cooling, noise, and the increasing prevalence of portable computers make Intel more favorable in the long run for the types of products that Apple wants to build.
G5 laptops were too hungry and dissipated too much heat to put in a laptop. 'Nuff said.
I'm sure, that some people might find it useful.
However, it's not likely to affect many people. I, and most people that I know, use macs because the software (both OS and Apps) are so pleasant and reliable to use.
The thought of being able to run really crappy software again doesn't float many boats.
They've been building everything on PowerPC and Intel at the same time for five years.
How is that surprising.
The bulk of the OS is the direct descendant of NeXTStep.
The base development tools have compiler flags to select processor family and subtype. They can compile natively, cross compile for another type, or do both simultaneously to create a fat binary (now called a Universal Binary).
The initial apple developer releases (pre 2000) all shipped for both intel and PPC.
The base OS, Darwin, has always been supplied for both architectures.
All of the code used for reading and writing objects and data files, or communicating via remote objects has always been endian neutral.
None of this ever changed.
Wow, would be a natural response only if they had deliberately abandoned that testing/support internally.
They're all things that were imported from FreeBSD and given a GUI.
Incorrect. Some are things which derived from the Mach BSD roots on which NeXTStep -> OPENSTEP rested.
For instance mach ports are used to provide another layer of privilege separation which are a superset of the unix world. This one is equivalent to a capability model and is based on mach ports.
One way this is used is to provide a means to define separate domains of privilege for tasks which are spawned at boot time or via other daemons, those which relate to remote logins, and those which are related to the window manager or login domain.
It is fundamentally impossible for a task in one domain to forge or acquire the mach port of another domain.
FreeBSD was used as a base for updating Unix components from 4.3 BSD to 4.4 BSD.
On the PC, I have to troubleshoot all the time...I don't look at it as time unproductive, I look at it as time educating myself for when it happens to the next person at work, or friends, or next door neighbors.
Macs? I'll see a problem and it is a waste of my time...I'll never find anyone with that exact problem again and its 3 hours wasted.
What a narrow, misguided viewpoint.
1. You have to solve problems all the time.
2. Your co-workers, friends and neighbors have problems frequently.
You consider solving rare and infrequent problems a waste of time, and yet don't consider the problems you claim to solve frequently to be a waste of time. Rare and infrequent problems rarely and frequently are encountered by either you or by others, thus represent time which you and they can use at their discretion. In comparison this seems like the opposite of "wasted time"
It is sad that you and others are forced to devote so much of your time to problems. It is misguided, because you rationalize the real time wasted and fail to see real underlying situation.
I grant that you may prove helpful to others by helping them solve similar problems in the future. This is beneficial to you by improving other's sense of your worth. You gain both social and psychological benefit from this. You benefit indirectly from the misfortune of others and justify your own (inherently unproductive) effort by marginally reducing the perceived cost of other people's problems. Actually, both you and your cohorts are collectively wasting a great deal of time. This is OK with you, because you get some other benefits from it. I don't denigrate you for this, it is a natural and basic part of being human. Just don't delude yourself. You don't consider it a waste of time for you because it is paid for by a larger volume of other people's wasted time.
This is not a zero sum game. Each of you collectively are taxed with a huge burden in wasted time, effort, and enjoyment. Use whatever hardware and software you wish, I honestly don't care. However, at least be honest. Both you and they are wasting a great deal of time compared to equivalent groups of Mac users.
The risk-reward ratio is way too low on this one. Basically, they're asking for a technological innovation on par with the light bulb
This is not grand innovation by any interpretation. This challenge, like the others, is about incrementally extending the state of the art. It is about practical, innovative application of technology, not about science.
Basically, the moon contains a great deal of oxygen, but the vast majority of it is found in molecules which bind the oxygen tightly. Some metallic oxides like iron oxide are fairly easy to crack. On the surface of the earth, iron oxide is abundant. On the moon, however, the most common oxides are of silicon, aluminum, calcium and titanium. These elements are bound very tightly to their oxygen, and require either great deals of energy and/or powerful chemical reagents (reducing agents) to liberate.
This explains why these elements were not isolated in pure form by chemists until the the first quarter of the 19th century, and in the case of aluminum, why it was far more valuable than gold until the dam at niagara falls produced sufficient cheap power to make production worth while.
Using Hydrogen as the reducing agent liberates some oxygen cheaply but leaves a great deal behind, but is easier to work with. More powerful agents such as fluorine, or sodium hydroxide are far more effective at reducing these oxides into oxygen and metal. However they are extremely corrosive and pose some tricky engineering challenges.
For instance, sodium hydroxide is great but requires the use of nickel electrode which are consumed by the reaction. Nickel is very rare on the lunar surface.
Chlorine, and even carbon based reactions are possible.
So the challenge is to explore the various engineering trade-offs. Weight, energy input, size, speed, and the amount of raw materials brought from earth and consumed by the process all need to be balanced.
$250 grand is surely a decent incentive for chemists and engineers to tinker with various designs.
Wow, what a horrific environmental tragedy!
By strip mining the surface of the moon we might end up with large areas of the surface which are barren expanses of rock and dust, devoid of soil or life...
Oh, never mind.
You have provided some good information, but it is incomplete. You probably are doing the right things to analyze this problem but in the absense of explicit statements I have no information on which to determine that.
It is imperative to determine whether the executable is being called, to determine that launchd is listening, and that you are connecting the the right port. Your xinetd configuration specified that the pop server was not using ssl and was listening on port 110 only. Your launchd configuration is listening on port 995 but not on 110. Since you did not specify what program or what port you were using to test the localhost connection, I cannot determine if the fault is with launchd or some other configuration problem.
1. I suggest you use telnet to determine if if you can connect to port 995. You can also use netstat -a and lsof to verify that launchd is or is not listening to the port. If it is listening, verify that your mail programs are attempting to connect via the SSL port not the vanilla imap port (110).
2. Use log files to verify that neither launchd nor pop3 are throwing errors.
Good luck with it.
You claim that the plist file you created is working fine.
If that is the case, the first thing to check is the firewall. In Preferences.app check the firewall settings and verify that ports used by ipop are open. Open both 110 (pop3) and 995 (pop3s which is SSL/TLS protected).
If you have difficulty connecting after verifying the firewall permissions, I suggest you try connecting to localhost to test the server. If localhost connections are not working, go back to the plist file until you can connect locally.
No it was not a "copy-and-paste" job. I wrote it while reading the source code and documentation for the launchd module. It is open source after all.
/System/Library. On my Tiger partition there are 17. Launchd replaces SystemStarter for the majority of both system and third party uses. It does not replace it entirely yet. With the absence of dependency ordering, I do not see how it could replace the rest.
The parent to my post, and the grandparent as well, had commented on the parallelism and boot speed of the Macos X boot process. Those comments suggested to me that they were posting based on familiarity with SystemStarter, and confusion about launchd. Even the Subject seemed to indicate this confusion. Not a cron relacement, a init replacement is false. Yes, it is partly an init replacement, but also a cron replacement, xinetd replacement, and several other things which have no direct counterpart in other unices - such as a means of writing ad hoc queue processing scripts.
launchd is about generalizing process launching regardless of whether a process is run based on a temporal trigger or request for service. SystemStarter provides relative ordering of scripts based on a graph of Requires/Provides definitions. I realize that SystemStarter is deprecated for most tasks for which it was historically used. However, the need for both SystemStarter and launchd seems clear.
I see no means within the launchd subsystem of cleanly specifying dependancies among different daemon plists (or groups of them). For this SystemStarter still seems appropriate. Launchd will of course be the preferred choice for most tasks, not least because it encourages a pattern of lazy evaluation for most system services and obviates the need for scores of daemons to poll or sleep until they have work to do.
Without requires/provides, however, launchd cannot do everything. Until it does, SystemStarter (also distributed in the launchd-106 tar ball) is still needed. On my primary Panther install there are 33 StartupItems in
However, the question is are we losing simplicity for features?
Good question.
Let's look at it. When are programs run? The simplest answer is "when they need to."
No, I'm not being snide, merely rhetorical. When do programs need to run?
Programs need to run for a variety of reasons. Some need to to run when the machine is booted. Others need to run at particular times. Some, like certain network server processes are needed only when a user or another program requests service (e.g. accept connections on protocol/port). Others are spool oriented programs where files in a queue directory need to be processed when present but have no work to do when the queue is empty.
So rc scripts run programs at boot time which either do some work and die or act as standalone servers which are intended to live forever (or until they are explicitly told to stop).
init runs programs (like getty processes) which are long lived and are respawned when they die.
inetd/xinetd listens for connection attempts to network ports and spawns server processes on ports.
cron runs programs based on a schedule, the passage across a point in time triggers execution.
launchd provides a superset of the above triggers for spawning programs.
Think of it as
Run Program [ProgramArgs] [ TemporalTrigger | ServiceRequiredTrigger ]
By default, the simplest launchd file says "Run this program now just once.". It is thus a simple rc script which, at boot time, runs something and at shutdown time can be told to stop. Adding a further key/value pair can say "restart on exit," thus replacing inittab/init based functionality. Specifying a family/protocol/port says listen and start me when needed to serve a network request al a inet. Adding a qualifier to this type of socket definition says connect() to an address, instead of the more typical bind()/listen()/accept(). Specifying time based activation covers cron functionality, if you need at functionality specify the environment variable and working directory as well. To enable spool-like behavior or programs tied to arbitrary file system activity watch a file or directory for changes.
Most Unix subsytems only support system level operation. launchd distinguishes whether a process description is system wide or based on user login simply by where the file is found. A launchd plist file found in a LaunchDaemons directory will be loaded on system startup. One found in a LaunchAgents directory will load when a user logs in, and unload on logout. The syntax of the file will be identical in either case.
So, the launchd plist files (short for property lists) contain a set of key/value pairs describing what to run, and when to run it. Beyond this, launchd defines keys which tailor how the program is run, all of which are optional. These include specifying: user and group by either name or uig/gid; working directory, chroot directory, a dictionary of environment variables, CPU niceness, umask. Do you want to limit how much memory or stack it uses, prevent it from wiring system memory? Do you want limit the number of children it can spawn, or treat its IO requests as low priority as urgent? Keys are available for that.
So is this simpler or more complex? In the big picture I believe that this simplifies things tremendously. Launchd defines a tiny language for specifying how and when to run processes. It covers all the traditional triggers of init, rc files, cron, and inetd. It specifies the environmental and security issues of su/sudo, chroot, ulimit, umask, nice and at. It covers both system level startup/shutdown as well as user level login/logout.
Because of well chosen defaults, most launchd input files will be very short and to the point, only specifying the direct functionality they need. Adding just a few more key/value pairs can obviate the need for the majority of moderately complex rc and daemon startup files. Since launchd also obviates the need to daemonize, close files descriptors, fo
The launchd source code is a collection of programs which span several related areas. In the broadest terms the contents of the distribution cover init, SystemStarter, and launchd.
Most people talking about launchd in the context of parallel system startup are actually talking about SystemStarter. Also note that the plist files which drive SystemStarter can be in one of two forms. The most common of these is the NeXT style textual plist format which is very human friendly and is not XML-like in structure or appearance.
As a replacement for aither BSD style or System 5 style rc scripts, SystemStarter is a definite improvement, both in terms of ease of use, speed, and reliability. The launchd subsystem uses XML formatted property lists. I am unsure whether NeXT style plists are supported for these.
Regardless, you were dismissive of launchd claiming that it was mere init replacement. You thought you were speaking about launchd but sound like you had only heard about SystemStarter.
launchd itself it a super-server which reads process definitions. These definitions can describe processes to be run using a set of predefined keys. Some examples of key value pairs are: Program/ (path to executable), or ProgramArguments/ (The array of strings to pass as arguments to the program). The interesting thing about launchd is that the predefined key/value space is so rich, and so well considered.
The keys span several related domains which Unix users associate with a number of different tools and data sources. Here are a list of some interesting areas covered.
like sudo or vixie cron the user and group under which to launch the program can be specified using any of { UserName, UID, GroupName, GID }
WorkingDirectory causes a chdir(2) before executing the job.
RootDirectory specieis a chroot(2) for the child process.
StdOutPath and StdErrPath can specify where to redirect output of the program.
OnDemand specifies whether to run only as needed or ensure that a server process should always be available, thus respawned.
Labels and Groups provide a way to refer to processes with greater specificity or to group related processes together for reporting or action using launchctl.
A set of time specific keywords cover a superset of at and cron time specification.
Soft and hard resource limits for the job can be tuned using keys that provide acces to all ulimit functionality (file descriptor file size, memory footprint, core size, etc.. Similarly the nice value can be specified to constrain CPU usage, and the *PriorityIO keys specify what priority the kernel should use for scheduling disk IO for this task.
The Socket Key defines an optional dictionary defining IPC behaviors controlling combinations of open/bind/connect/listen. (think inetd and xinetd). Beyond this you can also specify other things here like "Bonjour" to register this service with mDNSResponder. If a SockPathName is specified attempts to open a named unix domain socket will cause this program to launch.
If these are not enough, a launchd plist can start/stop a program when a watched file changes. When passed the path to a directory, the program can be started when the program is not running and the directory is not empty. Think about this one... A robust queue processing program might be simply:
#!/bin/sh
lockfile $SOMELOCKFILE
for file in *
do
process "$file"
done
WorkingDirectory and a watched directory path, along with whatever CPU/Disk IO/Memory/user/group are all handled by launchd. Similarly launchd ensures that the process runs when there is work to do, and is never launched unless there is work to do.
Finally, if the predefined keys and actions are insufficient you can call a small number of stubs implemented in Tcl to set either one shot timers or interval timers at which point the scripts is re-interpreted. You can pass messages to syslogd, start or stop jobs. A form of system introspection is also pr
I am interested in the metadata aspects also, but my view on where it is going differs from yours. You state that: this is just crying out for a BeOS style arbitrary metadata creation/editing application. I like the functionality that has been added, but do not wish a return to the older MacOS uses of metadata or a BeFS-like set of functionality.
Those nostalgic for BeFS might wish to see more low level use of metadata in ways that integrate it tightly into the underlying file system. In BeFS the underlying disk format was a Btree varant that supported arbitrary key value pairs on each node. Each key was indexed subsequent to being added, thus each new type of metadata became a first class citizen with the standard metadata predefined by the file system.
The Old-school Macintosh metadata camp liked the resource fork, which enabled developers to define additional data to be associated with file contents using key/value pairs. In this case the keys were not arbitrary like in BeOS, but limited to 4byte quantities (or in the case of Creator/Type codes pairs of 4 bytes keys). When HFS became HFS+ the underlying storage system was extended so that data/resource forks were suplemented by an arbitrary number of additional named resource forks. MacOS 9 and earilier versions of MacOS X never made use of this.
What I disliked about these earlier implementations of metadata was that they isolated MacOS and BeOS users from other systems. Copying a file from system to system either lost the metadata or resource information or made the information less accessible to users of other systems. Additionally, the native code to make use of this functionality was part of the Be C++ libraries or, on the Mac, part of what is now Carbon. Thus, even in MacOS X, using such functionality required linking to additional libraries which were pretty much guaranteed not to exist anywhere else. Writing otherwise portable Unix code, or Cocoa code (which could theoretically run on GnuStep) still required Carbon calls to make use of the old style metadata.
This strikes me as bad news. Similarly, writing low level BeFS-like functionality on top of this seems equally ill-conceived.
This implementation of metadata appears fundamentally different. The underlying storage mechanism leverages the named resource fork functionality of HFS+ (which is local to the MacOS X space). Despite this, the software mechanism for storing and querying this information is based on the POSIX extended attributes model. This means that programs which want to use new metadata on MacOS X can be ported to systems that implement the POSIX(1e) attribute model. It resides in the BSD space, not in the Cocoa, Carbon, or even HFS specific space. This is the right way to do it.
The primary goal for using this approach was probably not to increase the use of metada at all, but to add support for Access Control Lists (ACLs). Both Linux and FreeBSD have implemented ACLs based on the storage of ACL information in the form of posix extended attributes. This leveraged the fine wok done by Watson et al for the BSD world in security, it made the most sense to implement posix style extended attributes in MacOS X. Viola, nearly for free, by exposing this underlying storage to the command line, we now have an arbitrary resource subsystem where Unicode string keys can hold arbitrary values for filesystem objects.
The long term ramifications of this are that NFSv4 implementations which support the optional metadata extensions will interoperate well. BSD* and MacOS X based clients and servers will have complementary access to both ACL information and other metadata. Likewise Samba ACLs will interoperate between Mac and Windows networks. If you write an executable to store and retrieve this information it should be portable to FreeBSD, LInux, or any commercial Unix which implements the Posix extended attributes in a clean way. The storage for this metadata may be part of the native file system (as it is in HFS+), but need not be.
I hope you aren't holding your breath.
Why? Are you suggesting that Longhorn will not stink?