Thus new apps (Omniweb, Mail.app, etc.) have many reasons to go Cocoa, but legacy apps (Adobe, MS, etc.) have little reason.
I do not quibble with your basic premise that large vendors with a legacy Mac code base have been slow to migrate to Cocoa. Vendors of legacy apps (especially those with a large installed code base) have a number of reasons to move slowly.
However, I find it odd that you mention Mail.app and Omniweb as "new apps".
OmniWeb has been my primary browser since early 1995. Mail.app has been my sole email interface since 1990. That's 10 years, and 15 years respectively. They may seem "new" to legacy Macintosh users, but are decidedly not new.
I apologize if I put words in your mouth on several topics.
I assumed you were misinformed about those issue because of your continued insistence that the technology is file system specific, and that kernel notifications offer potential improvement.
You assert that notifications need only be sent when mtime changes, not for each file system write. This does not make sense. When a block write operation is performed in the vnode layer, it is passed to a filesystem specific write function. This, in turn updates the mtime. Thus, triggering notifications at the vnode layer for mtime updates would have to be performed for each block write. An attempt to optimize this, and pass along notifications less frequently would only be possible by pushing the notification down into each file system.
Second. You continue to state that this is a file system specific mechanism. It is not. Such a daemon can use fts(3) on non-hfs filesystems, and a faster hfs specific function on hfs+ volumes. It will be faster for the native filesystem. However, there is nothing preventing it from working on nfs, ufs, samba, or other volumes. In a very weak sense you may interpret this to be file system specific. However, you appeared to be claiming that it will only work at all on hfs volumes. This is not correct.
Thus, to finally close this, it is not file system specific in the first place, and is already more efficient than kernel notifications. In neither case do kqueues make any sense here.
Select a file. c to copy a reference to the clipboard. Select a directory. -v to paste the file.
How is that difficult?
Moving a file, is one of two things. Renaming, which is followed by the new name. Changing the parent folder of the file. In this latter case there is no key board equivalent (of cut), there is only drag and drop.
1. It is being done in user space, as a daemon, already. 2. It is not being done in HFS+ (beneath the vnode layer). 3. The meta data being discussed is not icon, label, or hfs fork metadata. 4. The meta data includes such things as dimensions and bit depth of graphic files, duration of song or movie files, and any other data which application files contain and which developers wish to provide interfaces for. 5. Changes to file contents will generally require triggering an update to meta-data indexing. 6. Thus, tying this into the vnode layer is a very bad idea. Block writes would have to trigger a notification.
Apple did not implement it in hfs+ or in other file systems beneath the vnode layer.
Apple did not, and should not have, implemented it at the vnode layer.
Instead, they wrote a daemon, which can check new and modified files, determine whether any changes are to be indexed or ignored, and call the approprate handler to gather the meta data to be indexed.
HFS+ will be more efficient than ufs or nfs for this. This is due to the fact that HFS+ supports btree based searches for filesystem metadata (i.e. find files of type T whose mtime > M) without requiring a full traversal of the file system. However, nothing precludes one from indexing meta data on other types of file systems.
You say you want to place a hook in the vnode layer. This hook would need to initiate a notification via kqueue. In the context of this discussion, the extra logic for this would need to be performed conditionally for all block write activity.
Even though kqueue, per se, is an efficient communication mechanism, your attempt to employ it for this purpose would impose additional overhead on all file system activity.
Thus, calling this 'efficient' is hardly a reasonable proposition whether or not the recipient is in userland.
Placing it that low would have an impact on filesystem speed for other more general use. I don't want each open, or each block written to cause more time to be spent in the kernel. Even if that call were handled by another thread it would have an adverse impact on throughput.
Doing it in userland makes much more sense. System call overhead is lower. You may choose to nice the daemon or choose not to run it. Don't muck with the kernel for application layer functionality.
Design is more than functionality. Design is more than features. It's not about interface, per se. It's not even (as so many claim) that it's about style in the sense of fashion.
It's the whole shooting match.
People who don't grok Apple, don't seem to get that.
I had a can opener. A manual can opener, that I got for about 5 bucks in the early eighties. A maid accidentally threw it out several years ago. Only when it was gone, did I realize how wonderful it was. I searched off-and-on for months trying to find a suitable replacement. I bought 5 can-openers finding each to be annoying to use.
I finally bought one that was about half as good from a mail order place in Great Britain (I live in the US). Nobody in the world makes a can opener like what I used to own. It was the right weight, and had a perfect gearing. It gripped the lid, and neatly dropped it in the trash. The balance, texure, and feel were simply superb. If I were an architect or other design geek, I would have realized how good it was long ago. As it was, only by comparison with alternatives did I realize how nice it was.
The iPod, and other great designs from Apple, exhibit this kind of property.
If you look at a checklist of features, look at particular aspects of functionality, price, or other attributes in isolation, they do not appear special. Through feel, and through use, they just seem right. As a whole, they simply strike many people as right.
You're right, gold-plated, mpeg enabled, or cheaper, a true iPod killer would have to have the "whole package".
What's tricky, is that this requires attention to the details of the design which most people are never actually aware. It will take a great deal to "kill" the iPod.
Re:Before the Stanford machine crashed...
on
Internet Turns 35 Today
·
· Score: 2, Insightful
Apparently BSD has been dying for much longer than people realize.
Since I've been using FreeBSD, NeXT, and MacOS X, exclusively for the past 15 years this news gives me pause for thought. Each OS has been reliable, fast, low-maintenance and enjoyable. Because of this I was not terribly concerned by the sad news that BSD was dying. Honestly, it always seemed pretty healthy to me.
Hearing that this fatal condition has persisted for much longer than I had known about, perhaps I should finally heed the warnings of its demise.
If I decide to switch to another OS are there lingering health problems I should worry about?
I hear that Windows has long suffered from epilepsy, incontinence, narcolepsy. It also has a severely compromised immune system which leaves it prone to opportunistic infections.
Linux on the other hand, appears to suffer from schizophrenia.
They add both NaCl (regular table salt) and other salts. They do so for flavor.
In Great Britain a while back they also added bromine for flavor, and treated it by bubbling ozone through it. Just as water with larger dissolved O2 in it tastes fresher, ozone imparts a similar flavor.
The problem is that bromine (which is harmless at moderate levels) become bromate when it reacts with ozone.
Bromate is a stong carcinogen.
Basically Coca-Cola, was pumping water from the Thames, filtering it, and adding carcinogens for flavor!
Dasani was recalled temporarily.
Teach the world to sing my ass!
In the USA the bottled water phenomenon saddens me. On average the quality, purity, and safety of tap water is higher than most bottled water. How did people get conned into spending more for water in many cases than for milk or gasoline? Are they really that F'ing stupid?
They sucked only slightly re the technology. It's more that they underestimated their competitors.
When they announced the initiative most digital display technologies were only capable of natively displaying at 720p. This is simply because the native resolution was typically 768 or 770 vertical rows of pixels. They can display 1080 images, but of course the conversion loses detail in the image.
The hdtv standard also has a format with 1080 vertical lines. 1080i (1080 lines interlaced) is a common broadcast standard. The top end (1080p) is the highest resolution in the standard. This year high end plasma displays are now shipping that can natively display 1080 lines (Sharp is one).
The rival rear projection technology for LCOS is DLP. DLP chip-sets have typically had a native resolution of 1280 x 768. TI started shipping a higher end version (the xHD3 chipset) that is capable of 1080p native resolution.
From Intel's standpoint:
1. They started planning an LCOS rollout at 720p native resolution. 2. Their competitors got to significant volumes of 1080p faster (and at lower price points) than they initially assumed. 3. They began redesigning to ship 1080p at rollout. 4. They had problems rolling out smaller line sizes in all of their fabs (IBM and others had similar difficulties). Their LCOS proved more difficult than they thought.
Poof. Longer time to recover investment now makes it less desirable.
I'm glad you brought that up. I've been so long out of a well supported branch that I forgot about Software Update entirely. I agree with your assessment. Those who are on well populated branches of the code tree are best served by FreeBSD Update for security. Since security is a moving target, running on a STABLE branch and keeping up to date is the best way to ensure both stability and security. You correctly pointed out that if security were my primary concern, I should have been doing that.
My requirements several years ago made deploying a 5.0 snapshot release very worthwhile. The combination of functionality I desired was too compelling, and likely not to be added to 4.x for some time. Thus, I have balanced functionality, stability, and security by making certain trade offs. Obviously, a breach in security affecting the main cvs tree or cvsup could prove catastrophic.
However, once I decided to live in a relatively unsupported part of the code tree, it has served me well. Since I have a local mirror of the cvs repository, periodically checking out the sources and building via cron is very efficient and requires no labor whatsoever. Many security updates require me to simply ensure that my latest compile went smoothly, cd to an appropriate subdirectory, and run a script to perform a make install to the main system image and once for each jail DESTROOT, then restart service or the system as required.
If such a largely automated ability to upgrade the system or a subsystem was not present, I would have been foolhardy to run a production server so far from a well supported release. In retrospect I am extremely happy to have run so stably and so securely for the past 3 years. I have not had any crashes or unplanned outages during that time (except for a drive failure). I have also to my knowledge (there's always a possibility!) had no security breaches either to the host or to any of its jails.
In my opinion the true measure of security and stability is measured over time, not by a particular point in time. Security is a constantly moving target. If you remain still, you may eventually become vulnerable, or discover that you always were vulnerable, and just did not know it yet. The true beauty of FreeBSD, is that on a stable branch, it is possible with little effort and negligible risk to update your system frequently. Moving gracefully, in small steps as security, stability, and functionality improvements become available.
For a variety of reasons, I have chosen a much less traveled path. My trajectory has not been as graceful. However, my stability, and reasonably high level of security, has been maintained with very little extra effort. This is a testament to the rigor, and high quality of the FreeBSD security and release engineering processes.
I do look forward to rejoining the STABLE fold, soon after 5.3 is released. It will give me more options for rapid response to security, and make more frequent minor upgrades a viable approach again.
It depends on how you measure quick, and on your risk tolerance.
If by quick you mean the least time start to finish, yes. If you mean as measured in system downtime, no. Each has a different risk profile which depends heavily on how much additional software you have installed.
I too have been running 5.x as a server environment since mid 5.0 days. I have performed 2 source based upgrades in the interim to bring me to 5.2. My preference for source based upgrades is based partly on my desire for quick response time re: security. It is also conditioned by my rather complex setup in which I have multiple jailed environments each running a large number of packages. A binary upgrade is less attractive since I would need to install dozens of different ports and possibly face conflicts or temporarily broken ports.
You have very few ports running, and from your statement they are pretty stock configurations. From this standpoint a binary upgrade should be relative painless. However, it might require more downtime.
If I were you and were running a GENERIC kernel, and was running a late 5.1, or 5.2_RELEASE, I would suggest a source base approach. if you are running an earlier 5.x version I would still do so myself but would counsel you to assess your comfort and knowledge with compiling the code and following/usr/src/UPDATING to the letter. If you are unsure, opt for a binary install.
If you do use a source base approach, I would prepare by installing the cvsup tools from the ports tree to mirror the source code and the ports tree. Then you can compile using buildworld and buildkernel, and even compile and install ports (using and alternate paths for the package db and destroot) to test versions of installed ports which might be newer.
Read UPDATING thoroughly and study any differences which you are unsure of. Then when you are ready, use install* targets and mergemaster to finish.
This is initially a longer, more time consuming approach, you must install sources, and configure cvsup to keep them up to date. Once that is done, however, they are always up to date. At each site which I have maintained FreeBSD, I use cvsup to mirror ports and sources on a single box. In fact, I mirror the cvs trees, enabling each host in the network to choose what particular version to check out. I then check out source trees via cvsup, and run a buildworld and a buildkernel via cron either weekly or monthly.
Thus, I always have a recent binary distribution ready to install when I feel like it. I upgrade rarely, but when I do, I typically have a 10-20 minute downtime. On boxes where I have configured multiple drives with sets of boot, usr, and var partitions, I configure and install to the alternate drive using the DESTROOT variable, and can take care of merging changes while running on the old version. Then downtime, is boot time + time to select the new boot partition.
The court system (both federal, and most states) does not agree with you.
You are correct that until rather recently most statutes concerning theft did correspond to older dictionary definitions requiring that a physical object be missing of that an object be moved from its rightful place.
However in 20th century statutes using the word "theft" began appearing which no longer rely on that old definition.
Statutes for theft of service, involving electrical power define unpaid use of electricity as theft. You have not stolen electrons, merely some of the motive power they convey. Legally however this is a from of theft. Later, theft of service in other forms was legislated. Tapping into a cable TV feed, receiving and decrypting real time stock ticker information broadcast over radio, are all considered theft by both federal and state laws.
In the latter form, you have deprived no-one of use of their property. You have however, attempted to derive personal benefit from something for which you have not paid.
On legal grounds your definition of theft appears unsound.
I see many problems with intellectual property and patent laws which no longer serve the public. Their intent was to provide a short time limited monopoly which was to spur innovation, and then devolve to the public domain and benefit everyone. In my opinion the grant of limited monopoly is no longer limited, and the benefit to the public vastly reduced. However that is a matter of politics, not of pragmatics or ethics.
I agree with your opinion that copying aught to be somehow different. However, ethically and pragmatically it still feels like theft. Legally, it also looks like theft.
Admitting that it is an illegal act, but insisting it is not theft is mere hair splitting.
Downloading a stolen copy of the OS is just plain wrong.
Apple paid 400 million dollars to buy NeXT. They then spent years of development effort integrating their older MacOS technologies to ensure backward compatibility. They released the resulting core OS for free use (in source code no less). They base a number of their core utility software on OpenSource products, and contribute much source code back to the community.
If you are running a BSD Unix, or running Linix, chances are you are already benefiting from Apple contributions to open source projects on a daily basis.
Ooh, you say, now we can pirate their GUI development utilities and application software! Grow up!
Why would you benefit from doing so? Because the software is worth using, will save you time, and will be enjoyable. If you benefit from a product or service, show some respect for those people responsible for providing it.
If you are not willing to pay anything, then use what is given for free. They respect and contribute to both GNU and BSD based projects.
If you are not willing to buy a new machine, then look on eBay, or online retailers who specialize in repairing and reselling older Mac hardware.
Yes, the software is damn good. No, they currently do not sell it on Intel hardware (either native or emulated).
Whether you or I like that or not, is beside the point. Using tools which improve your productivity or quality of life is worth something to you. If it is worthwhile, put up or shut up. In the open source world, contribute money or time to help improve it. In the commercial world, buy the product, and help fund further improvements.
In american primary schools we are taught the following mnemonic device for spelling.
"'I' before 'E' except after 'C' or when sounding like 'A' as in neighbor and weigh."
In american English the most common words we encounter that contain 'ie' or 'ei' are pronounced with long 'A' or long 'I' sounds not long 'E'.
Upon encountering 'ie' we thus assume a long 'I' sound as in 'bribe'. When trying to spell a proper name of european origin that sounds like 'ortleeb' we thus reject 'ie' and are drawn to the 'ei'.
When shooting for the long 'E' sound, the vowel ordering 'ie' just does not look right. Our assumptions about standard pronunciation makes the spelling 'ortlieb' appear incorrect since common words like 'lie' have a long 'I' sound.
You are correct. It's not a mix and match environment. Current X-prize competitors are focusing on a wide range of different engines, fuels, and components. Even if they were all working on traditional LOX + kerosene or LOX + hydrogen, many components are complex enough to demand significant effort to re-use in other designs.
People like XCOR, working on far less expensive, more traditional designs, can significantly advance the state of the art.
Its too early to tell what will happen.
However, before X-prize was announced in the late 90s, nobody in the world was working on manned space beyond crew return vehicles. Having manned space flight back on the table is wonderful.
Getting the big players out of the loop also helps. Military, Big Science, and government interests don't have a vested interest in manned space per se. (Manned space flight is there only as an adjunct to other goals.)
Although this might cause NASA budgets to be re-architected to funnel more R&D money to material science, I believe that the opposite might occur. Perhaps, NASA will reduce those budgets and start awarding contracts to some of these startups.
Neither NASA nor any of the big aerospace firms would have gotten approval for the kind of rapid development that Scaled Composites and many others, have managed. Think about it, Rutans SS1/SS2, has had only 6 powered flights. 3 of them were to space! Though further testing and analysis would be required for integrating components into more massive designs, the R&D budget of ~$30 million, would barely make prototype stage (let alone off the ground) in more traditional big aerospace organizations.
"Newer supported devices" is uselessly vague, as you are aware. Adding the words "wireless one" is more detailed, but not as you state, "more precise".
Wireless could still mean almost anything. IRDA, 802.11*, bluetooth, heck you might be talking about anything from a mouse or a keyboard to an interface to an amateur packet radio band (via short wave). As a result, though I would like to provide an answer, I cannot. I can only make it easier for you to find it on your own.
FreeBSD supports a wide range of devices. Note however that FreeBSD strive for quality over quantity, and that your particular hardware may not be well supported yet, if supported at all. You should look at the hardware support page for the release you want to run. (version and host architecture)
It list all the hardware specific release notes for the i386 architecture, including motherboard, processors, and devices.
The device page covering everything from mice to raid controllers is: http://www.freebsd.org/relnotes/5-STABLE/hard ware/ i386/support.html
Does it support strange and obscure devices? Yes. Does it support your strange and obscure device? I don't know, take a look and see. Good luck, I hope you give it a try. It's a very nice environment.
You claim that this is not a stepping stone toward any useful goal, that's it's "just advertising and a joy ride". Nothing less than cheap access to orbit is worthy of interest.
I agree with you that short, sub-orbital flight is only directly good for joy rides, and advertising. Beyond this however I disagree with you entirely. No offense, but I think you're missing the point.
Why? Because advertising and joy rides are the key to unlocking a revenue stream which can move us toward more useful goals.
Currently the only significant source of direct income from the private sector comes from launching satellites. This is a large source of revenue, but one which is neither very elastic, nor one which places demands on those who provide lift to significantly change the status quo. The cost of launching most satellites is but a fraction of the total cost. Adding together insurance, interest payments and other opportunity costs for capital, they are extraordinarily expensive objects even if launch costs are ignored. The market is narrow and capital intensive.
The result is that the market puts little pressure on firms to lift significantly larger payloads, either measured in volume or in mass. Incrementally reducing cost per pound on existing orbital launch systems would not be likely to increase the demand significantly. The risk of modifying these systems incrementally is simply not justified by the risk or the return on near term capital investment. Worst, no private income stream currently encourages development of manned missions at all.
The X-prize cup goal is provide direct incentive for innovation in manned space transport. It does so by providing a mechanism for directly infusing private capital into manned vehicles in ways that are much more flexible, much more elastic, and which result in pressure on potential space transportation designers to increase both aggregate and per launch lift capacity. The first prize was designed to promote competition in developing an inexpensive re-usable sub-orbital vehicle for carrying passengers. This will generate income in 2 ways. Advertisers will pay to be associated with the product and services provided by commercial users. Passengers able to afford a the ride will provide a significant on-going stream of revenue.
The passenger revenue is highly elastic. at the price of $200K per head, about 6,000 have already expressed serious interest in riding Virgin Galactic. 1.2 billion is nothing to sneeze at. If the price were $100K, that number would rise rapidly. As the price continues to lower, more and more passengers will be able and willing to afford even a sub-orbital jaunt. I'm not wealthy, but I would certainly drive crappy used cars for 5-10 years in return for a trip to space.
The X-prize cup is an annual event, Competitors will vie each year to travel greater distances downrange, achieve higher altitude, launch the most times during the event, carry the largest payloads, etc. The organizers expect that an X-prize competitor will achieve orbital capability in 5-8 years. That apparently would interest you.
In the past 30 years we've gone backwards not forwards. Aside from X-prize vehicles (both Scaled Composites and the 20 or so other contenders), the only manned space vehicles we have are based on designs form the 1960s and 1970s. Huge lift capacity died with apollo.
Without advertising and joy rides to both fund that development and promote competition, how do you propose we get there?
Although I was speaking mostly about ballistic, rather than orbital flight plans, altitude per se does benefit orbital trajectories as well.
You are correct in pointing out that velocity at apogee (tangential to a line drawn to the earths center) is the critical factor in acheiving orbit. Thus in an orbital flight plan, an eax 50,000 feet or so is not directly helpful. However, it is helpful indirectly.
Rocket motors are less efficient at higher pressure. A conventional bell shaped nozzle is more than 9% more efficient about about 15,000 than is is at sea level. Thus using an air breathing motor to delay rocket motor ingnition to high altitude can reap significant savings and result in more payload to orbit.
An additional benefit, also related to efficiency is the reduction in dynamic pressure. When launched from sea level, most spacecraft must throttle back their engines from 30 seconds to a minute at Max Q (the flight regime when dynamic pressure is at its maximum). If the spacecraft attempted to maintain higher thrust levels the shock waves building up on the leading surface would produce vibration which could damage the craft. Typically this means reducing thrust by 20-25% for a considerable time to minimize risk to the space craft. Craft launched from higher altitude do not reach supersonic or hypersonic thresholds until the air density is so low that the engines can safely operate at full throttle throughout. This reduces time spent in the atmosphere and increases engine efficiency.
This explains why Nasa in the 70s looked at several booster designs which had air breathing first stages which were both subsonic, and supersonic (about mach 3.5).
In the long run, hypersonic scramjets, are likely to be the most efficient chemical booster designs. Unfortunately this is a very long way off. Also distant are rocket engine designs (like the aerospike) which can operate more efficiently across a wider range of pressures.
In the medium term air breathing stage 1 (or stage 0) boosters make sense for both orbital an suborbital craft. They make the most sense, however, for suborbital spacecraft. For these, the additional 30-50K in altitude is directly significant.
In either case, I do think the Scaled Composites design could be a reasonable and cost effective approach.
Rutan's technology doesn't really fill the bill here because fabricating hybrid rockeet motors is expensive compared to refueling. Also its unlikely his aerodynamic body scales up as cheaply as does simple tankage with vertical takeoff.
I find your criticism of Rutan somewhat puzzling.
I agree with you and Truax that 2 stage transport vehicles are technologically compelling.
However, what's wrong with the Rutan vehicle? It has some advantages which are quite nice.
First, the first stage is a plane, not a rocket. It uses air breathing technologies which do not require lifting separate oxidizers. You state that this does not scale up as efficiently. 747s and C5 constellations suggest otherwise. A C5 can carry a useful payload of around 275,000 pounds. It has a typical cruising altitude of 34,000 feet. With a narrower fuselage, and different engines, instead of carrying large payloads thousands of miles, it would be well suited to carrying large payloads to 50 thousand feet.
A large air breathing first stage, makes far more sense than a conventional rocket. The mass and volume of oxider is wasteful and reduces the payload.
Reusable SSTO (single stage to orbit) is also compelling for small payloads to low earth orbit. Carmack and company are making contributions which are useful both to that end, and to extend research into pump, engine, and propellants which might prove better than Rutan's choice of solid propellant for upper stage rockets.
Large payloads, and higher orbits seem better suited to two stage designs. That a reasonably conventional aircraft might serve as a useful first stage is not very sexy. However, it is cheap, reliable, and can scale to sufficiently large payloads to make it far more scalable than you suggest.
I've always tried to deal with personality issues when I hire.
I've also had significant success when using pair programming. It's a great way to make sure process is followed, it improves quality, and it spreads knowledge around.
The phrase "Personality Problems" is merely one type of difference, which is relevant. You are right that some people do not work well with other, and are not valuable contributers in tight team environments.
You mention knowledge transfer which is of great value to both individuals and the wider organization. You mention process which if appropriate, can also provide similar benefit. However, "improves quality" is too vague to be a very useful statement.
I would agree that "improves quality" by reducing the frequency and magnitude of certain kinds of flaws. Common bugs, implementation flaws and design errors tend to to be less likely to occur and noticed more quickly if they do. If you refer to these by the phrase "improve quality", I agree.
In other senses, however, I believe that pair programming can reduce quality. It imposes a structure which can put some programmers at a distinct disadvantage, and thereby reduce their potentially valuable contributions to the code base and to the organization. The most common ways that pair programming can be a poor fit for some programmers is often categorized as a "Personality Problem",
Personality and individual temperament is highly variable. Despite this, statistically, there are a number of common traits shared by large groups of individuals. The ways in which a person habitually perceives problems and reasons about possible solutions is a core aspect of a persons personality. A number of occupational/industrial psychologists (and lay people) have performed research and written about personality or temperament. Much of this is worthless drivel (i.e. bull).
Despite this, the overwhelming evidence from experimental psychology, and several statistically sound studies of industrial psychology concur on several key points. First, certain aspects of personality emerge in infancy, and are highly stable throughout an individual's life. Second, several of these distinct personality traits influence the problem solving styles, perceptual styles, and interpersonal styles of the individual in ways which are both statistically significant and subject to analysis.
One such basic trait, an individual's tendency towards introversion or extraversion is especially relevant to pair programming. In conversation and thought an introverted person requires quiet reflection in order to develop their ideas and consider broader consequences. An extraverted person may find that talking out loud about a problem is most productive. Paired together, an introvert may be distracted and unable to realize their full potential. The extravert will suffer by not benefiting from good critical analysis of their work, They will not benefit from the ideas and knowledge that otherwise would have been forthcoming if their "chattiness" and relative impatience had not adversely affected their partner.
Some people benefit greatly from paired programming. Most people tend to be extraverted and pragmatic. Theoretical and highly technical professions tend to attract those who are more adept at abstract reasoning. Despite this, the majority of programmers tend to learn best from concrete examples and from hands on experience. The minority, about 10% in the general population and perhaps as much as 30% in the programming profession are introverts who work best by learning abstract principles and generalizing from them. Slight more than half of these have moderate to extreme introverted tendencies. Collaboration between these practical and theoretical types is theoretically of great value to both individuals and the organization. Their significantly different perceptions and problem solving styles can be highly complementary. The most stunning and productiv
In your opinion does a Siamese "person" count as one or two? They are as joined as these organisms. I would say that physical connection is not enough. What is I don't know though.
You raise an interesting point re: Siamese Twins. Like you, in the case of conjoined twins, I have the gut reaction that they are distinct. I also agree that physical connection is not enough. However, a bit more thought reveals that the case of conjoined twins is still not very clear cut. It only appears so initially by virtue of the special status that we grant people or other sentient creatures. In your first sentence you used the word "person", in the second you said "organism". We grant individuality to beings which are capable of perceiving the world, or even have the potential to do so. I think these two words sum up what makes conjoined twins special. By virtue of having two minds they demand consideration as individual persons despite the fact that physically they are a single organism.
The illusion that they are two joined organisms is further bolstered by the fact that the vast majority of conjoined twins are joined in only a few ways. Around two thirds are fused in the thorax or lower chest, just under 20% are joined at the buttocks. Of the rest, 6% have one form of lower body union (with no sharing of the heart) and 5% share the lower body in another geometry with or without cardiac involvement. The remaining ways in which conjoined twins are united are extremely rare. What this means is that, in the vast majority of cases, their outward physical form suggests that two otherwise healthy and well formed bodies are stuck together. The fact that the majority of such twins are largely well formed and of similar stages of development is unsurprising. More sever deformity or asymmetry would likely be fatal. In fact, the vast majority of potential conjoined twins are miscarried, about half of those which are carried to term are still born or die in a matter of hours or days.
Cases where one twin is significantly underdeveloped or malformed, are conveniently given a different label. Calling the less developed of these asymmetric conjoined twins a "parasitic twin", reduces the ethical hurdle on parents and doctors when sacrificing one to improve the viability of the remaining twin. Even in cases where each twin has a complete set of organs, lungs and a heart, during gestation and at birth it is difficult to argue that they are separate physical organisms. The mere possibility of their independent survival depends on considerable surgical and medical intervention. Those who share significant organs, circulatory systems, skeletal structure, or nervous systems are sometimes so interdependent that separation into two independently viable organisms is simply not feasible. This raises serious ethical issues such as that of the Attard twins. The conjoined sisters shared a single heart leading the parents to refuse surgery. The British high court ruled against them and ordered surgery, which only one person (the stronger of the twins) could possibly survive. In 2001 one child, Gracie, emerged from surgery. Her sibling, lacking a heart of her own, was sacrificed to give Gracie a chance of a healthier, longer life. Physically, this was indistinguishable from an amputation or removal of an abnormal growth. Ethically, this was the destruction of a person, as her sibling had a sufficiently development brain to warrant separate existence as a person. In this case only a single viable organism existed. That it was capable of providing biological support for only one of two conscious entities is sad and unfortunate.
What about trees or fungus? Trees are complex highly differentiated organisms like people. It is possible to identify components, subsets of the living thing, and make clear judgments about the viability of each subsystem if divided in specific ways. Both the internal and external structure of the systems provide ample basis for determin
I since found several other references which seem to confirm that the living mass of the Washington state mushroom is greater than that of Pando. Much of the bulk and mass of a tree is dead cellulose fibers. Though some of the mass of mycelial fiber is dead connective tissue as well, a substantially greater fraction of it is actively metabolizing living tissue.
It seems like this young whippersnapper wins the title (10,500 year old pando, vs 1,500 year old mushroom). I still wistfully hope that some Canadian behemoth is eventually found. I like mushrooms, they are tasty, but aesthetically I'd prefer a tree to win over a fungus (even though we are more closely related to the fungus than the tree).
Slashdot Mirror
I do not quibble with your basic premise that large vendors with a legacy Mac code base have been slow to migrate to Cocoa. Vendors of legacy apps (especially those with a large installed code base) have a number of reasons to move slowly.
However, I find it odd that you mention Mail.app and Omniweb as "new apps".
OmniWeb has been my primary browser since early 1995. Mail.app has been my sole email interface since 1990. That's 10 years, and 15 years respectively. They may seem "new" to legacy Macintosh users, but are decidedly not new.
I apologize if I put words in your mouth on several topics.
I assumed you were misinformed about those issue because of your continued insistence that the technology is file system specific, and that kernel notifications offer potential improvement.
You assert that notifications need only be sent when mtime changes, not for each file system write. This does not make sense. When a block write operation is performed in the vnode layer, it is passed to a filesystem specific write function. This, in turn updates the mtime. Thus, triggering notifications at the vnode layer for mtime updates would have to be performed for each block write. An attempt to optimize this, and pass along notifications less frequently would only be possible by pushing the notification down into each file system.
Second. You continue to state that this is a file system specific mechanism. It is not. Such a daemon can use fts(3) on non-hfs filesystems, and a faster hfs specific function on hfs+ volumes. It will be faster for the native filesystem. However, there is nothing preventing it from working on nfs, ufs, samba, or other volumes. In a very weak sense you may interpret this to be file system specific. However, you appeared to be claiming that it will only work at all on hfs volumes. This is not correct.
Thus, to finally close this, it is not file system specific in the first place, and is already more efficient than kernel notifications. In neither case do kqueues make any sense here.
A previous poster told you the truth.
Select a file.
c to copy a reference to the clipboard.
Select a directory.
-v to paste the file.
How is that difficult?
Moving a file, is one of two things.
Renaming, which is followed by the new name.
Changing the parent folder of the file. In this latter case there is no key board equivalent (of cut), there is only drag and drop.
One more time.
1. It is being done in user space, as a daemon, already.
2. It is not being done in HFS+ (beneath the vnode layer).
3. The meta data being discussed is not icon, label, or hfs fork metadata.
4. The meta data includes such things as dimensions and bit depth of graphic files, duration of song or movie files, and any other data which application files contain and which developers wish to provide interfaces for.
5. Changes to file contents will generally require triggering an update to meta-data indexing.
6. Thus, tying this into the vnode layer is a very bad idea. Block writes would have to trigger a notification.
Apple did not implement it in hfs+ or in other file systems beneath the vnode layer.
Apple did not, and should not have, implemented it at the vnode layer.
Instead, they wrote a daemon, which can check new and modified files, determine whether any changes are to be indexed or ignored, and call the approprate handler to gather the meta data to be indexed.
HFS+ will be more efficient than ufs or nfs for this. This is due to the fact that HFS+ supports btree based searches for filesystem metadata (i.e. find files of type T whose mtime > M) without requiring a full traversal of the file system. However, nothing precludes one from indexing meta data on other types of file systems.
Got it?
That is what I was responding to.
You say you want to place a hook in the vnode layer.
This hook would need to initiate a notification via kqueue.
In the context of this discussion, the extra logic for this
would need to be performed conditionally for all block write activity.
Even though kqueue, per se, is an efficient communication mechanism, your attempt to employ it for this purpose would impose additional overhead on all file system activity.
Thus, calling this 'efficient' is hardly a reasonable proposition whether or not the recipient is in userland.
I entirely disagree.
Placing it that low would have an impact on filesystem speed for other more general use. I don't want each open, or each block written to cause more time to be spent in the kernel. Even if that call were handled by another thread it would have an adverse impact on throughput.
Doing it in userland makes much more sense. System call overhead is lower. You may choose to nice the daemon or choose not to run it. Don't muck with the kernel for application layer functionality.
Design is more than functionality. Design is more than features. It's not about interface, per se. It's not even (as so many claim) that it's about style in the sense of fashion.
It's the whole shooting match.
People who don't grok Apple, don't seem to get that.
I had a can opener. A manual can opener, that I got for about 5 bucks in the early eighties. A maid accidentally threw it out several years ago. Only when it was gone, did I realize how wonderful it was. I searched off-and-on for months trying to find a suitable replacement. I bought 5 can-openers finding each to be annoying to use.
I finally bought one that was about half as good from a mail order place in Great Britain (I live in the US). Nobody in the world makes a can opener like what I used to own. It was the right weight, and had a perfect gearing. It gripped the lid, and neatly dropped it in the trash. The balance, texure, and feel were simply superb. If I were an architect or other design geek, I would have realized how good it was long ago. As it was, only by comparison with alternatives did I realize how nice it was.
The iPod, and other great designs from Apple, exhibit this kind of property.
If you look at a checklist of features, look at particular aspects of functionality, price, or other attributes in isolation, they do not appear special. Through feel, and through use, they just seem right. As a whole, they simply strike many people as right.
You're right, gold-plated, mpeg enabled, or cheaper, a true iPod killer would have to have the "whole package".
What's tricky, is that this requires attention to the details of the design which most people are never actually aware. It will take a great deal to "kill" the iPod.
Apparently BSD has been dying for much longer than people realize.
Since I've been using FreeBSD, NeXT, and MacOS X, exclusively for the past 15 years this news gives me pause for thought. Each OS has been reliable, fast, low-maintenance and enjoyable. Because of this I was not terribly concerned by the sad news that BSD was dying. Honestly, it always seemed pretty healthy to me.
Hearing that this fatal condition has persisted for much longer than I had known about, perhaps I should finally heed the warnings of its demise.
If I decide to switch to another OS are there lingering health problems I should worry about?
I hear that Windows has long suffered from epilepsy, incontinence, narcolepsy. It also has a severely compromised immune system which leaves it prone to opportunistic infections.
Linux on the other hand, appears to suffer from schizophrenia.
Any recommendations?
They add both NaCl (regular table salt) and other salts. They do so for flavor.
In Great Britain a while back they also added bromine for flavor, and treated it by bubbling ozone through it. Just as water with larger dissolved O2 in it tastes fresher, ozone imparts a similar flavor.
The problem is that bromine (which is harmless at moderate levels) become bromate when it reacts with ozone.
Bromate is a stong carcinogen.
Basically Coca-Cola, was pumping water from the Thames, filtering it, and adding carcinogens for flavor!
Dasani was recalled temporarily.
Teach the world to sing my ass!
In the USA the bottled water phenomenon saddens me. On average the quality, purity, and safety of tap water is higher than most bottled water. How did people get conned into spending more for water in many cases than for milk or gasoline? Are they really that F'ing stupid?
They sucked only slightly re the technology. It's more that they underestimated their competitors.
When they announced the initiative most digital display technologies were only capable of natively displaying at 720p. This is simply because the native resolution was typically 768 or 770 vertical rows of pixels. They can display 1080 images, but of course the conversion loses detail in the image.
The hdtv standard also has a format with 1080 vertical lines. 1080i (1080 lines interlaced) is a common broadcast standard. The top end (1080p) is the highest resolution in the standard. This year high end plasma displays are now shipping that can natively display 1080 lines (Sharp is one).
The rival rear projection technology for LCOS is DLP. DLP chip-sets have typically had a native resolution of 1280 x 768. TI started shipping a higher end version (the xHD3 chipset) that is capable of 1080p native resolution.
From Intel's standpoint:
1. They started planning an LCOS rollout at 720p native resolution.
2. Their competitors got to significant volumes of 1080p faster (and at lower price points) than they initially assumed.
3. They began redesigning to ship 1080p at rollout.
4. They had problems rolling out smaller line sizes in all of their fabs (IBM and others had similar difficulties). Their LCOS proved more difficult than they thought.
Poof. Longer time to recover investment now makes it less desirable.
Though I do realize your intent for humor, rexx is available under the GPL (LGPL actually).
Rexx with tcl bindings also exists, though sadly, is not called called T/Rexx, but Rexx/Tk
You can find them both at:
http://regina-rexx.sourceforge.net/
I'm glad you brought that up. I've been so long out of a well supported branch that I forgot about Software Update entirely. I agree with your assessment. Those who are on well populated branches of the code tree are best served by FreeBSD Update for security. Since security is a moving target, running on a STABLE branch and keeping up to date is the best way to ensure both stability and security. You correctly pointed out that if security were my primary concern, I should have been doing that.
My requirements several years ago made deploying a 5.0 snapshot release very worthwhile. The combination of functionality I desired was too compelling, and likely not to be added to 4.x for some time. Thus, I have balanced functionality, stability, and security by making certain trade offs. Obviously, a breach in security affecting the main cvs tree or cvsup could prove catastrophic.
However, once I decided to live in a relatively unsupported part of the code tree, it has served me well. Since I have a local mirror of the cvs repository, periodically checking out the sources and building via cron is very efficient and requires no labor whatsoever. Many security updates require me to simply ensure that my latest compile went smoothly, cd to an appropriate subdirectory, and run a script to perform a make install to the main system image and once for each jail DESTROOT, then restart service or the system as required.
If such a largely automated ability to upgrade the system or a subsystem was not present, I would have been foolhardy to run a production server so far from a well supported release. In retrospect I am extremely happy to have run so stably and so securely for the past 3 years. I have not had any crashes or unplanned outages during that time (except for a drive failure). I have also to my knowledge (there's always a possibility!) had no security breaches either to the host or to any of its jails.
In my opinion the true measure of security and stability is measured over time, not by a particular point in time. Security is a constantly moving target. If you remain still, you may eventually become vulnerable, or discover that you always were vulnerable, and just did not know it yet. The true beauty of FreeBSD, is that on a stable branch, it is possible with little effort and negligible risk to update your system frequently. Moving gracefully, in small steps as security, stability, and functionality improvements become available.
For a variety of reasons, I have chosen a much less traveled path. My trajectory has not been as graceful. However, my stability, and reasonably high level of security, has been maintained with very little extra effort. This is a testament to the rigor, and high quality of the FreeBSD security and release engineering processes.
I do look forward to rejoining the STABLE fold, soon after 5.3 is released. It will give me more options for rapid response to security, and make more frequent minor upgrades a viable approach again.
It depends on how you measure quick, and on your risk tolerance.
/usr/src/UPDATING to the letter. If you are unsure, opt for a binary install.
If by quick you mean the least time start to finish, yes. If you mean as measured in system downtime, no. Each has a different risk profile which depends heavily on how much additional software you have installed.
I too have been running 5.x as a server environment since mid 5.0 days. I have performed 2 source based upgrades in the interim to bring me to 5.2. My preference for source based upgrades is based partly on my desire for quick response time re: security. It is also conditioned by my rather complex setup in which I have multiple jailed environments each running a large number of packages. A binary upgrade is less attractive since I would need to install dozens of different ports and possibly face conflicts or temporarily broken ports.
You have very few ports running, and from your statement they are pretty stock configurations. From this standpoint a binary upgrade should be relative painless. However, it might require more downtime.
If I were you and were running a GENERIC kernel, and was running a late 5.1, or 5.2_RELEASE, I would suggest a source base approach. if you are running an earlier 5.x version I would still do so myself but would counsel you to assess your comfort and knowledge with compiling the code and following
If you do use a source base approach, I would prepare by installing the cvsup tools from the ports tree to mirror the source code and the ports tree. Then you can compile using buildworld and buildkernel, and even compile and install ports (using and alternate paths for the package db and destroot) to test versions of installed ports which might be newer.
Read UPDATING thoroughly and study any differences which you are unsure of. Then when you are ready, use install* targets and mergemaster to finish.
This is initially a longer, more time consuming approach, you must install sources, and configure cvsup to keep them up to date. Once that is done, however, they are always up to date. At each site which I have maintained FreeBSD, I use cvsup to mirror ports and sources on a single box. In fact, I mirror the cvs trees, enabling each host in the network to choose what particular version to check out. I then check out source trees via cvsup, and run a buildworld and a buildkernel via cron either weekly or monthly.
Thus, I always have a recent binary distribution ready to install when I feel like it. I upgrade rarely, but when I do, I typically have a 10-20 minute downtime. On boxes where I have configured multiple drives with sets of boot, usr, and var partitions, I configure and install to the alternate drive using the DESTROOT variable, and can take care of merging changes while running on the old version. Then downtime, is boot time + time to select the new boot partition.
The court system (both federal, and most states) does not agree with you.
You are correct that until rather recently most statutes concerning theft did correspond to older dictionary definitions requiring that a physical object be missing of that an object be moved from its rightful place.
However in 20th century statutes using the word "theft" began appearing which no longer rely on that old definition.
Statutes for theft of service, involving electrical power define unpaid use of electricity as theft. You have not stolen electrons, merely some of the motive power they convey. Legally however this is a from of theft. Later, theft of service in other forms was legislated. Tapping into a cable TV feed, receiving and decrypting real time stock ticker information broadcast over radio, are all considered theft by both federal and state laws.
In the latter form, you have deprived no-one of use of their property. You have however, attempted to derive personal benefit from something for which you have not paid.
On legal grounds your definition of theft appears unsound.
I see many problems with intellectual property and patent laws which no longer serve the public. Their intent was to provide a short time limited monopoly which was to spur innovation, and then devolve to the public domain and benefit everyone. In my opinion the grant of limited monopoly is no longer limited, and the benefit to the public vastly reduced. However that is a matter of politics, not of pragmatics or ethics.
I agree with your opinion that copying aught to be somehow different. However, ethically and pragmatically it still feels like theft. Legally, it also looks like theft.
Admitting that it is an illegal act, but insisting it is not theft is mere hair splitting.
Downloading a stolen copy of the OS is just plain wrong.
Apple paid 400 million dollars to buy NeXT. They then spent years of development effort integrating their older MacOS technologies to ensure backward compatibility. They released the resulting core OS for free use (in source code no less). They base a number of their core utility software on OpenSource products, and contribute much source code back to the community.
If you are running a BSD Unix, or running Linix, chances are you are already benefiting from Apple contributions to open source projects on a daily basis.
Ooh, you say, now we can pirate their GUI development utilities and application software! Grow up!
Why would you benefit from doing so? Because the software is worth using, will save you time, and will be enjoyable. If you benefit from a product or service, show some respect for those people responsible for providing it.
If you are not willing to pay anything, then use what is given for free. They respect and contribute to both GNU and BSD based projects.
If you are not willing to buy a new machine, then look on eBay, or online retailers who specialize in repairing and reselling older Mac hardware.
Yes, the software is damn good. No, they currently do not sell it on Intel hardware (either native or emulated).
Whether you or I like that or not, is beside the point. Using tools which improve your productivity or quality of life is worth something to you. If it is worthwhile, put up or shut up. In the open source world, contribute money or time to help improve it. In the commercial world, buy the product, and help fund further improvements.
BTW this is so common that the company in question has had problems due to this in the past.
Thus, their web site is reachable via both
www.ortlieb.com and
www.ortleib.com
In american primary schools we are taught the following mnemonic device for spelling.
"'I' before 'E' except after 'C' or when sounding like 'A' as in neighbor and weigh."
In american English the most common words we encounter that contain 'ie' or 'ei' are pronounced with long 'A' or long 'I' sounds not long 'E'.
Upon encountering 'ie' we thus assume a long 'I' sound as in 'bribe'. When trying to spell a proper name of european origin that sounds like 'ortleeb' we thus reject 'ie' and are drawn to the 'ei'.
When shooting for the long 'E' sound, the vowel ordering 'ie' just does not look right. Our assumptions about standard pronunciation makes the spelling 'ortlieb' appear incorrect since common words like 'lie' have a long 'I' sound.
You are correct. It's not a mix and match environment. Current X-prize competitors are focusing on a wide range of different engines, fuels, and components. Even if they were all working on traditional LOX + kerosene or LOX + hydrogen, many components are complex enough to demand significant effort to re-use in other designs.
People like XCOR, working on far less expensive, more traditional designs, can significantly advance the state of the art.
Its too early to tell what will happen.
However, before X-prize was announced in the late 90s, nobody in the world was working on manned space beyond crew return vehicles. Having manned space flight back on the table is wonderful.
Getting the big players out of the loop also helps. Military, Big Science, and government interests don't have a vested interest in manned space per se. (Manned space flight is there only as an adjunct to other goals.)
Although this might cause NASA budgets to be re-architected to funnel more R&D money to material science, I believe that the opposite might occur. Perhaps, NASA will reduce those budgets and start awarding contracts to some of these startups.
Neither NASA nor any of the big aerospace firms would have gotten approval for the kind of rapid development that Scaled Composites and many others, have managed. Think about it, Rutans SS1/SS2, has had only 6 powered flights. 3 of them were to space! Though further testing and analysis would be required for integrating components into more massive designs, the R&D budget of ~$30 million, would barely make prototype stage (let alone off the ground) in more traditional big aerospace organizations.
"Newer supported devices" is uselessly vague, as you are aware. Adding the words "wireless one" is more detailed, but not as you state, "more precise".
r e/ i386/index.html
d ware/ i386/support.html
Wireless could still mean almost anything. IRDA, 802.11*, bluetooth, heck you might be talking about anything from a mouse or a keyboard to an interface to an amateur packet radio band (via short wave). As a result, though I would like to provide an answer, I cannot. I can only make it easier for you to find it on your own.
FreeBSD supports a wide range of devices. Note however that FreeBSD strive for quality over quantity, and that your particular hardware may not be well supported yet, if supported at all. You should look at the hardware support page for the release you want to run. (version and host architecture)
For FreeeBSD 5.x on intel that page is:
http://www.freebsd.org/relnotes/5-STABLE/hardwa
It list all the hardware specific release notes for the i386 architecture, including motherboard, processors, and devices.
The device page covering everything from mice to raid controllers is:
http://www.freebsd.org/relnotes/5-STABLE/har
Does it support strange and obscure devices?
Yes.
Does it support your strange and obscure device?
I don't know, take a look and see. Good luck, I hope you give it a try. It's a very nice environment.
You claim that this is not a stepping stone toward any useful goal, that's it's "just advertising and a joy ride". Nothing less than cheap access to orbit is worthy of interest.
I agree with you that short, sub-orbital flight is only directly good for joy rides, and advertising. Beyond this however I disagree with you entirely. No offense, but I think you're missing the point.
Why? Because advertising and joy rides are the key to unlocking a revenue stream which can move us toward more useful goals.
Currently the only significant source of direct income from the private sector comes from launching satellites. This is a large source of revenue, but one which is neither very elastic, nor one which places demands on those who provide lift to significantly change the status quo. The cost of launching most satellites is but a fraction of the total cost. Adding together insurance, interest payments and other opportunity costs for capital, they are extraordinarily expensive objects even if launch costs are ignored. The market is narrow and capital intensive.
The result is that the market puts little pressure on firms to lift significantly larger payloads, either measured in volume or in mass. Incrementally reducing cost per pound on existing orbital launch systems would not be likely to increase the demand significantly. The risk of modifying these systems incrementally is simply not justified by the risk or the return on near term capital investment. Worst, no private income stream currently encourages development of manned missions at all.
The X-prize cup goal is provide direct incentive for innovation in manned space transport. It does so by providing a mechanism for directly infusing private capital into manned vehicles in ways that are much more flexible, much more elastic, and which result in pressure on potential space transportation designers to increase both aggregate and per launch lift capacity. The first prize was designed to promote competition in developing an inexpensive re-usable sub-orbital vehicle for carrying passengers. This will generate income in 2 ways. Advertisers will pay to be associated with the product and services provided by commercial users. Passengers able to afford a the ride will provide a significant on-going stream of revenue.
The passenger revenue is highly elastic. at the price of $200K per head, about 6,000 have already expressed serious interest in riding Virgin Galactic. 1.2 billion is nothing to sneeze at. If the price were $100K, that number would rise rapidly. As the price continues to lower, more and more passengers will be able and willing to afford even a sub-orbital jaunt. I'm not wealthy, but I would certainly drive crappy used cars for 5-10 years in return for a trip to space.
The X-prize cup is an annual event, Competitors will vie each year to travel greater distances downrange, achieve higher altitude, launch the most times during the event, carry the largest payloads, etc. The organizers expect that an X-prize competitor will achieve orbital capability in 5-8 years. That apparently would interest you.
In the past 30 years we've gone backwards not forwards. Aside from X-prize vehicles (both Scaled Composites and the 20 or so other contenders), the only manned space vehicles we have are based on designs form the 1960s and 1970s. Huge lift capacity died with apollo.
Without advertising and joy rides to both fund that development and promote competition, how do you propose we get there?
Although I was speaking mostly about ballistic, rather than orbital flight plans, altitude per se does benefit orbital trajectories as well.
You are correct in pointing out that velocity at apogee (tangential to a line drawn to the earths center) is the critical factor in acheiving orbit. Thus in an orbital flight plan, an eax 50,000 feet or so is not directly helpful. However, it is helpful indirectly.
Rocket motors are less efficient at higher pressure. A conventional bell shaped nozzle is more than 9% more efficient about about 15,000 than is is at sea level. Thus using an air breathing motor to delay rocket motor ingnition to high altitude can reap significant savings and result in more payload to orbit.
An additional benefit, also related to efficiency is the reduction in dynamic pressure. When launched from sea level, most spacecraft must throttle back their engines from 30 seconds to a minute at Max Q (the flight regime when dynamic pressure is at its maximum). If the spacecraft attempted to maintain higher thrust levels the shock waves building up on the leading surface would produce vibration which could damage the craft. Typically this means reducing thrust by 20-25% for a considerable time to minimize risk to the space craft. Craft launched from higher altitude do not reach supersonic or hypersonic thresholds until the air density is so low that the engines can safely operate at full throttle throughout. This reduces time spent in the atmosphere and increases engine efficiency.
This explains why Nasa in the 70s looked at several booster designs which had air breathing first stages which were both subsonic, and supersonic (about mach 3.5).
In the long run, hypersonic scramjets, are likely to be the most efficient chemical booster designs. Unfortunately this is a very long way off. Also distant are rocket engine designs (like the aerospike) which can operate more efficiently across a wider range of pressures.
In the medium term air breathing stage 1 (or stage 0) boosters make sense for both orbital an suborbital craft. They make the most sense, however, for suborbital spacecraft. For these, the additional 30-50K in altitude is directly significant.
In either case, I do think the Scaled Composites design could be a reasonable and cost effective approach.
I find your criticism of Rutan somewhat puzzling.
I agree with you and Truax that 2 stage transport vehicles are technologically compelling.
However, what's wrong with the Rutan vehicle? It has some advantages which are quite nice.
First, the first stage is a plane, not a rocket. It uses air breathing technologies which do not require lifting separate oxidizers. You state that this does not scale up as efficiently. 747s and C5 constellations suggest otherwise. A C5 can carry a useful payload of around 275,000 pounds. It has a typical cruising altitude of 34,000 feet. With a narrower fuselage, and different engines, instead of carrying large payloads thousands of miles, it would be well suited to carrying large payloads to 50 thousand feet.
A large air breathing first stage, makes far more sense than a conventional rocket. The mass and volume of oxider is wasteful and reduces the payload.
Reusable SSTO (single stage to orbit) is also compelling for small payloads to low earth orbit. Carmack and company are making contributions which are useful both to that end, and to extend research into pump, engine, and propellants which might prove better than Rutan's choice of solid propellant for upper stage rockets.
Large payloads, and higher orbits seem better suited to two stage designs. That a reasonably conventional aircraft might serve as a useful first stage is not very sexy. However, it is cheap, reliable, and can scale to sufficiently large payloads to make it far more scalable than you suggest.
The phrase "Personality Problems" is merely one type of difference, which is relevant. You are right that some people do not work well with other, and are not valuable contributers in tight team environments.
You mention knowledge transfer which is of great value to both individuals and the wider organization. You mention process which if appropriate, can also provide similar benefit. However, "improves quality" is too vague to be a very useful statement.
I would agree that "improves quality" by reducing the frequency and magnitude of certain kinds of flaws. Common bugs, implementation flaws and design errors tend to to be less likely to occur and noticed more quickly if they do. If you refer to these by the phrase "improve quality", I agree.
In other senses, however, I believe that pair programming can reduce quality. It imposes a structure which can put some programmers at a distinct disadvantage, and thereby reduce their potentially valuable contributions to the code base and to the organization. The most common ways that pair programming can be a poor fit for some programmers is often categorized as a "Personality Problem",
Personality and individual temperament is highly variable. Despite this, statistically, there are a number of common traits shared by large groups of individuals. The ways in which a person habitually perceives problems and reasons about possible solutions is a core aspect of a persons personality. A number of occupational/industrial psychologists (and lay people) have performed research and written about personality or temperament. Much of this is worthless drivel (i.e. bull).
Despite this, the overwhelming evidence from experimental psychology, and several statistically sound studies of industrial psychology concur on several key points. First, certain aspects of personality emerge in infancy, and are highly stable throughout an individual's life. Second, several of these distinct personality traits influence the problem solving styles, perceptual styles, and interpersonal styles of the individual in ways which are both statistically significant and subject to analysis.
One such basic trait, an individual's tendency towards introversion or extraversion is especially relevant to pair programming. In conversation and thought an introverted person requires quiet reflection in order to develop their ideas and consider broader consequences. An extraverted person may find that talking out loud about a problem is most productive. Paired together, an introvert may be distracted and unable to realize their full potential. The extravert will suffer by not benefiting from good critical analysis of their work, They will not benefit from the ideas and knowledge that otherwise would have been forthcoming if their "chattiness" and relative impatience had not adversely affected their partner.
Some people benefit greatly from paired programming. Most people tend to be extraverted and pragmatic. Theoretical and highly technical professions tend to attract those who are more adept at abstract reasoning. Despite this, the majority of programmers tend to learn best from concrete examples and from hands on experience. The minority, about 10% in the general population and perhaps as much as 30% in the programming profession are introverts who work best by learning abstract principles and generalizing from them. Slight more than half of these have moderate to extreme introverted tendencies. Collaboration between these practical and theoretical types is theoretically of great value to both individuals and the organization. Their significantly different perceptions and problem solving styles can be highly complementary. The most stunning and productiv
You raise an interesting point re: Siamese Twins. Like you, in the case of conjoined twins, I have the gut reaction that they are distinct. I also agree that physical connection is not enough. However, a bit more thought reveals that the case of conjoined twins is still not very clear cut. It only appears so initially by virtue of the special status that we grant people or other sentient creatures. In your first sentence you used the word "person", in the second you said "organism". We grant individuality to beings which are capable of perceiving the world, or even have the potential to do so. I think these two words sum up what makes conjoined twins special. By virtue of having two minds they demand consideration as individual persons despite the fact that physically they are a single organism.
The illusion that they are two joined organisms is further bolstered by the fact that the vast majority of conjoined twins are joined in only a few ways. Around two thirds are fused in the thorax or lower chest, just under 20% are joined at the buttocks. Of the rest, 6% have one form of lower body union (with no sharing of the heart) and 5% share the lower body in another geometry with or without cardiac involvement. The remaining ways in which conjoined twins are united are extremely rare. What this means is that, in the vast majority of cases, their outward physical form suggests that two otherwise healthy and well formed bodies are stuck together. The fact that the majority of such twins are largely well formed and of similar stages of development is unsurprising. More sever deformity or asymmetry would likely be fatal. In fact, the vast majority of potential conjoined twins are miscarried, about half of those which are carried to term are still born or die in a matter of hours or days.
Cases where one twin is significantly underdeveloped or malformed, are conveniently given a different label. Calling the less developed of these asymmetric conjoined twins a "parasitic twin", reduces the ethical hurdle on parents and doctors when sacrificing one to improve the viability of the remaining twin. Even in cases where each twin has a complete set of organs, lungs and a heart, during gestation and at birth it is difficult to argue that they are separate physical organisms. The mere possibility of their independent survival depends on considerable surgical and medical intervention. Those who share significant organs, circulatory systems, skeletal structure, or nervous systems are sometimes so interdependent that separation into two independently viable organisms is simply not feasible. This raises serious ethical issues such as that of the Attard twins. The conjoined sisters shared a single heart leading the parents to refuse surgery. The British high court ruled against them and ordered surgery, which only one person (the stronger of the twins) could possibly survive. In 2001 one child, Gracie, emerged from surgery. Her sibling, lacking a heart of her own, was sacrificed to give Gracie a chance of a healthier, longer life. Physically, this was indistinguishable from an amputation or removal of an abnormal growth. Ethically, this was the destruction of a person, as her sibling had a sufficiently development brain to warrant separate existence as a person. In this case only a single viable organism existed. That it was capable of providing biological support for only one of two conscious entities is sad and unfortunate.
What about trees or fungus? Trees are complex highly differentiated organisms like people. It is possible to identify components, subsets of the living thing, and make clear judgments about the viability of each subsystem if divided in specific ways. Both the internal and external structure of the systems provide ample basis for determin
Replying to my own post is kind of lame.
I since found several other references which seem to confirm that the living mass of the Washington state mushroom is greater than that of Pando. Much of the bulk and mass of a tree is dead cellulose fibers. Though some of the mass of mycelial fiber is dead connective tissue as well, a substantially greater fraction of it is actively metabolizing living tissue.
It seems like this young whippersnapper wins the title (10,500 year old pando, vs 1,500 year old mushroom). I still wistfully hope that some Canadian behemoth is eventually found. I like mushrooms, they are tasty, but aesthetically I'd prefer a tree to win over a fungus (even though we are more closely related to the fungus than the tree).