Some aspen forests are dominated by clones. Additional trunks sprout from the roots of its sibling, break the surface, and appear to be a distinct individuals even though the root system is still partially shared among them.
If the shared root structure is broken, certain clumps of trees may now be considered separate organisms, despite being genetically identical siblings. Logically, even a few capillary sized connections would suffice to define their status as a single organism.
The mycelia underground by which this fungus spreads, and which serves to define these large mushrooms as a single organism are analogous to the shared root system of these quaking aspen forests. The fruiting bodies (mushrooms) on the surface grow from a shared network of underground fibers. The trees and mushrooms are each genetically homogeneous, interconnected biological systems, thus single organisms.
One such tree/clone-forest in Utah named Pando (latin for "I spread") has over 47,000 trunks, weighs over 7 million kilograms, and covers about 118 acres. A large number of similar clone forests exist in Canada. Though some believe one or more of these Aspen groves in Canada is larger, Pando is older by several hundred years.
So, this mushroom in Washington has a web of mycelia that span 2200 acres. On the surface it seasonally fruits above ground bodies in shady areas scattered across this area. That's big. Despite the fact that the horizontal surface spanned by the underground network is about 20 times larger, perhaps the Aspen edges it out.
Above ground the volume and mass of the aspen, per acre, is significantly greater. One trunk, its branches, roots, and leaves, are certainly more massive than a significant number of mushrooms. At nearly 5 thousand trunks per acre, that's a lot of wood! Since the acreage difference is only a factor of 20, one only need show that one acre of Aspen is 20 times heavier or voluminous than one acre of this mushroom. I found no data to confirm this but I believe that 1 acre of Pando would kick one acre of mushrooms butt.
I'll grant that the mushroom covers a larger footprint on the soil thus has a larger area (measure in acreage). The mycelia also may edge out the root system per acre in displaced soil volume. Considered in their entirety I'd be very surprised if by volume or mass it is truly the largest. Thus, I find it hard to believe that this mushroom is a larger organism than Pando.
BTW, These clone forests are quite interesting in the fall and spring. The connected clones change color in the fall, and open their leaf buds in the spring in parallel. It is possible to see the boundary of clone forests, and spot genetically different isolated trees within the boundary of the forest. Mid season they are visually indistinguishable. At those times, isolated trees, or boundaries between genetically diverse stands of trees, are easy to spot visually.
A lot of people say FreeBSD is better because "its more stable" or "it has a more mature kernel" I've seen little evidence to substantiate these common claims. Whilst they may have been true some years ago are they really true today?
Apart from the cool things like the ports system and userland differences, licensing differences aside- At the core level of the kernel what makes a new FreeBSD kernel better than a new linux kernel?
There is a lot of hype on both sides of the fence here. Your skepticism is well founded. You asked several questions, which I will try to answer, but not without first adding some context. I think this additional context is needed because I suspect from your phrasing that perhaps you are asking the wrong questions.
You ask:
Is freeBSD more stable?
Is the kernal more mature?
What makes the FreeBSD kernel better then a new Linux Kernel?
The reason I am compelled to add some context is that your questions are lacking context. Value jusdgements like "better" and "more __ than" require context, in this case the context of utility. Better for what purpose, and towards which ends? More stable in the context of performing what tasks?
Another question that I have about the phrasing is stems from your mention of the ports system and userland as a preface to your question about which kernel is better. FreeBSD and Linux have different histories. Their user and developer communities have had different priorities. Each thus has different strengths and weaknesses in particular contexts. I would prefer Linux for certain specific uses and FreeBSD for others. The answer to your questions about stability and maturity will shed light on the rest.
Linux distributions emerged from a set of disparate components. BSD evolved from a complete whole. Starting from V6 and V7 Unix in the 70s, it has always been an indivisible whole, kernel, userland, documentation, the whole shebang. The technological strengths and weaknesses of each system, relate to this difference. The expectations and conventional practices of the systems users also are heavily influenced by these differences.
Linux users, developers, and administrators tend to applaud the rapid pace of development, greater number of new drivers and other features, and technical merits of certain specific aspects of the Linux kernel or userland. When hype is stripped away, I believe they are largely correct.
FreeBSD users, applaud, the stability, coherence, and ease of maintenance of their systems. Because it evolved from systems that were already in use, they always had an installed base, and many developers were motivated by keeping themselves and their existing users happy. The needs of system administrators were always well represented in the user and developer community.
Given a particular work load, and a particular set of applications, FreeBSD will outshine Linux on some tasks and be blown away by Linux on others. Each system is sufficiently mature that a well planned and well managed system of each flavor can run reliably for years. Yes, FreeBSD has historically been more stable and robust than Linux. It has a longer history, and its well managed release engineering process has kept the stable branches of the code remarkably robust and reliable over time. Given the rapid advancement of Linux however, the general stability and maturity of each system is quite high. If configured properly and deployed responsibly these gaps have narrowed and are largely moot.
The most compelling differences between FreeBSD and Linux are not terribly important if one deploys a single host and uses it directly. The difference is what is required to maintain the system over time.
FreeBSD is a unified whole, strongly influenced by the desire of administrators to keep users happy. As a result, the ongoing effort required to upgrade and maintain the systems is very smal
Less is more - Gnome, KDE and the Unixdesktop war.
on
GNOME 2.8 Released
·
· Score: 1
A number of posters have commented on the large memory footprint of Gnome (and of KDE). Others have made comments regarding code bloat, configurability, or more sophisticated graphical features such as transparency. Several readers have suggested that Macos X provides a wonderful user experience, one stating that FreeBSD or Linux on the server and Macos X on the desktop is the best approach. (That was moderated as flame bait BTW, which I find unjustified. I considered it merely off-topic since the poster did not elaborate).
KDE and gnome both have Macos X and Windows GUIs in their sights. They are looking for ease of use, and short ramp up time for new users. They are also looking to provide horizontal infrastructure to provide more functionality for developers of applications targeted to their environment. In short, they want to provide more power to developers by enabling them to write less code and provide more functionality. They want to provide more power to end users by providing a more familiar experience (familiar to what they are already used to). They also want to provide more general functionality in ways that are configurable. To do so they have expanded the functionality and scope of their systems dramatically in the past few years. However, to be more useful and valuable to the majority of users in the long run they need to reverse this trend in certain ways. They need to limit developers and users in consistent ways, and provide less flexibility not more in particular aspects.
KDE and Gnome have both improvement dramatically over the past several years. Both the depth and breath of their supporting libraries and the basic graphical expressiveness of their core frameworks have advanced. This has resulted in increasing the potential value of these systems for users and developers. However, the potential value, the potential utility of the software which relies on the framework in the context of how difficult it was to write, is essentially independent of the tangible value accruing to end users through use of applications.
Value is an inherently subjective measure. It is not intrinsic. It is measured person by person in the context of use. I believe that the biggest problem with most open source efforts is the failure to recognize that value is context dependent. The designers and developers fail to account for the inherently subjective nature of their judgments, and thus assess cost and value in ways that differ substantially from their users.
Complaints that memory footprint and CPU utilization are increasing, result mostly from developers' desire to increase the depth and breadth of the graphical toolset. They also result from attempts to broaden the support libraries which application developers can call from their code to provide general services (file system browsing, color choosers, etc.). These both serve to increase the potential power of the system for developers, by increasing the functionality which they may provide to users without writing it from scratch. However, developers tend to have more powerful systems with more memory, thus tend to underestimate the cost of this functionality as measured by more typical users. No wonder many complain of bloat, their experience of the system is qualitatively different.
This broader, deeper core functionality decreases the effort expended by application developers and makes development more enjoyable to them. This is of direct and tangible value to a developer measured in time, and enjoyment. Value as measured by developers or highly technical users, derives both through direct use of the resulting software and their interaction with the source code, other internal features of the software, and the supporting frameworks on which it rests. This often causes them to judge cost and value in significantly different ways than other users. Thus technical users are inherently prone to judgments which different significantly, even diametrically to those other users. After all a user derives no direct
I read a while ago about how OLEDs in the future could be part of an energy revolution, causing electricty consumption for lighting to be reduced to a tenth of present levels.
I do not believe OLED is a very good contender for this use.
Yes, they do use less power than the traditional LED technologies they compete with in the portable space, (e.g. PDAs, mobile phones, camera veiwfinders etc.) They do so for several reasons.
They have excellent contrast ratio.
They have lower power consumptions (largely because of the high power required for backlighting a transmissive LED display).
In the long run they require less capital for manufacturing (relying on ink-jet like deposition, rather than high vacuum technologies).
However, chemically they they are still rather fragile. The organic molecules degrade over time and with use. The different molecules used to produce the 3 primary colors also degrade at different rates resulting in poor and uneven color saturation over time. Though area lighting may indeed be in OLEDs future, I believe that other technologies are more compelling in this space.
They are thus well suited to displays which are used intermittently rather than continuously, for devices with tight power budget, and whose average useful product life is shorter than the expected life of the OLED.
We can expect OLED chemistry to improve over time, resulting in longer life, and more even color saturation over its useful life. Despite these gains, the fundamental physics of these emitters make very long life unrealistic. The OLED is interesting in applications where the following properties are compelling (or acceptable):
Low power
High contrast
Short Life
Low cost of manufacturing
OLEDs may be printed on a flexible substrate, and may eventually be cost effective to produce in larger sizes. In this way they may add large size to the above list. Think of rolling up a 30" display like a poster and carrying it in a tube in your backpack. I think if OLED does take off in this space, it is likely to be as niche. It would be interesting to have a low power, low heat output, light emitting panel which is flexible and can wrap around or deform to cover an irregularly shaped surface.
Long life high output light emitters are more likely to be best produced by nano-scale defects in solid sate devices. These may soon compete with incandescent, fluorescent, and cold cathode light sources for steady illumination. Long life, low power, small size, high resolution displays will also likely come from nano-scale defects in crystalline structures.
High pixel count, high density, large size displays, will be leave room for both of these types of technologies. For direct viewing, OLEDs may be compelling, as low temperature, light weight, and inexpensive manufacturing might prove compelling. They may need replacement several time per decade, however, as the organic compounds degrade. This is much like the phosphor decay in which severely limits the life of plasma display technology. Using rear projection, LCOS (a reflective rather than transmissive technology) appears to be the most promising technology, since advances in light source technology and display technology are decoupled. This will permit incremental advances in imaging and illumination technologies to proceed independently. LCOS (or something like it) and nano-scale LED illumination may be a big win as high output LEDs would eventually have longer life and much lower temperature than the high pressure lamps currently used.
See reports on HDTV technology and background info on Toshiba, Philips and Intel re: LCOS (and compare to the more popular but eventually inferior plasma, and DLP). Also see companies like Kopin technologies for info on high density low power displays and nano-scale LED technologies. The most compelling info on O
>What's a little disappointing is that this planet is orbiting a brown dwarf, which isn't really a star
Arguing that it is not a type of star seems questionable. There is a grey area between giant planetary objects and tiny stellar objects. Brown dwarves share properties with both at various times in their evolution.
A Brown dwarf masses between 1 and 8 percent of our suns mass (which is a yellow dwarf). This mass is too small for gravity to produce high enough temperature and pressure in the core to sustain the fusion of hydrogen nuclei into helium 4. However this does not mean that fusion cannot occur. It also does not mean that the surface temperature of the body, or the luminosity of the body are not star-like at some point.
Gravitational contraction alone raises the temperature of the gas considerably. Though the surface temperature of a typical brown dwarf may be as low as 1000K, early in their career the heat generated by their gravitational collapse be be high enough to shine red for a short time. Larger brown dwarves may also have pressures and temperatures at the core sufficient for deuterium and tritium based fusion reactions. The resulting release of energy is futile as it is far too small to even temporarily balance or reverse the gravitationally induced contraction. They couldn't make a go of fusion on the professional circuit, but fusion is fusion. If star-hood is a nuclear club, their amateur standing should count.
Yes, they are dim and cool. They can only continue to cool and eventually will radiate weakly in the radio spectrum, as Jupiter and other large gas plants do. However, at some points they may have pretty respectable surface temperatures (perhaps as high as 2500K). At the core they also may fuse some paltry amounts of deuterium and tritium.
On technical grounds this should justify calling them stars, if only briefly. On aesthetic grounds I also think these objects should be cut a bit of slack. The universe is cold and empty enough. Stripping these pitiful gas balls of star-hood entirely seems a bit too harsh.
They are both unsung, and many are certainly grateful for their contribution.
In early 1999 they wrote several articles and started a petition for releasing Macos X as open source. Their original goal was two-fold. They wanted Apple to release the core OS as open source, and for apple to continue selling and supporting "Yellow Box" development tools on Intel platforms. Apple did not continue supporting their development tools on either Windows (or on what was then Rhapsody for Intel). However, Apple subsequently released Darwin, and a number of other software projects, under an open source license.
Apple's increasing use of numerous BSD and GPL licensed code has resulted in a steady stream of patches both from Apple itself and from Apple users which are fed back upstream to the original projects. Projects ranging from OSes, utilities, compilers, and applications, benefit directly from these contributions.
Apple developers, OpenDarwin developers, and users of Macos X and darwin, have contributed improvements to FreeBSD, samba, Konquerer/KHTML, procmail, gcc, and many other projects. These contributions cross OS and license boundaries, benefiting linux users, BSD users, and users of open source tools on other commercial OSes.
Though Don Yacktman and Patrick Taylor were not directly affiliated with Apple, I am sure their voices and the voices of those whom they inspired, influenced Apple's decision. Don's prior work on projects like MiscKit, provided great value to NeXTStep and OPENSTEP developers. However, I believe that the petition for opening Macos X has done far more.
These names are probably unknown to most slashdot readers. A large percentage of users of open source OSes and tools have probably benefited indirectly from Apple's choice to release Darwin. These men helped influence that decision if not inspire it.
Before jumping to conclusions and flinching lest we be struck by the falling sky, let's take a step back.
First look at the most crucial benefits of the runtime environment. Mach supports an efficient and flexible framework for multiple memory objects. Objc leverages this by supporting the efficient mapping and unmapping of new bundles.
You may think of a bundle as a set of related objects in a language like Java, but don't take that analogy too far. The concepts of delegation, and protocols, usually mean that different bundles of code have clean interfaces that do not require recompilation when one or the other changes. Sometimes even knowledge of each other's type is irrelevant.
In any case, the best design for objc applications is a collection of separate UI definitions or nib files, and one or more libraries of code which are searched and loaded as needed at runtime.
Statically linked code, is more efficient for some tasks, but in the context of good objc design does not fit very well. Text which is statically linked is more fragile, it must be recompiled more often. It can also take more time to initialize and load; using late binding and lazy loading, only the sections to text and definitions of objects actually called will be mapped in memory.
Position independent code is absolutely needed for
this kind of flexibility at runtime. The gcc compiler grew up on CISC, on 32 bit or 16 architectures. Position independent code, had to be relative to something, and the most commonly useful location was always "You are here", the program counter.
I'm not sure whether a less frequently changed relative address such as a start of bundle address makes more sense for gcc on ppc.
In any event, however, I would certainly not be willing to categorize Apple's reliance on position independent code as a bug. By default, use pic.
A quote from Balmer ends the article. It highlights a serious problem in both Microsoft and the American business community.
"In a perception sense this hasn't been a very good four to five months, I'll be blunt. On the other hand we now understand another important lesson in terms of what it means to be a trustworthy partner."
This disgusts me. First, what he seems to find bad is the perception of the public, not the reality of his company's malfeasance. He then claims to understand a really important lesson about being trustworthy. Apparently that lesson is that a trustworthy partner does not lie. Some would tend to a harsher interpretation - that the lesson was don't get caught lying. Whether true or not, I find the most generous interpretation to be sufficiently damning.
I purchased roxio and tried it out in 10.1 months ago and was quite disappointed. Spin Doctor records an album to one large file, and only supports writing to CD rather than to a sequence of aiff files.
Spin Doctor also required that I record, run filters, mark begin and end for tracks, add title info, and burn to cd, all in sequence. Several times the program crashed and I had to start over with a new recording.
As a FreeBSD and OpenStep user I found the tool to be shoddy and to have that somehow condescending stink of Carbon. Tools should do one or a few things well, and read/write using standard types. Roxio and Spin Doctor did do one or two things well, but did not allow me to do anything else using other tools unless I burned a CD, read it back in as aiff then processed those files before burning the CDs I eventually want. It also used lots of cpu when idle and crashed several times.
I would rather spend my money on a fleet of separate applets, each reliable and each performing one task well, than spend any money on an app which may do a couple of things well but which wastes my time by enforcing its idea of workflow on me. I also have no patience for tools which do not support services and standards thus making it either hard or impossible to use it to perform only the parts of the job it does well.
Sorry for the rant, but I've been quite pissed off recently by the really shoddy quality of some big name carbon apps. I've used Appkit apps since 1991, and can see and feel the difference.
So are there any tools out there which I can use to record albums, split them into aiff files and perform filtering? I'll use iTunes to listen and record to CD. Again, 100% Cocoa is a plus obviously. Despite the above rant I am open to using a really good little Carbon tool, but I'll take some convincing.
I am a mac convert from the Unix side, actually inherited by Apple as an NeXT user. I am interested in a tool for recording my old vinyl, cleaning up pop, click, hiss, etc, and saving each track as aiff files, which I can then listen to in iTunes, and burn to CD for my car. This tool seems like overkill for me, but I though people posting on this topic may know of other software that would work well for my purposes. BTW: no Classic or OS9 app need apply. Bonus points for good use of services,or scriptability.
Slashdot Mirror
Some aspen forests are dominated by clones. Additional trunks sprout from the roots of its sibling, break the surface, and appear to be a distinct individuals even though the root system is still partially shared among them.
If the shared root structure is broken, certain clumps of trees may now be considered separate organisms, despite being genetically identical siblings. Logically, even a few capillary sized connections would suffice to define their status as a single organism.
The mycelia underground by which this fungus spreads, and which serves to define these large mushrooms as a single organism are analogous to the shared root system of these quaking aspen forests. The fruiting bodies (mushrooms) on the surface grow from a shared network of underground fibers. The trees and mushrooms are each genetically homogeneous, interconnected biological systems, thus single organisms.
One such tree/clone-forest in Utah named Pando (latin for "I spread") has over 47,000 trunks, weighs over 7 million kilograms, and covers about 118 acres. A large number of similar clone forests exist in Canada. Though some believe one or more of these Aspen groves in Canada is larger, Pando is older by several hundred years.
So, this mushroom in Washington has a web of mycelia that span 2200 acres. On the surface it seasonally fruits above ground bodies in shady areas scattered across this area. That's big. Despite the fact that the horizontal surface spanned by the underground network is about 20 times larger, perhaps the Aspen edges it out.
Above ground the volume and mass of the aspen, per acre, is significantly greater. One trunk, its branches, roots, and leaves, are certainly more massive than a significant number of mushrooms. At nearly 5 thousand trunks per acre, that's a lot of wood! Since the acreage difference is only a factor of 20, one only need show that one acre of Aspen is 20 times heavier or voluminous than one acre of this mushroom. I found no data to confirm this but I believe that 1 acre of Pando would kick one acre of mushrooms butt.
I'll grant that the mushroom covers a larger footprint on the soil thus has a larger area (measure in acreage). The mycelia also may edge out the root system per acre in displaced soil volume. Considered in their entirety I'd be very surprised if by volume or mass it is truly the largest. Thus, I find it hard to believe that this mushroom is a larger organism than Pando.
BTW, These clone forests are quite interesting in the fall and spring. The connected clones change color in the fall, and open their leaf buds in the spring in parallel. It is possible to see the boundary of clone forests, and spot genetically different isolated trees within the boundary of the forest. Mid season they are visually indistinguishable. At those times, isolated trees, or boundaries between genetically diverse stands of trees, are easy to spot visually.
There is a lot of hype on both sides of the fence here. Your skepticism is well founded. You asked several questions, which I will try to answer, but not without first adding some context. I think this additional context is needed because I suspect from your phrasing that perhaps you are asking the wrong questions.
You ask:
The reason I am compelled to add some context is that your questions are lacking context. Value jusdgements like "better" and "more __ than" require context, in this case the context of utility. Better for what purpose, and towards which ends? More stable in the context of performing what tasks?
Another question that I have about the phrasing is stems from your mention of the ports system and userland as a preface to your question about which kernel is better. FreeBSD and Linux have different histories. Their user and developer communities have had different priorities. Each thus has different strengths and weaknesses in particular contexts. I would prefer Linux for certain specific uses and FreeBSD for others. The answer to your questions about stability and maturity will shed light on the rest.
Linux distributions emerged from a set of disparate components. BSD evolved from a complete whole. Starting from V6 and V7 Unix in the 70s, it has always been an indivisible whole, kernel, userland, documentation, the whole shebang. The technological strengths and weaknesses of each system, relate to this difference. The expectations and conventional practices of the systems users also are heavily influenced by these differences.
Linux users, developers, and administrators tend to applaud the rapid pace of development, greater number of new drivers and other features, and technical merits of certain specific aspects of the Linux kernel or userland. When hype is stripped away, I believe they are largely correct.
FreeBSD users, applaud, the stability, coherence, and ease of maintenance of their systems. Because it evolved from systems that were already in use, they always had an installed base, and many developers were motivated by keeping themselves and their existing users happy. The needs of system administrators were always well represented in the user and developer community.
Given a particular work load, and a particular set of applications, FreeBSD will outshine Linux on some tasks and be blown away by Linux on others. Each system is sufficiently mature that a well planned and well managed system of each flavor can run reliably for years. Yes, FreeBSD has historically been more stable and robust than Linux. It has a longer history, and its well managed release engineering process has kept the stable branches of the code remarkably robust and reliable over time. Given the rapid advancement of Linux however, the general stability and maturity of each system is quite high. If configured properly and deployed responsibly these gaps have narrowed and are largely moot.
The most compelling differences between FreeBSD and Linux are not terribly important if one deploys a single host and uses it directly. The difference is what is required to maintain the system over time.
FreeBSD is a unified whole, strongly influenced by the desire of administrators to keep users happy. As a result, the ongoing effort required to upgrade and maintain the systems is very smal
A number of posters have commented on the large memory footprint of Gnome (and of KDE). Others have made comments regarding code bloat, configurability, or more sophisticated graphical features such as transparency. Several readers have suggested that Macos X provides a wonderful user experience, one stating that FreeBSD or Linux on the server and Macos X on the desktop is the best approach. (That was moderated as flame bait BTW, which I find unjustified. I considered it merely off-topic since the poster did not elaborate).
KDE and gnome both have Macos X and Windows GUIs in their sights. They are looking for ease of use, and short ramp up time for new users. They are also looking to provide horizontal infrastructure to provide more functionality for developers of applications targeted to their environment. In short, they want to provide more power to developers by enabling them to write less code and provide more functionality. They want to provide more power to end users by providing a more familiar experience (familiar to what they are already used to). They also want to provide more general functionality in ways that are configurable. To do so they have expanded the functionality and scope of their systems dramatically in the past few years. However, to be more useful and valuable to the majority of users in the long run they need to reverse this trend in certain ways. They need to limit developers and users in consistent ways, and provide less flexibility not more in particular aspects.
KDE and Gnome have both improvement dramatically over the past several years. Both the depth and breath of their supporting libraries and the basic graphical expressiveness of their core frameworks have advanced. This has resulted in increasing the potential value of these systems for users and developers. However, the potential value, the potential utility of the software which relies on the framework in the context of how difficult it was to write, is essentially independent of the tangible value accruing to end users through use of applications.
Value is an inherently subjective measure. It is not intrinsic. It is measured person by person in the context of use. I believe that the biggest problem with most open source efforts is the failure to recognize that value is context dependent. The designers and developers fail to account for the inherently subjective nature of their judgments, and thus assess cost and value in ways that differ substantially from their users.
Complaints that memory footprint and CPU utilization are increasing, result mostly from developers' desire to increase the depth and breadth of the graphical toolset. They also result from attempts to broaden the support libraries which application developers can call from their code to provide general services (file system browsing, color choosers, etc.). These both serve to increase the potential power of the system for developers, by increasing the functionality which they may provide to users without writing it from scratch. However, developers tend to have more powerful systems with more memory, thus tend to underestimate the cost of this functionality as measured by more typical users. No wonder many complain of bloat, their experience of the system is qualitatively different.
This broader, deeper core functionality decreases the effort expended by application developers and makes development more enjoyable to them. This is of direct and tangible value to a developer measured in time, and enjoyment. Value as measured by developers or highly technical users, derives both through direct use of the resulting software and their interaction with the source code, other internal features of the software, and the supporting frameworks on which it rests. This often causes them to judge cost and value in significantly different ways than other users. Thus technical users are inherently prone to judgments which different significantly, even diametrically to those other users. After all a user derives no direct
I do not believe OLED is a very good contender for this use.
Yes, they do use less power than the traditional LED technologies they compete with in the portable space, (e.g. PDAs, mobile phones, camera veiwfinders etc.) They do so for several reasons.
However, chemically they they are still rather fragile. The organic molecules degrade over time and with use. The different molecules used to produce the 3 primary colors also degrade at different rates resulting in poor and uneven color saturation over time. Though area lighting may indeed be in OLEDs future, I believe that other technologies are more compelling in this space.
They are thus well suited to displays which are used intermittently rather than continuously, for devices with tight power budget, and whose average useful product life is shorter than the expected life of the OLED.
We can expect OLED chemistry to improve over time, resulting in longer life, and more even color saturation over its useful life. Despite these gains, the fundamental physics of these emitters make very long life unrealistic. The OLED is interesting in applications where the following properties are compelling (or acceptable):
OLEDs may be printed on a flexible substrate, and may eventually be cost effective to produce in larger sizes. In this way they may add large size to the above list. Think of rolling up a 30" display like a poster and carrying it in a tube in your backpack. I think if OLED does take off in this space, it is likely to be as niche. It would be interesting to have a low power, low heat output, light emitting panel which is flexible and can wrap around or deform to cover an irregularly shaped surface.
Long life high output light emitters are more likely to be best produced by nano-scale defects in solid sate devices. These may soon compete with incandescent, fluorescent, and cold cathode light sources for steady illumination. Long life, low power, small size, high resolution displays will also likely come from nano-scale defects in crystalline structures.
High pixel count, high density, large size displays, will be leave room for both of these types of technologies. For direct viewing, OLEDs may be compelling, as low temperature, light weight, and inexpensive manufacturing might prove compelling. They may need replacement several time per decade, however, as the organic compounds degrade. This is much like the phosphor decay in which severely limits the life of plasma display technology. Using rear projection, LCOS (a reflective rather than transmissive technology) appears to be the most promising technology, since advances in light source technology and display technology are decoupled. This will permit incremental advances in imaging and illumination technologies to proceed independently. LCOS (or something like it) and nano-scale LED illumination may be a big win as high output LEDs would eventually have longer life and much lower temperature than the high pressure lamps currently used.
See reports on HDTV technology and background info on Toshiba, Philips and Intel re: LCOS (and compare to the more popular but eventually inferior plasma, and DLP).
Also see companies like Kopin technologies for info on high density low power displays and nano-scale LED technologies. The most compelling info on O
>What's a little disappointing is that this planet is orbiting a brown dwarf, which isn't really a star
.
Arguing that it is not a type of star seems questionable. There is a grey area between giant planetary objects and tiny stellar objects. Brown dwarves share properties with both at various times in their evolution.
A Brown dwarf masses between 1 and 8 percent of our suns mass (which is a yellow dwarf). This mass is too small for gravity to produce high enough temperature and pressure in the core to sustain the fusion of hydrogen nuclei into helium 4. However this does not mean that fusion cannot occur. It also does not mean that the surface temperature of the body, or the luminosity of the body are not star-like at some point.
Gravitational contraction alone raises the temperature of the gas considerably. Though the surface temperature of a typical brown dwarf may be as low as 1000K, early in their career the heat generated by their gravitational collapse be be high enough to shine red for a short time. Larger brown dwarves may also have pressures and temperatures at the core sufficient for deuterium and tritium based fusion reactions. The resulting release of energy is futile as it is far too small to even temporarily balance or reverse the gravitationally induced contraction. They couldn't make a go of fusion on the professional circuit, but fusion is fusion. If star-hood is a nuclear club, their amateur standing should count
Yes, they are dim and cool. They can only continue to cool and eventually will radiate weakly in the radio spectrum, as Jupiter and other large gas plants do. However, at some points they may have pretty respectable surface temperatures (perhaps as high as 2500K). At the core they also may fuse some paltry amounts of deuterium and tritium.
On technical grounds this should justify calling them stars, if only briefly. On aesthetic grounds I also think these objects should be cut a bit of slack. The universe is cold and empty enough. Stripping these pitiful gas balls of star-hood entirely seems a bit too harsh.
They are both unsung, and many are certainly grateful for their contribution.
In early 1999 they wrote several articles and started a petition for releasing Macos X as open source. Their original goal was two-fold. They wanted Apple to release the core OS as open source, and for apple to continue selling and supporting "Yellow Box" development tools on Intel platforms. Apple did not continue supporting their development tools on either Windows (or on what was then Rhapsody for Intel). However, Apple subsequently released Darwin, and a number of other software projects, under an open source license.
Apple's increasing use of numerous BSD and GPL licensed code has resulted in a steady stream of patches both from Apple itself and from Apple users which are fed back upstream to the original projects. Projects ranging from OSes, utilities, compilers, and applications, benefit directly from these contributions.
Apple developers, OpenDarwin developers, and users of Macos X and darwin, have contributed improvements to FreeBSD, samba, Konquerer/KHTML, procmail, gcc, and many other projects. These contributions cross OS and license boundaries, benefiting linux users, BSD users, and users of open source tools on other commercial OSes.
Though Don Yacktman and Patrick Taylor were not directly affiliated with Apple, I am sure their voices and the voices of those whom they inspired, influenced Apple's decision. Don's prior work on projects like MiscKit, provided great value to NeXTStep and OPENSTEP developers. However, I believe that the petition for opening Macos X has done far more.
These names are probably unknown to most slashdot readers. A large percentage of users of open source OSes and tools have probably benefited indirectly from Apple's choice to release Darwin. These men helped influence that decision if not inspire it.
Unsung hero seems an apt description.
First look at the most crucial benefits of the runtime environment. Mach supports an efficient and flexible framework for multiple memory objects. Objc leverages this by supporting the efficient mapping and unmapping of new bundles.
You may think of a bundle as a set of related objects in a language like Java, but don't take that analogy too far. The concepts of delegation, and protocols, usually mean that different bundles of code have clean interfaces that do not require recompilation when one or the other changes. Sometimes even knowledge of each other's type is irrelevant.
In any case, the best design for objc applications is a collection of separate UI definitions or nib files, and one or more libraries of code which are searched and loaded as needed at runtime.
Statically linked code, is more efficient for some tasks, but in the context of good objc design does not fit very well. Text which is statically linked is more fragile, it must be recompiled more often. It can also take more time to initialize and load; using late binding and lazy loading, only the sections to text and definitions of objects actually called will be mapped in memory.
Position independent code is absolutely needed for this kind of flexibility at runtime. The gcc compiler grew up on CISC, on 32 bit or 16 architectures. Position independent code, had to be relative to something, and the most commonly useful location was always "You are here", the program counter.
I'm not sure whether a less frequently changed relative address such as a start of bundle address makes more sense for gcc on ppc. In any event, however, I would certainly not be willing to categorize Apple's reliance on position independent code as a bug. By default, use pic.
"In a perception sense this hasn't been a very good four to five months, I'll be blunt. On the other hand we now understand another important lesson in terms of what it means to be a trustworthy partner."
This disgusts me. First, what he seems to find bad is the perception of the public, not the reality of his company's malfeasance. He then claims to understand a really important lesson about being trustworthy. Apparently that lesson is that a trustworthy partner does not lie. Some would tend to a harsher interpretation - that the lesson was don't get caught lying. Whether true or not, I find the most generous interpretation to be sufficiently damning.
Pretty lame Mr. Balmer, pretty lame.
I purchased roxio and tried it out in 10.1 months ago and was quite disappointed. Spin Doctor records an album to one large file, and only supports writing to CD rather than to a sequence of aiff files.
Spin Doctor also required that I record, run filters, mark begin and end for tracks, add title info, and burn to cd, all in sequence. Several times the program crashed and I had to start over with a new recording.
As a FreeBSD and OpenStep user I found the tool to be shoddy and to have that somehow condescending stink of Carbon. Tools should do one or a few things well, and read/write using standard types. Roxio and Spin Doctor did do one or two things well, but did not allow me to do anything else using other tools unless I burned a CD, read it back in as aiff then processed those files before burning the CDs I eventually want. It also used lots of cpu when idle and crashed several times.
I would rather spend my money on a fleet of separate applets, each reliable and each performing one task well, than spend any money on an app which may do a couple of things well but which wastes my time by enforcing its idea of workflow on me. I also have no patience for tools which do not support services and standards thus making it either hard or impossible to use it to perform only the parts of the job it does well.
Sorry for the rant, but I've been quite pissed off recently by the really shoddy quality of some big name carbon apps. I've used Appkit apps since 1991, and can see and feel the difference.
So are there any tools out there which I can use to record albums, split them into aiff files and perform filtering? I'll use iTunes to listen and record to CD. Again, 100% Cocoa is a plus obviously. Despite the above rant I am open to using a really good little Carbon tool, but I'll take some convincing.
I am a mac convert from the Unix side, actually inherited by Apple as an NeXT user. I am interested in a tool for recording my old vinyl, cleaning up pop, click, hiss, etc, and saving each track as aiff files, which I can then listen to in iTunes, and burn to CD for my car. This tool seems like overkill for me, but I though people posting on this topic may know of other software that would work well for my purposes. BTW: no Classic or OS9 app need apply. Bonus points for good use of services,or scriptability.