Troll or no, since you've been modded up so high, I feel compelled to respond.
Madness does not exist in any objective sense.
Actually, you are completely wrong. True, some people who are called "mad" are not "mad" by any known objective metric, but diseases which induce "madness" via neurochemical imbalance are well documented. If your body has issues with how certain neurotransmitters are either generated or used, causing an imbalance, it can make the brain run seriously out-of-spec. E.g. it's been found that manic depressives have very high levels of seratonin during the manic ("happy") phase, but very low levels during a depressive phase. There's tons of info on the web about this: search for schizophrenia, depression, obsessive-compulsive disorder, and related info on neurotransmitters, etc.
You've got a political-correctness-of-conformity issue, which you are wrongly using to ignore valuable medical science. This is especially bad when the medical viewpoint is far more compassionate and humanitarian than, for example, the historical view of the medically "mad" as "posessed by satan," with the horrible treatments that endengered.
There was surprisingly little controversy in this session, perhaps because it concentrated on goals and didn't get into actual implementation designs.
This underscores a key point, that this was a forum for future requirements and architectural directions in the Linux kernel. Many skilled and competent kernel hackers would have had little to add to these sessions and little to gain that wasn't offered in the summary report. Even then, truly interested participants will still chime in on the mailing lists and via other means.
Ultimately, hacker/programmer != architect. Why? A hypothetical 'pure' programmer is interested in solely in implementation issues while the 'pure' architect is interested in design issues. In practice, the two are related, yet many individuals show pronounced skill in one area over (or relative to) the other.
This meeting was heavily stilted towards the architects (who are almost all programmers, in this case). Those without the OS kernel architectural chops would have either bogged things down or been lost and bored stiff.
I'll chime in to concur with the above assessment: it's fairly easy to take your home directory and any special system config files and scripts you have from one distro to another.
If you are careful, you can always just mkfs over partitions that are distro-specific, making sure to preserve the partition with/home on it. (If/home has its own partition, this becomes _really_ easy.) I've done just this conversion to change a RedHat system to a Debian system, with a minimum of fuss. You can even keep a non-tar/gz copy of your important/etc config files in your home directory for easy access during the reinstall.
You are assuming hydrogen combustion. The much more interesting work in that regard is on hydrogen fuel cells, which produce electricity from hydrogen and oxygen from the air via catalytic reaction. From what I've read, they are extremely clean, nearly distilled-grade water as the exhaust. "mmm thirsty, need to drive somewhere..." 8-)
I absolutely disagree. I've seen Java used in the first year, in a true OO-from the ground-up approach, to amazing effect. Done right, the students are capable of much more interesting coding (both in "personal interest" and "interesting CS fundamentals") in the first year than they ever would have been in a procedural/modular style program.
The problem in question is that your instructor(s) had no idea how OO should be taught. Even if one can program in an OO style, an instructor used to teaching old-school structured or modular style often results in a machine that makes broken students.
It's nigh-impossible to express "the right way" in a/. comment, but I'll point out that Brown University (formerly using OO Pascal/Delphi, now Java) and Virginia Tech have excellent programs that do OO from the first day. They aren't the only programs that do it right, either. It's a matter of OO requiring a very different teaching style. Brown's old book (Object-Oriented Programming in Pascal, A Graphical Approach, by Conner, van Dam, and Niguidula) didn't hit control structures until chapter 10 or so. Earlier chapters dealt with OO conceptual fundamentals, including non-programming modelling exercises (think in objects), object instantiation, method invocation, composition, and inheritance. Sounds rough? Nope, it's natural as water in the way and order they teach it.
I agree, in that I also believe that we will see continuing improvements in end-user programming environments.
OTOH, I don't buy the magic self-programming computer. This sort of prognostication is much like the now-laughable predictions in the early 1950's by an MIT professor that "I think that within five years we will have computers that can think."
That is, the problem of "programming" the computer via natural language is so vast as to be nearly equivalent to the (now somewhat discredited) goal of "classic" AI to put a brain in a box (or rather, create a non-embodied AI). Why? Because "natural language" lacks precision and information. Anyone who's had to reconcile marketing "requirements" with engineering reality will realize the incredible disjoint here. In its most general form, you are creating a programmer AI who:
Must be able to productively negotiate with the human client to determine the actual problem to be solved. ** This is one of the top skills of good lead-level programmers.
Must be able to analyze and understand the problem domain at least partially independently of the human client's input. In the real world, this often means consulting with a variety of humans involved with the problem, doing research, and relying on a staggering amount of world knowledge from having been a human being in the world for a few decades.
No, I believe that highly skilled humans will always remain a part of the "programming" process even in the distant future (unless/until the very notion of "human" itself is challenged, ala some Brin short stories in Otherness.) As knowledge and technology improve, the capabilities of end-users will increase... as will the capabilities of the highly skilled software creators. Such "programmers" will be empowered by ever more sophisticated knowledge of software architecture, HCI, algorithmics, and lessons of history... along with some powerful software tools. But in the end, it will be humans using tools to craft things that have value to the human experience.
Others have rightly mentioned the flaw in trusting the client side to accurately report your own critical data back to you. This is the technical flaw, but not the root cause. This situation is a prime example of the business risk of employing an underqualified software development staff. (N.B. this could be direct employment, or "employment" via your purchasing department). A lead developer (or preferable, software architect) who analyzed and understood the problem domain (an online shop) separately from the machine (i.e. program) that implements the soltion, would not have exposed this obvious security risk.
Her eyes literally glazed over. I was in protracted-rant mode [...]
Remember: the Rant is the ultimate form of "the medium is the message." That is, the Rant itself overwhelms the message to everyone except the already convinced. The unconvinced listener only hears the rant, and the message itself gets lost in the strident ring of emotion. The convinced listener echoes sympathy, but the effort is wasted (aka "Preaching to the Choir").
When the urge to rant comes along, step back from it and consider a more relaxed approach. Don't preach, but instead engage your audience. One tactic: ask your audience what he/she/they think of the issue. This buys you a few things. 1) You'll sometimes pique interest where a rant would have quashed it. 2) You can gague whether your audience is at all receptive (and spare them if they aren't). 3) You set the tone for a calmer and more interactive discussion.
An OS is *not* something that gets between a user and what they want to do. Instead, it's the tool that provides consistent services to both the user and the applications running on it.
BOOT TO THE HEAD, to you and everyone else in this thread that failed to read the article. It explicitly puts "OS" in context with the phrase: the concept of the OS as an application. As Raskin says:
"One big mistake is the idea of an operating system... [which] is the program you have to hassle with before you get to hassle with the application. It does nothing for you, wastes your time, is unnecessary,"
Read Jef's book The Humane Interface and Don Norman's The Invisible Computer to get some vision into this movement. And read the article. The essence is that a class of tools new and distinct from the PC will emerge, in which (among other things) the concept of OS as application will be dead.
Just how often does a painter immersed in the creative act stop to think about minutiae of the paintbrush? Or worse still, get interrupted by the paintbrush? Not often, and that's a hallmark of a good tool -- that it be subsumed as completely as possible beneath the user's attention to the task. The PC as we know it can undergo vast improvement towards being a really great tool for a particular task -- and this will likely involve some specialization. Again, read the above books and get a leg up on the next wave...
Others have rightly pointed out "find a bug and fix it". I'll weaken this a little: find a bug and identify it. To start, you needn't even find the "correct" fix -- for some problems this can be hard to do, especially if you are inexperienced and didn't architect the code in the first place.
It is *VERY* important to your development as a programmer to get involved with sophisticated code that someone else has written. You'll see good code, bad code, ugly code, and learn to tell the difference between them. This will improve your own coding styles. You'll learn about various coding techniques, data structures, etc. in something resembling a real application.
[rant about deluge of unmotivated "I just want a job" students in CS academia deleted for brevity.]
Perhaps the entire SECTION of the article "Sony's next Trinitron?" flew completely under your radar? The article explicitly discusses application across a wide range of display sizes and markets.
Moreover, if you had the slightest clue about the currently available display technologies they mention (LCD variants, DLP, etc.) the application of GLV is obvious -- to either front or rear projection displays. See Samsung's line of projection TVs (PLK405W, plus their entire HDTV line) which includes both tabletop sets and floorstanding projection TVs. See every DLP projector out there.
Personally, I find this fascinating. GLV's use of laser-scanning instead of the conventional (consumable and expensive) projection bulbs may turn out to be a big win for Sony vs. other technologies. I'll be interested to see relative power-consumption and efficiency figures for comparable DLV and {LCD,DLP,etc.} projectors.
Your exact wish is likely to be unrealized for several reasons:
Flash memory is getting rapidly larger, cheaper, faster just like all other memory. Sony has announced a 1GB Memory Stick due 3-4Q 2001, and Hitachi has 2GB flash (in chip and one of the major flash formats, maybe SmartMedia) due in around the same timeframe.
In a few years it will see serious competition from MRAM (Magnetic RAM) technologies hitting the market. MRAM will provide a combination of low power drain, high speed, and high capacity (relative to DRAM) in addition to being non-volatile. It may well obsolete both DRAM and Flash.
Short form: unless IBM has some simply amazing ultraminiature hard drive voodoo in the research pipeline, the solid state technologies are likely to be total design wins starting late next year.
This sonogram analysis is quaint, but the author fails to grok the basics of psychoacoustic model based audio compression. The first rule is: you cannot measure the perceptual quality of the compressed audio via a raw distortion metric. Subtracting the original signal's sonogram from the compressed signal's sonogram is a distortion metric.
That said, it is generally the case that "pre-echo is bad" and "over-ring is bad." Reducing these can be thought of as a good thing. Let's assume that for these encoders, pre-echo and over-ring are universally bad (I'll give an example where this isn't the case, below). Furthermore, this comparison actually says nothing about these encoders other than the pre-echo or over-ring. I.e. what happened to the sound that was the "same" on the sonogram? It is quite possible for an "encoder" to mangle the audio quality yet have a pristine sonogram by this test's standards.
Just to throw a wrench in the works, more advanced encoders and/or psychoacoustic models can utilize what's called temporal masking. This is the ability of a higher-amplitude signal to mask (make inaudible) a lower-amplitude signal either before or after itself, as far as the human ear is concerned. Pre-echo is the phenomenon whereby a transient signal (i.e. a very 'sudden' attack, like a drum hit) is smeared in time. The audible effect can be most obnoxious. Yet encoders utilizing temporal masking will explicitly allow a certain amount of pre-echo through, as long as it is temporally masked. This leaves the encoder to spend those bits on other parts of the signal that would be more seriously degraded as far as our ear is concerned. In short, a sufficiently savvy encoder could exhibit more pre-echo than another worse-sounding encoder, especially if it uses temporal masking.
Quantitative analysis for perceptual audio coding is not easy; this has been a grail for researchers in the field for years. I strongly suggest that interested parties dig into various IEEE and AES (Audio Engineering Society) journal papers on the subject, as well as various books, etc.
Stable filesystem or not, I'd still be running a filesystem check.
This is not necessary in a properly designed filesystem. The only reason for fsck is that the f/s algorithms permit the filesystem image on disk to be in an invalid state. The goal of more modern f/s design is to ensure that before, during, and after all operations, the filesystem is in a valid state. I.e. no operation ever, even temporarily, corrupts the filesystem.
E.g. journalling filesystems such as XFS perform the same constant-time check routine every time they start, to inspect and clean up the journal (and commit transactions, if necessary) in case we crashed last time. The journal may not be complete, and some modest amount of data may have been lost, but the filesystem is not corrupt.
Yes, the Bell Labs folks created something like
that for Plan9. It's not a filesystem, however,
but rather the main fileserver. It's basically
a WORM jukebox with a RAID caching the WORM and
a bunch of RAM caching the RAID -- and the whole
thing essentially just implements the 9P filesystem protocol.
On a daily basis, the RAID cache is synched back to WORM. At any time, a user of the system can just cd to the fileserver's state for that day and inspect those files. E.g.
cd/history/1997/October/13/...
When they had the WORM (hmm.. might have been MO, don't have the paper handy) juke upgraded, the team noted that the capacity of the jukebox was
expanding faster than they were using it, even with the system state snapshots. 8-)
I'll probably get modded down for saying this, but what gives with all of the vocal gripe posts that surround various bits of new tech? This tech has a use model seemingly identical to existing KVMs, with some added features: some people/installations need this for a variety of reasons. Given that there exists a market for KVM extenders, maybe the gripers should get informed about the intended market instead of whining "I don't need this! It sucks!" or "No one needs this! It sucks!"
[Ob. Actual Content:] Here's a couple of examples of this tech's use:
Security Physical system security needs may make it desirable to not have the CPU case located with the user station.
Noise Disk and fan noise suck, especially for professional/project music studios, or even for general working environments.
Note that X/M$ Terminal Server/etc. aren't applicable for the uses of a KVM! All such solutions require a system (even if only a thin client) at the user location -- and none work well (or at all) in a multi-platform environment.
There is not only the concern of Brooks' Law, but also competence for the work requested. It is important to consider the level of work you will be asking of the overseas group vs. their actual skills. Are you providing gorily detailed project specifications or just a set of general requirements?
In my experience with one such situation, the group was pretty good at turning the crank when provided with sufficient information, but abysmal when faced with a 'blank page situation'. I.e. they could do raw implementation or extend an existing design, but possessed no design skills.
If you buy into the idea of the open source movement being a gift culture, as suggested by ESR, then the answer to CmdrTaco's question "isn't saying thanks and crediting your source part of it too?" is obviously yes. In gift culture, it is precisely this lack of acknowledgement which is a major slight to the giver. It is a substantial part of the "payment" for the contribution of effort.
... and on a somewhat offtopic note, consider the 5-rated (!!) troll who wrote:
"...this is the road that RMS and the FSF want to lead us down. No IP rights, and no recourse against people who "share" the output of your hard work."
What a truly astonishing lack of clue about the FSF and its goals.
While it's all very fashionable to tout the PS2 and bash
Microsoft (and by extension, the X-Box) on/., there is another
side to the story. That of the game developer. It seems that
many game developers are flocking to X-Box, sometimes dropping
PS2.
Some facts:
No game consoles are open development platforms. You must be licensed by the console manufacturer to produce titles for that box.
Japanese corporate business practices, for all you decry
Microsoft's foul play, makes MS look like flowers and
sunshine. Japanese corps, Sony no exception, can be
ruthlessly anti-competitive ESPECIALLY to foreign
competition.
Now if you put #1 and #2 together, you may start to appreciate why
U.S. game developers are heralding the arrival of the X-Box.
They've been in an anti-competitive situation for many years now, with
the U.S. console market dominated by Japanese corporations. Game
developers finally have a modern U.S. console to target, without
the competitive problems they've been suffering.
What it comes down to is that Microsoft's presence in this market
is out-and-out good news for U.S. game developers. Period. That
fact alone will change the nature of titles available for X-Box
(and possibly PS2, through competition).
You assume that the Asker is seeking to distribute the work of one program. Perhaps the real goal is to create a single seamless computing environment out of a widely differing (aka heterogeneous) collection of computing devices. User terminals, compute servers, data servers, embedded devices, The Vast Open Network, etc.
Are there any models/designs for a totally distributed operating system, possibly utilizing AI to learn patterns of use, resource need, and anything else that might be relevant?
First, you should be clear on what you mean by operating system, or rather, what level of design you are interested in. There is the sense of "OS design" which is embodied by most good university OS classes, and books like Tanenbaum's _Modern Operating Systems_. I.e. there are many nitty-gritty primitives that a given distributed operating system requires depending on its goals. E.g. distributed deadlock detection/avoidance, many of Leslie Lamport's contributions (including his seminal Distributed Clocks work), etc.
At a larger scale, and as others have rightly mentioned, Plan 9 is one of the first major rethinks of fundamental OS design policies and goals. Unix has at its roots assumptions buried in a single large timesharing/batch system, with networking and thus distributed behavior stapled on afterwards. To whet your appetite, the X Window System is fundamentally irrelevant in the Plan 9 environment, except for legacy code. It is safe to say that the Plan 9 papers are required reading for your goals. Note that this really doesn't get into kernel level design -- the Bell Labs team freely admits that the kernel (at least pre-Brazil) was fairly conventional in design.
Last but not least, don't fall into the trap of a Solution looking for a Problem. Don't try to use "AI" (no offense, but whatever the heck you mean by that -- it's so overbroad as be like saying "I'll solve it with Science!") when you don't even have a specific problem in the domain of distributed computing identified. Understand the real problems, which I'm guessing in your case are large-scale systems design and usability issues... THEN look for appropriate solutions.
FYI, Compact Flash writes are slower than molasses in January. CF has approx. 60ms (yes _milliseconds_) per 512 byte block write latency. The napkin calculation indicates that at 5:1 compression (assuming 640x480x24bit raw) you're looking at over 20 seconds to save an image down from RAM to flash. This can be a serious impact to the design of an embedded system (such as a digital camera). Yes, you can cache images to RAM (as you must for the image compression) but the more RAM you have (i.e. more snaps before writedown) the greater the cost and shorter the battery life.
FWIW, Memory Stick has much higher write bandwidth than CF... unfortunately I don't have the figures on me at the moment.
Given the Mac's traditional markets, there are a lot of content developers (esp. audio folks) who've been screaming for a full-powered computer with NO FAN! Kudos to Apple for reducing our ambient noise levels.
The Computers-For-Everyone-Else Rationale:
As a technological device's market matures, you find differentiation not so much in its bells and whistles, but in fit-and-finish details. Design, design design. Which watch looks better on your wrist? They all keep time well enough... Apple has made a computer that has a little tech-sex appeal, as it were. <sarcasm>Ooh, the horror, it's small, quiet, and pretty -- how ever will the big beige box motherboard-o'-the-month crowd cope?</sarcasm>
Slashdot Mirror
Actually, you are completely wrong. True, some people who are called "mad" are not "mad" by any known objective metric, but diseases which induce "madness" via neurochemical imbalance are well documented. If your body has issues with how certain neurotransmitters are either generated or used, causing an imbalance, it can make the brain run seriously out-of-spec. E.g. it's been found that manic depressives have very high levels of seratonin during the manic ("happy") phase, but very low levels during a depressive phase. There's tons of info on the web about this: search for schizophrenia, depression, obsessive-compulsive disorder, and related info on neurotransmitters, etc.
You've got a political-correctness-of-conformity issue, which you are wrongly using to ignore valuable medical science. This is especially bad when the medical viewpoint is far more compassionate and humanitarian than, for example, the historical view of the medically "mad" as "posessed by satan," with the horrible treatments that endengered.
I'll chime in to concur with the above assessment: it's fairly easy to take your home directory and any special system config files and scripts you have from one distro to another.
/home on it. (If /home has its own partition, this becomes _really_ easy.) I've done just this conversion to change a RedHat system to a Debian system, with a minimum of fuss. You can even keep a non-tar/gz copy of your important /etc config files in your home directory for easy access during the reinstall.
If you are careful, you can always just mkfs over partitions that are distro-specific, making sure to preserve the partition with
You are assuming hydrogen combustion. The much more interesting work in that regard is on hydrogen fuel cells, which produce electricity from hydrogen and oxygen from the air via catalytic reaction. From what I've read, they are extremely clean, nearly distilled-grade water as the exhaust. "mmm thirsty, need to drive somewhere..." 8-)
The problem in question is that your instructor(s) had no idea how OO should be taught. Even if one can program in an OO style, an instructor used to teaching old-school structured or modular style often results in a machine that makes broken students.
It's nigh-impossible to express "the right way" in a /. comment, but I'll point out that Brown University (formerly using OO Pascal/Delphi, now Java) and Virginia Tech have excellent programs that do OO from the first day. They aren't the only programs that do it right, either. It's a matter of OO requiring a very different teaching style. Brown's old book (Object-Oriented Programming in Pascal, A Graphical Approach, by Conner, van Dam, and Niguidula) didn't hit control structures until chapter 10 or so. Earlier chapters dealt with OO conceptual fundamentals, including non-programming modelling exercises (think in objects), object instantiation, method invocation, composition, and inheritance. Sounds rough? Nope, it's natural as water in the way and order they teach it.
OTOH, I don't buy the magic self-programming computer. This sort of prognostication is much like the now-laughable predictions in the early 1950's by an MIT professor that "I think that within five years we will have computers that can think."
That is, the problem of "programming" the computer via natural language is so vast as to be nearly equivalent to the (now somewhat discredited) goal of "classic" AI to put a brain in a box (or rather, create a non-embodied AI). Why? Because "natural language" lacks precision and information. Anyone who's had to reconcile marketing "requirements" with engineering reality will realize the incredible disjoint here. In its most general form, you are creating a programmer AI who:
No, I believe that highly skilled humans will always remain a part of the "programming" process even in the distant future (unless/until the very notion of "human" itself is challenged, ala some Brin short stories in Otherness.) As knowledge and technology improve, the capabilities of end-users will increase... as will the capabilities of the highly skilled software creators. Such "programmers" will be empowered by ever more sophisticated knowledge of software architecture, HCI, algorithmics, and lessons of history... along with some powerful software tools. But in the end, it will be humans using tools to craft things that have value to the human experience.
Others have rightly mentioned the flaw in trusting the client side to accurately report your own critical data back to you. This is the technical flaw, but not the root cause. This situation is a prime example of the business risk of employing an underqualified software development staff. (N.B. this could be direct employment, or "employment" via your purchasing department). A lead developer (or preferable, software architect) who analyzed and understood the problem domain (an online shop) separately from the machine (i.e. program) that implements the soltion, would not have exposed this obvious security risk.
Just how often does a painter immersed in the creative act stop to think about minutiae of the paintbrush? Or worse still, get interrupted by the paintbrush? Not often, and that's a hallmark of a good tool -- that it be subsumed as completely as possible beneath the user's attention to the task. The PC as we know it can undergo vast improvement towards being a really great tool for a particular task -- and this will likely involve some specialization. Again, read the above books and get a leg up on the next wave...
Others have rightly pointed out "find a bug and fix it". I'll weaken this a little: find a bug and identify it. To start, you needn't even find the "correct" fix -- for some problems this can be hard to do, especially if you are inexperienced and didn't architect the code in the first place.
It is *VERY* important to your development as a programmer to get involved with sophisticated code that someone else has written. You'll see good code, bad code, ugly code, and learn to tell the difference between them. This will improve your own coding styles. You'll learn about various coding techniques, data structures, etc. in something resembling a real application.
[rant about deluge of unmotivated "I just want a job" students in CS academia deleted for brevity.]
*WHAP!* *BIFF!*... goes the clue-by-four.
Perhaps the entire SECTION of the article "Sony's next Trinitron?" flew completely under your radar? The article explicitly discusses application across a wide range of display sizes and markets.
Moreover, if you had the slightest clue about the currently available display technologies they mention (LCD variants, DLP, etc.) the application of GLV is obvious -- to either front or rear projection displays. See Samsung's line of projection TVs (PLK405W, plus their entire HDTV line) which includes both tabletop sets and floorstanding projection TVs. See every DLP projector out there.
Personally, I find this fascinating. GLV's use of laser-scanning instead of the conventional (consumable and expensive) projection bulbs may turn out to be a big win for Sony vs. other technologies. I'll be interested to see relative power-consumption and efficiency figures for comparable DLV and {LCD,DLP,etc.} projectors.
- Flash memory is getting rapidly larger, cheaper, faster just like all other memory. Sony has announced a 1GB Memory Stick due 3-4Q 2001, and Hitachi has 2GB flash (in chip and one of the major flash formats, maybe SmartMedia) due in around the same timeframe.
- In a few years it will see serious competition from MRAM (Magnetic RAM) technologies hitting the market. MRAM will provide a combination of low power drain, high speed, and high capacity (relative to DRAM) in addition to being non-volatile. It may well obsolete both DRAM and Flash.
Short form: unless IBM has some simply amazing ultraminiature hard drive voodoo in the research pipeline, the solid state technologies are likely to be total design wins starting late next year.We need a /. poll:
Did you "hold out" knolwedge of the XFree86 4 debs until you'd downloaded yours?
( ) Yes, bwahaha.
( ) No
( ) First post!
( ) What's a deb?
That said, it is generally the case that "pre-echo is bad" and "over-ring is bad." Reducing these can be thought of as a good thing. Let's assume that for these encoders, pre-echo and over-ring are universally bad (I'll give an example where this isn't the case, below). Furthermore, this comparison actually says nothing about these encoders other than the pre-echo or over-ring. I.e. what happened to the sound that was the "same" on the sonogram? It is quite possible for an "encoder" to mangle the audio quality yet have a pristine sonogram by this test's standards.
Just to throw a wrench in the works, more advanced encoders and/or psychoacoustic models can utilize what's called temporal masking. This is the ability of a higher-amplitude signal to mask (make inaudible) a lower-amplitude signal either before or after itself, as far as the human ear is concerned. Pre-echo is the phenomenon whereby a transient signal (i.e. a very 'sudden' attack, like a drum hit) is smeared in time. The audible effect can be most obnoxious. Yet encoders utilizing temporal masking will explicitly allow a certain amount of pre-echo through, as long as it is temporally masked. This leaves the encoder to spend those bits on other parts of the signal that would be more seriously degraded as far as our ear is concerned. In short, a sufficiently savvy encoder could exhibit more pre-echo than another worse-sounding encoder, especially if it uses temporal masking.
Quantitative analysis for perceptual audio coding is not easy; this has been a grail for researchers in the field for years. I strongly suggest that interested parties dig into various IEEE and AES (Audio Engineering Society) journal papers on the subject, as well as various books, etc.
E.g. journalling filesystems such as XFS perform the same constant-time check routine every time they start, to inspect and clean up the journal (and commit transactions, if necessary) in case we crashed last time. The journal may not be complete, and some modest amount of data may have been lost, but the filesystem is not corrupt.
On a daily basis, the RAID cache is synched back to WORM. At any time, a user of the system can just cd to the fileserver's state for that day and inspect those files. E.g.
When they had the WORM (hmm.. might have been MO, don't have the paper handy) juke upgraded, the team noted that the capacity of the jukebox was expanding faster than they were using it, even with the system state snapshots. 8-)
[Ob. Actual Content:] Here's a couple of examples of this tech's use:
- Security Physical system security needs may make it desirable to not have the CPU case located with the user station.
- Noise Disk and fan noise suck, especially for professional/project music studios, or even for general working environments.
Note that X/M$ Terminal Server/etc. aren't applicable for the uses of a KVM! All such solutions require a system (even if only a thin client) at the user location -- and none work well (or at all) in a multi-platform environment.There is not only the concern of Brooks' Law, but also competence for the work requested. It is important to consider the level of work you will be asking of the overseas group vs. their actual skills. Are you providing gorily detailed project specifications or just a set of general requirements?
In my experience with one such situation, the group was pretty good at turning the crank when provided with sufficient information, but abysmal when faced with a 'blank page situation'. I.e. they could do raw implementation or extend an existing design, but possessed no design skills.
... and on a somewhat offtopic note, consider the 5-rated (!!) troll who wrote:
What a truly astonishing lack of clue about the FSF and its goals.Some facts:
- No game consoles are open development platforms. You must be licensed by the console manufacturer to produce titles for that box.
- Japanese corporate business practices, for all you decry
Microsoft's foul play, makes MS look like flowers and
sunshine. Japanese corps, Sony no exception, can be
ruthlessly anti-competitive ESPECIALLY to foreign
competition.
Now if you put #1 and #2 together, you may start to appreciate why U.S. game developers are heralding the arrival of the X-Box. They've been in an anti-competitive situation for many years now, with the U.S. console market dominated by Japanese corporations. Game developers finally have a modern U.S. console to target, without the competitive problems they've been suffering.What it comes down to is that Microsoft's presence in this market is out-and-out good news for U.S. game developers. Period. That fact alone will change the nature of titles available for X-Box (and possibly PS2, through competition).
You assume that the Asker is seeking to distribute the work of one program. Perhaps the real goal is to create a single seamless computing environment out of a widely differing (aka heterogeneous) collection of computing devices. User terminals, compute servers, data servers, embedded devices, The Vast Open Network, etc.
At a larger scale, and as others have rightly mentioned, Plan 9 is one of the first major rethinks of fundamental OS design policies and goals. Unix has at its roots assumptions buried in a single large timesharing/batch system, with networking and thus distributed behavior stapled on afterwards. To whet your appetite, the X Window System is fundamentally irrelevant in the Plan 9 environment, except for legacy code. It is safe to say that the Plan 9 papers are required reading for your goals. Note that this really doesn't get into kernel level design -- the Bell Labs team freely admits that the kernel (at least pre-Brazil) was fairly conventional in design.
Last but not least, don't fall into the trap of a Solution looking for a Problem. Don't try to use "AI" (no offense, but whatever the heck you mean by that -- it's so overbroad as be like saying "I'll solve it with Science!") when you don't even have a specific problem in the domain of distributed computing identified. Understand the real problems, which I'm guessing in your case are large-scale systems design and usability issues... THEN look for appropriate solutions.
Good luck!
FYI, Compact Flash writes are slower than molasses in January. CF has approx. 60ms (yes _milliseconds_) per 512 byte block write latency. The napkin calculation indicates that at 5:1 compression (assuming 640x480x24bit raw) you're looking at over 20 seconds to save an image down from RAM to flash. This can be a serious impact to the design of an embedded system (such as a digital camera). Yes, you can cache images to RAM (as you must for the image compression) but the more RAM you have (i.e. more snaps before writedown) the greater the cost and shorter the battery life.
FWIW, Memory Stick has much higher write bandwidth than CF... unfortunately I don't have the figures on me at the moment.
Given the Mac's traditional markets, there are a lot of content developers (esp. audio folks) who've been screaming for a full-powered computer with NO FAN! Kudos to Apple for reducing our ambient noise levels.
The Computers-For-Everyone-Else Rationale:
As a technological device's market matures, you find differentiation not so much in its bells and whistles, but in fit-and-finish details. Design, design design. Which watch looks better on your wrist? They all keep time well enough... Apple has made a computer that has a little tech-sex appeal, as it were. <sarcasm>Ooh, the horror, it's small, quiet, and pretty -- how ever will the big beige box motherboard-o'-the-month crowd cope?</sarcasm>