NO, NO, NO! As someone who works in the consumer digital media industry, this is not the right idea. The B2B (that's business-to-business) companies, e.g. Transmeta and many others, who produce hardware, firmware, and software support are bound to do what their customers (consumer electronics companies) want them to produce. If they don't, someone else gets the contract, period. The failure of Transmeta or TI or ARM does *nothing* to stop DRM. But there is a means that will work:
Boycott end-user products that use unacceptable DRM technologies. A few good market failures will send a loud message to the CE companies that no one wants DRM products. They stop asking for it, and companies like Transmeta will be more than happy to no longer waste development effort on a feature their customers will no longer pay for. Then the CE and the B2B hardware companies become your allies in the fight against DRM -- because you've taught them that to do otherwise limits their bottom lines.
This sounds to me like another bogus patent. If something is very easy to re-invent independently, it shouldn't be patentable. I thought patents were supposed to be non-obvious.
Ob. Disclaimer: I am quite opposed to current patent law and its application in practice. That said, I feel the need to provide an alternative view to your knee-jerk rewriting of recent technological history.
Unistrokes was quite non-obvious when no one had actually done it yet. The entire field of handwriting recognition was relatively new. While many so-called "innovations" really do fail the non-obviousness test, this simply wasn't one of them. In this case, 20-20 hindsight blinds you to the novelty of the idea *before anyone had thought of it*. (Think about the design of the paperclip for a moment, if you don't get this.) Moreover, Xerox didn't just think of it, they researched the idea to show that their design actually made sense from an CHI perspective. Their work was quite innovative in that era's handwriting recognition research.
I have a hard time believing that the Graffiti devleopers didn't know about Unistrokes. Published work on Unistrokes was readily available in conferences, journals, and online. Anyone doing even a minimal literature dive for handwriting recognition technology would have found the papers. Even if the work was independent and/or prior, there's at least some technical guilt for re-inventing a well-known solution. MS gets bashed for not-invented-here syndrome all the time -- why not Palm?
And remember -- half or more of the battle is in seeing past the now and into that first great idea. That this idea is amenable to a straightforward implementation is a *feature*, since it was aimed at low-power embedded devices.
You stipulate that Graffiti was "re-invent[ed] independently". Do you have any basis in fact for this statement, or are you just defending your vision of Palm as The Innocent Victim?
I mean, it's a little bit more complicated than using XOR to draw a cursor, but not that much.
You are clearly ready for the marketing department. "Oh, that's trivial! The engineering teams can do it in an hour or two, I'm sure!" The innovation here is NOT algorithmic, but rather in the design concept and how it dovetails with a user-interaction model and an efficient implementation.
It torques me off that "human-computer interfaces" is used to mean "displays". Propagation of a bad meme. Don't get me wrong; technology improvement can be useful. But far and away the greatest challenge and opportunity for improvement of the user experience is to improve the design and usability of consumer electronics.
There are many current and old examples showing that good design can work with here-and-now technology quite well. Bad design will take that 39-cent display with SuperDuper-VGA resolution and turn it into a glossy usability nightmare.
Good business sense. Instead of maintaining the whole OS, SGI (and other companies) can meet their requirements in the Linux kernel environment, focusing only on the value they need to add to the system. Who wants to reinvent all the old-hat stuff like driver or filesystem interfaces, anyways?
Good business sense. Very few companies except Microsoft make money from an Operating System. Rewriting an OS from scratch is a huge business risk and cash investment unless you're into very specialized hard-core OS R&D work. See Plan 9 and EROS for examples of, IMO, well-founded OS projects that started from scratch.
Recall that SGI is a platform vendor. You buy a package of hardware and software from them. If their software costs are lower, that translates directly into higher margins. Apple made a similar "don't reinvent the wheel" decision in the choices that led to MacOS X, which left them time to focus on their true focus of applications and system usability.
Good business sense.With large development projects, it's useful to spread the development cost across a large population of developer-users. I.e. this is a driving motivation behind collaborative open source development. Only now it's happening at the corporate level instead of the level of the individual developer.
It's not clear what feedback technology this company is using, but a fantastic SIGCHI 2001 poster presentation by an NTT researcher showed how this problem can be solved -- and cheaply at that.
The gist is that piezo "thumper" or a stock tiny portable speaker can be programmed to emit low-frequency vibrations when a key is pressed. Not only does this provide very nifty positive feedback from a touchscreen surface, but the feel itself is programmable. E.g. the demo hardware was an all-LCD desk calculator where the buttons were done as soft keys. The clear button had a tactile sensation distinct from the feedback given by the other buttons. I'm eagerly awaiting this tech to propagate into production devices...
None of the links on the/. page or OSDL seem to indicate that the database is IBM's software, just that they're providing the bug database admin labor. Where did you read that IBM's proprietary DB software is being used?
Even if your statement is true, perhaps part of IBM's return on investment is a real-world application study with this bug-tracker as a test case?
I'm running 10.1 on my Powerbook G3/400 (Lombard), and it runs fine. A co-worker with the same model Powerbook has 10.2 and praised the overall performance boost it gave his system.
For comparison, 10.1 is much faster than the Debian installation I had on the same system.
Details for the terminally bored: Linux was slow enough that I rarely bothered to boot into it. FWIW, I've heard that the Linux performance issues were largely X and/or driver related. I've used and enjoyed Linux systems at work and at home, but this experience was at best a 'D-' on Linux's platform support report card, IMO.
"Let's hope this technology does not come to fruition."
Urgh, get me a bucket! I'm gonna spew!
"No place to do anything."
What a whiner. I so hate having to debunk upmodded trolls. Sigh.
First try, reductio ad sarcasium:
Indeed! No place to upload new firmware, applications, or content. We don't even have to bother with the circuity in this model! We can just paint the glass! BWAHAHAHAHAHA!! It's _completely secure_! Fooled those silly customers, didn't we now!
Second try, a more serious approach:
This is no different than a large variety of new printable circuit technologies on the horizon. (E.g. printable on plastic, woven/printed into cloth, etc.) ALL OF THEM WILL EVENTUALLY COME TO PASS. Just like current implementation technologies, none of these have any instrinsic connection to DRM.
Listen up: the feature sets and marketing profiles of products are determined by what customers will buy, or by what companies guess customers will buy. If customers continue to value of a product market without DRM, then products without DRM will continue to be sold. If customers never value DRM, eventually markets will learn.
Yes, despite the diligence of those in the know, we may enter a Prohibition like phase regarding IP rights here in the U.S. We may already be there. Yes that sucks. But I believe that continued diligence and basic economic forces will eventually roll over all of that like so many other times that "progress" went burp! in world history. At least we don't have to deal with the Black Plague.
Moreover, your position holds powerlessness and fear as its fundamental assumptions. How can you stand to think that way? You've already lost!
The implied complaint in many comments thus far can be summed up as follows:
Will a compatible computer media drive, with no "rights" restrictions, be available for either format?
IMO, it's highly doubtful this would occur in the current climate. Ironically, the audio industry could probably greatly assist the success of one or both formats if it were to enable computer drives compatible with DVD-A and/or SACD.
No human could hear 100kHz frequencies, even at ear-splitting dynamic ranges over 120dB,
Not this noise again! The point of having higher resolution is NOT for your freaking pet bat. There are two primary reasons that improved fidelity may result. Both of these reasons relate to various characteristics of the high resolution formats, either Sony's DSD or 96kHz/24-bit PCM on DVD audio. (FYI, DSD == Direct Stream Digital, the moniker for the SACD modulation format, which is different from PCM digital audio.)
Recording, production, and mastering processes can be made easier due to the increased dynamic range and headroom. E.g. the recording engineer has lots of room to play with record level settings, without having to be neurotic about that last few dB of gain to get maximum dynamic range in the recording. Production and mastering have more numerical headroom for mixing, effects, etc. It's also easier to avoid audibility of certain aliasing artifacts in processing passes due to the increased sampling rate. (Note: the above loosely applies to PCM, and loosely to DSD, but at least a few years ago, there were some major issues with the computational requirements for signal processing in the DSD domain. That and many DSP algorithms would essentially have to be mathematically reformulated for DSD. I'm out of touch with current practices with DSD.)
Design benefits in the signal reproduction hardware that improve fidelity due to eliminating introduced artifacts in signal reconstruction. E.g. as regards CD audio vs. 96/24 audio, it's easier to design the DAC's brickwall filters for 96/24. With 44.1/16, the task is harder, and the filter is more likely to introduce distortion into the audible band. Sony had/has whole web pages and/or PDFs describing similar design principles driving the design of the DSD format.
More info is available via Google and/or Google Groups on the rec.audio.* groups.
Note: none of the above speaks to the critical questions of marketability: is it worth it to the end consumer? What does the consumer gain? What does the consumer lose?
I don't think the two will be the same, and I don't see why one should suffer with a lesser interface based on limitations he/she doesn't have.
As it happens, the closing plenary by Gregg Vanderheiden at the ACM CHI 2001 conference nicely debunked this commonly held viewpoint. In so many cases, devices can be made *more* useful to the fully-abled as well as accessible to segments of the disabled. Here's a page with audio links, slides, and a transcript of one of Dr. Vanderheiden's talks on the accessibility subject.
IMO, Vanderheiden's closing plenary completely blew away the opening plenary by Bill Gates. Gates likes to present a public image of himself as a technology visionary. These two talks were a fantastic case study on how self-marketing cannot compete with actual substance when vyying for the visionary title.
While I can't speak to the original posters admission problems, there are *serious* problems within many graduate programs that are pretty much in-line with the poster's gripes. To wit: many departments (and not just in CS) have in circles of foreign students who keep test libraries and who coach students in their sub-community not to learn the material but to just pass the tests. A similar pheomenon is observed at the undergrad level, but usually driven by greek organizations, in my experience. In many cases, faculty are either oblivious to the problem or don't have the time or teaching skill to "immunize" their evaluation metholodogy against this sort of attack.
Short form: honest and hardworking students get screwed in their grades, while know-nothing slackers sail on by... Personally, I don't care if the system allows some slackers -- some will squeak through. I am bothered when they mass in such numbers that the real talent is trampled underfoot.
At last, someone with the right idea. The embedded digital audio space is a volatile new market, with a bunch of relatively young companies and/or young divisions within large companies (which is much the same thing for my purposes here) vying for marketshare. Feature sets end up being defined in two general ways: 1) via feedback about a shipping product (market success or failure, direct user feedback, etc), or 2) marketing gets the idea that customers Must Have This Feature. User feedback can make a difference in this latter model.
Ogg isn't yet big enough on its own to be an automatic target for these electronics marketing divisions. It needs grassroots backing to give it the same boost that MP3's mindshare and Micosoft's market power (WMA) have done for those formats already.
This codebase makes this grassroots effort VERY VIABLE. So write your favorite digital audio portable company (be brief -- you're talking to marketing) and ask for Ogg Vorbis support. FWIW, Apple's design prowess made big waves in this industry. If Apple adds Ogg it, it's very likely that it will become a bullet on everyone else's next product feature list. (Note: the iPod uses an ARM-based processor.)
Full listening tests to evaluate codec quality or perform a comparison are quite laborious and expensive to run. They are done very rarely. The implied "they" in your note -- "They" who should conduct the listening tests -- is also left undefined. Xiph almost certainly doesn't have the resources to run such a test series. If not Xiph, then who else has the financial motive if the result is, in practice, good enough?
Moreover, your complaint should enompass more than Ogg: few if any shipping MP3 encoders or decoders have actually been run through listening tests to create a baseline comparison with the tested MP3 reference codebase. Virtually all of them have tweaks, refinements, optimizations, etc. that affect the resulting output and quality.
Excellent points. In this sense, a BSD-like license seems to be more appropriate than GPL/LGPL where the promotion of an open software-based standard is more important than any single codebase that implements that standard.
I'm a firmware engineer in this market, and this definitely lowers the barrier to entry for companies who would previously have had to implement a custom Ogg Vorbis codec. Such a project would have been very expensive to undertake, probably prohibitively so. (both in the development cost and in the lead times to a QA'ed and marketable finished product.)
Fallacy alert! Fallacy alert!: I mean, legally, I have to side with the companies. Their machines, their time, their liability. [They] can do what they want.
I don't buy this. My reasons are:
Legal-oriented thought tends towards viewing the sets of ethical, moral, and legal as being identical. Or rather, that all behavior is collapsed to "if it's legal, then it's O.K." Anyone who remembers the drivel spewed by the First Great Spammers, Cantor and Siegel, the infamous "Green Card Lawyers" could see a prime example of this type of thought.
A more mature mindset recognizes that legal vs. ethical vs. (e.g.) balanced compassion are progresively "smaller" behavioral sets. Point: just because a practice is legal doesn't mean that it's even remotely acceptable! Examnple: Say that someone spams half the Internet, then a law is passed that makes spamming illegal for that individual, then they spam again. The law doesn't change the fact that this individual was a thoughtless jerk even before the law was passed!
Despite the above ideas, some people and organizations will continue to suck. This is one reason for laws to exist: to create boundaries of extreme behavior beyond which society will no longer tolerate those actions. Companies must not continue to confuse the real need for employee performance, responsibility, and accountability with a control-freakish need to survey every aspect of a worker's life. If this trend goes too far, and it probably already has, then it's a definite call for improved privacy laws.
For me, the most nostalgic thing about the old 'net was the sense of net community. This was a feature imparted by the very small population and the very age/academia/gov't skewed user demographics at the time. I.e. a bunch of geeks noodling around online.
As universities started to open access to undergrads, the September Effect (cf. the Jargon File) came into play... which was still okay while the numbers were such that older netizens could impart netiquette to the newbies. Later, the online population explosion really started to ramp, perhaps marked by the Neverending September of AOL.
Today's Internet is a very different place socially, characterized more by microcommunities. These, ironically, were enabled by the very same massive population that engulfed the old 'net community.
It's all just been one big lesson in eternal change, AFAIC.
Re:"Reduced" Instruction Set Computer???
on
PowerPC Goes 64 bit
·
· Score: 2
In practice, it is useful to define a set of conventions so that binary objects can interoperate with different compilers and pre-written assembly code.
As a point of general information: These conventions are referred to as a platform's ABI, or Application Binary Interface. The ABI sets the necessary register use (e.g. stack/frame pointer policy), parameter passing (in registers/on stack), and function calling conventions for a given hardware platform. This is typically C/C++ centric. FWIW, compilers which don't depend on C/C++ link level compatibility need only obey the ABI when calling external code.
No, this isn't loop unrolling at all. This library (and not the compiler, note) is using this scheme to maintain cache-locality. A general rule of optimization is to agressively utilize the memory heirarchy, be it at the L1/L2 cache level, VM, etc. This means maintaining good data-locality in the algorithm's access patterns at the relevant scales (i.e. cache, VM pages, etc). Failure to manage this (for this example) means a performance hit due to greatly increased cache misses, often in the form of unecessary loading, dirtying, flushing, reloading and redirtying cache lines continuously during the course of processing. Ideally, one wants to load the cache line once, do all work in the cache, then flush/write back and move on to other data.
This principle can be seen in how the GIMP stores image data in tiles data for rapid processing, in matrix math libraries, in the design of FFTW (The Fastest Fourier Transform in the West, www.fftw.org), and many other systems.
As far as arcade games go, Atari has always produced my favorites.
From the vector classics such as Tempest and BattleZone (dating myself), to Hard Drivin'/Race Drivin' (the first great driving simulators, IMO), Steel Talons (helicopter simulator), STUN Runner (I *so* want a Shockwave on the freeway sometimes), and the Rush series (San Franciso Rush, Rush 2049)... all have had fantastic game play. Heck, after too much Race Drivin', I finally couldn't play driving games without good force feedback. How else do you know when the wheels are on the edge of losing grip? 8-)
What-ever. If we're going to issue over something, then let's talk about the short- and long-term ramifications of externalized costs due to industrial pollution, automobiles, environmental mismanagement, bad/corrupt urban planning, and similar factors that have been with us for far, far longer than the measly few decades software developers have been doing their worst. No matter how bad your office productivity suite is, it probably won't give you asthma or lung cancer.
Say what?!? Reinventing and/or reimplementing error-prone RTOS functionality and primitives (semaphores, queueing, resource locks, multi-level queue scheduler (or the few other popular variants thereof) makes no business sense for most companies.
Specifically: RTOS writing is a cost-center (as opposed to a profit-center) for most organizations. The great thing about eCos was its promise to help distribute this cost center across many organizations that need a lightweight small-footprint RTOS for their application. RedHat's service0based business model was appealing, also. Service and/or modification contracts were substantially cheaper than most proprietary RTOS upfront, per-unit, or ongoing licensing fees. Heck, OSes in general are cost centers for everyone except MS (possibly for RedHat, depending on how you view their business model). Moreover, few developers really understand how to competently code even a basic RTOS these days. Once an RTOS has been produced in-house, it will have to be maintained by at least one developer, with a backup maintainer on-hand for safety. I know of lots of organizations where the firmware team is only 2-5 people, who get "graded" by how quickly they complete the whole application, not on how much time they spent writing boring infrastructure code. Still, RTOS writing does make sense for a few companies, especially ones with a larger firmware staff and unique needs.
So what happened with eCos? Because corporations looking for a product platform RTOS choice often seek a few things 1) a known, supported, stable OS platform which 2) has a body (in house or in the marketplace) of knowledgable developers available. To be specific, Linux itself has whomped eCos. Despite the economies that can be had by lightweight firmware architecture designs (in the bill of materials for req'd hardware, etc)... many large companies seek out OSes for which their staff has prior experience, and/or which meet a corporate safety objective. Particularly in Japan, Linux is becoming an embedded imperative. RedHat's move is simply responding to percieved (and quite real) demand in the marketplace for 'real' embedded Linux.
So remember kiddies: Plenty of RAM and an MMU are your friends! 8-)
Slashdot Mirror
Boycott any hardware that supports "DRM"
NO, NO, NO! As someone who works in the consumer digital media industry, this is not the right idea. The B2B (that's business-to-business) companies, e.g. Transmeta and many others, who produce hardware, firmware, and software support are bound to do what their customers (consumer electronics companies) want them to produce. If they don't, someone else gets the contract, period. The failure of Transmeta or TI or ARM does *nothing* to stop DRM. But there is a means that will work:
Boycott end-user products that use unacceptable DRM technologies. A few good market failures will send a loud message to the CE companies that no one wants DRM products. They stop asking for it, and companies like Transmeta will be more than happy to no longer waste development effort on a feature their customers will no longer pay for. Then the CE and the B2B hardware companies become your allies in the fight against DRM -- because you've taught them that to do otherwise limits their bottom lines.
This sounds to me like another bogus patent. If something is very easy to re-invent independently, it shouldn't be patentable. I thought patents were supposed to be non-obvious.
Ob. Disclaimer: I am quite opposed to current patent law and its application in practice. That said, I feel the need to provide an alternative view to your knee-jerk rewriting of recent technological history.
Unistrokes was quite non-obvious when no one had actually done it yet. The entire field of handwriting recognition was relatively new. While many so-called "innovations" really do fail the non-obviousness test, this simply wasn't one of them. In this case, 20-20 hindsight blinds you to the novelty of the idea *before anyone had thought of it*. (Think about the design of the paperclip for a moment, if you don't get this.) Moreover, Xerox didn't just think of it, they researched the idea to show that their design actually made sense from an CHI perspective. Their work was quite innovative in that era's handwriting recognition research.
I have a hard time believing that the Graffiti devleopers didn't know about Unistrokes.
Published work on Unistrokes was readily available in conferences, journals, and online. Anyone doing even a minimal literature dive for handwriting recognition technology would have found the papers. Even if the work was independent and/or prior, there's at least some technical guilt for re-inventing a well-known solution. MS gets bashed for not-invented-here syndrome all the time -- why not Palm?
And remember -- half or more of the battle is in seeing past the now and into that first great idea. That this idea is amenable to a straightforward implementation is a *feature*, since it was aimed at low-power embedded devices.
You stipulate that Graffiti was "re-invent[ed] independently". Do you have any basis in fact for this statement, or are you just defending your vision of Palm as The Innocent Victim?
I mean, it's a little bit more complicated than using XOR to draw a cursor, but not that much.
You are clearly ready for the marketing department. "Oh, that's trivial! The engineering teams can do it in an hour or two, I'm sure!" The innovation here is NOT algorithmic, but rather in the design concept and how it dovetails with a user-interaction model and an efficient implementation.
It torques me off that "human-computer interfaces" is used to mean "displays". Propagation of a bad meme. Don't get me wrong; technology improvement can be useful. But far and away the greatest challenge and opportunity for improvement of the user experience is to improve the design and usability of consumer electronics.
There are many current and old examples showing that good design can work with here-and-now technology quite well. Bad design will take that 39-cent display with SuperDuper-VGA resolution and turn it into a glossy usability nightmare.
Three reasons:
Recall that SGI is a platform vendor. You buy a package of hardware and software from them. If their software costs are lower, that translates directly into higher margins. Apple made a similar "don't reinvent the wheel" decision in the choices that led to MacOS X, which left them time to focus on their true focus of applications and system usability.
It's not clear what feedback technology this company is using, but a fantastic SIGCHI 2001 poster presentation by an NTT researcher showed how this problem can be solved -- and cheaply at that.
The gist is that piezo "thumper" or a stock tiny portable speaker can be programmed to emit low-frequency vibrations when a key is pressed. Not only does this provide very nifty positive feedback from a touchscreen surface, but the feel itself is programmable. E.g. the demo hardware was an all-LCD desk calculator where the buttons were done as soft keys. The clear button had a tactile sensation distinct from the feedback given by the other buttons. I'm eagerly awaiting this tech to propagate into production devices...
None of the links on the /. page or OSDL seem to indicate that the database is IBM's software, just that they're providing the bug database admin labor. Where did you read that IBM's proprietary DB software is being used?
Even if your statement is true, perhaps part of IBM's return on investment is a real-world application study with this bug-tracker as a test case?
I'm running 10.1 on my Powerbook G3/400 (Lombard), and it runs fine. A co-worker with the same model Powerbook has 10.2 and praised the overall performance boost it gave his system.
For comparison, 10.1 is much faster than the Debian installation I had on the same system.
Details for the terminally bored: Linux was slow enough that I rarely bothered to boot into it. FWIW, I've heard that the Linux performance issues were largely X and/or driver related. I've used and enjoyed Linux systems at work and at home, but this experience was at best a 'D-' on Linux's platform support report card, IMO.
Urgh, get me a bucket! I'm gonna spew!
What a whiner. I so hate having to debunk upmodded trolls. Sigh.
First try, reductio ad sarcasium:
Indeed! No place to upload new firmware, applications, or content. We don't even have to bother with the circuity in this model! We can just paint the glass! BWAHAHAHAHAHA!! It's _completely secure_! Fooled those silly customers, didn't we now!
Second try, a more serious approach:
This is no different than a large variety of new printable circuit technologies on the horizon. (E.g. printable on plastic, woven/printed into cloth, etc.) ALL OF THEM WILL EVENTUALLY COME TO PASS. Just like current implementation technologies, none of these have any instrinsic connection to DRM.
Listen up: the feature sets and marketing profiles of products are determined by what customers will buy, or by what companies guess customers will buy. If customers continue to value of a product market without DRM, then products without DRM will continue to be sold. If customers never value DRM, eventually markets will learn.
Yes, despite the diligence of those in the know, we may enter a Prohibition like phase regarding IP rights here in the U.S. We may already be there. Yes that sucks. But I believe that continued diligence and basic economic forces will eventually roll over all of that like so many other times that "progress" went burp! in world history. At least we don't have to deal with the Black Plague.
Moreover, your position holds powerlessness and fear as its fundamental assumptions. How can you stand to think that way? You've already lost!
The implied complaint in many comments thus far can be summed up as follows:
Will a compatible computer media drive, with no "rights" restrictions, be available for either format?
IMO, it's highly doubtful this would occur in the current climate. Ironically, the audio industry could probably greatly assist the success of one or both formats if it were to enable computer drives compatible with DVD-A and/or SACD.
Not this noise again! The point of having higher resolution is NOT for your freaking pet bat. There are two primary reasons that improved fidelity may result. Both of these reasons relate to various characteristics of the high resolution formats, either Sony's DSD or 96kHz/24-bit PCM on DVD audio. (FYI, DSD == Direct Stream Digital, the moniker for the SACD modulation format, which is different from PCM digital audio.)
More info is available via Google and/or Google Groups on the rec.audio.* groups.
Note: none of the above speaks to the critical questions of marketability: is it worth it to the end consumer? What does the consumer gain? What does the consumer lose?
Ob. Jedi quip: "These are not the production droids you're looking for."
As it happens, the closing plenary by Gregg Vanderheiden at the ACM CHI 2001 conference nicely debunked this commonly held viewpoint. In so many cases, devices can be made *more* useful to the fully-abled as well as accessible to segments of the disabled. Here's a page with audio links, slides, and a transcript of one of Dr. Vanderheiden's talks on the accessibility subject.
Access to (all) Electronic Products by Everyone
IMO, Vanderheiden's closing plenary completely blew away the opening plenary by Bill Gates. Gates likes to present a public image of himself as a technology visionary. These two talks were a fantastic case study on how self-marketing cannot compete with actual substance when vyying for the visionary title.
While I can't speak to the original posters admission problems, there are *serious* problems within many graduate programs that are pretty much in-line with the poster's gripes. To wit: many departments (and not just in CS) have in circles of foreign students who keep test libraries and who coach students in their sub-community not to learn the material but to just pass the tests. A similar pheomenon is observed at the undergrad level, but usually driven by greek organizations, in my experience. In many cases, faculty are either oblivious to the problem or don't have the time or teaching skill to "immunize" their evaluation metholodogy against this sort of attack.
Short form: honest and hardworking students get screwed in their grades, while know-nothing slackers sail on by... Personally, I don't care if the system allows some slackers -- some will squeak through. I am bothered when they mass in such numbers that the real talent is trampled underfoot.
The Dilbert Principle lives... %-/
No, they just slide down the hill on their tummies... like Tux does.
At last, someone with the right idea. The embedded digital audio space is a volatile new market, with a bunch of relatively young companies and/or young divisions within large companies (which is much the same thing for my purposes here) vying for marketshare. Feature sets end up being defined in two general ways: 1) via feedback about a shipping product (market success or failure, direct user feedback, etc), or 2) marketing gets the idea that customers Must Have This Feature. User feedback can make a difference in this latter model.
Ogg isn't yet big enough on its own to be an automatic target for these electronics marketing divisions. It needs grassroots backing to give it the same boost that MP3's mindshare and Micosoft's market power (WMA) have done for those formats already.
This codebase makes this grassroots effort VERY VIABLE. So write your favorite digital audio portable company (be brief -- you're talking to marketing) and ask for Ogg Vorbis support. FWIW, Apple's design prowess made big waves in this industry. If Apple adds Ogg it, it's very likely that it will become a bullet on everyone else's next product feature list. (Note: the iPod uses an ARM-based processor.)
Full listening tests to evaluate codec quality or perform a comparison are quite laborious and expensive to run. They are done very rarely. The implied "they" in your note -- "They" who should conduct the listening tests -- is also left undefined. Xiph almost certainly doesn't have the resources to run such a test series. If not Xiph, then who else has the financial motive if the result is, in practice, good enough?
Moreover, your complaint should enompass more than Ogg: few if any shipping MP3 encoders or decoders have actually been run through listening tests to create a baseline comparison with the tested MP3 reference codebase. Virtually all of them have tweaks, refinements, optimizations, etc. that affect the resulting output and quality.
Excellent points. In this sense, a BSD-like license seems to be more appropriate than GPL/LGPL where the promotion of an open software-based standard is more important than any single codebase that implements that standard.
I'm a firmware engineer in this market, and this definitely lowers the barrier to entry for companies who would previously have had to implement a custom Ogg Vorbis codec. Such a project would have been very expensive to undertake, probably prohibitively so. (both in the development cost and in the lead times to a QA'ed and marketable finished product.)
I mean, legally, I have to side with the companies. Their machines, their time, their liability. [They] can do what they want.
I don't buy this. My reasons are:
True, True!
For me, the most nostalgic thing about the old 'net was the sense of net community. This was a feature imparted by the very small population and the very age/academia/gov't skewed user demographics at the time. I.e. a bunch of geeks noodling around online.
As universities started to open access to undergrads, the September Effect (cf. the Jargon File) came into play... which was still okay while the numbers were such that older netizens could impart netiquette to the newbies. Later, the online population explosion really started to ramp, perhaps marked by the Neverending September of AOL.
Today's Internet is a very different place socially, characterized more by microcommunities. These, ironically, were enabled by the very same massive population that engulfed the old 'net community.
It's all just been one big lesson in eternal change, AFAIC.
As a point of general information: These conventions are referred to as a platform's ABI, or Application Binary Interface. The ABI sets the necessary register use (e.g. stack/frame pointer policy), parameter passing (in registers/on stack), and function calling conventions for a given hardware platform. This is typically C/C++ centric. FWIW, compilers which don't depend on C/C++ link level compatibility need only obey the ABI when calling external code.
No, this isn't loop unrolling at all. This library (and not the compiler, note) is using this scheme to maintain cache-locality. A general rule of optimization is to agressively utilize the memory heirarchy, be it at the L1/L2 cache level, VM, etc. This means maintaining good data-locality in the algorithm's access patterns at the relevant scales (i.e. cache, VM pages, etc). Failure to manage this (for this example) means a performance hit due to greatly increased cache misses, often in the form of unecessary loading, dirtying, flushing, reloading and redirtying cache lines continuously during the course of processing. Ideally, one wants to load the cache line once, do all work in the cache, then flush/write back and move on to other data.
This principle can be seen in how the GIMP stores image data in tiles data for rapid processing, in matrix math libraries, in the design of FFTW (The Fastest Fourier Transform in the West, www.fftw.org), and many other systems.
As far as arcade games go, Atari has always produced my favorites.
From the vector classics such as Tempest and BattleZone (dating myself), to Hard Drivin'/Race Drivin' (the first great driving simulators, IMO), Steel Talons (helicopter simulator), STUN Runner (I *so* want a Shockwave on the freeway sometimes), and the Rush series (San Franciso Rush, Rush 2049)... all have had fantastic game play. Heck, after too much Race Drivin', I finally couldn't play driving games without good force feedback. How else do you know when the wheels are on the edge of losing grip? 8-)
What-ever. If we're going to issue over something, then let's talk about the short- and long-term ramifications of externalized costs due to industrial pollution, automobiles, environmental mismanagement, bad/corrupt urban planning, and similar factors that have been with us for far, far longer than the measly few decades software developers have been doing their worst. No matter how bad your office productivity suite is, it probably won't give you asthma or lung cancer.
Say what?!? Reinventing and/or reimplementing error-prone RTOS functionality and primitives (semaphores, queueing, resource locks, multi-level queue scheduler (or the few other popular variants thereof) makes no business sense for most companies.
Specifically: RTOS writing is a cost-center (as opposed to a profit-center) for most organizations. The great thing about eCos was its promise to help distribute this cost center across many organizations that need a lightweight small-footprint RTOS for their application. RedHat's service0based business model was appealing, also. Service and/or modification contracts were substantially cheaper than most proprietary RTOS upfront, per-unit, or ongoing licensing fees. Heck, OSes in general are cost centers for everyone except MS (possibly for RedHat, depending on how you view their business model). Moreover, few developers really understand how to competently code even a basic RTOS these days. Once an RTOS has been produced in-house, it will have to be maintained by at least one developer, with a backup maintainer on-hand for safety. I know of lots of organizations where the firmware team is only 2-5 people, who get "graded" by how quickly they complete the whole application, not on how much time they spent writing boring infrastructure code. Still, RTOS writing does make sense for a few companies, especially ones with a larger firmware staff and unique needs.
So what happened with eCos? Because corporations looking for a product platform RTOS choice often seek a few things 1) a known, supported, stable OS platform which 2) has a body (in house or in the marketplace) of knowledgable developers available. To be specific, Linux itself has whomped eCos. Despite the economies that can be had by lightweight firmware architecture designs (in the bill of materials for req'd hardware, etc)... many large companies seek out OSes for which their staff has prior experience, and/or which meet a corporate safety objective. Particularly in Japan, Linux is becoming an embedded imperative.
RedHat's move is simply responding to percieved (and quite real) demand in the marketplace for 'real' embedded Linux.
So remember kiddies: Plenty of RAM and an MMU are your friends! 8-)