Rather than being bothered to actually try and understand something you just shrug your shoulders and say "magic".
I've noted a similar trend along these lines amongst myself and other geek friends lately. When mulling some topic to which the answer is unknown to the group, someone will expound something like "Google knows" or "imdb knows". Instead of supersition, we now have specific cultural icons for "knowledge somewhere out there." 8-)
I have said that *1000* times and been moded a troll every last time
I don't know about the other times, but you're a troll now. The earlier poster described a situation in which a company has transitioned beyond the early adopter phase, and is selling products based on what he called "signs". I.e. Apple has transitioned to using the marketing tactics of a mature industry, not an early adopter industry. You, however go on to make inflammatory and content-free statements like "People who buy Apples are the same irrational fanboys [deletia]." Go log off, troll.
Folks looking for great information on market transitions and computing w/o the rant and religion should go read the first several chapters of Don Norman's "The Invisible Computer". You'll get some fascinating history of market evolutions, and analysis of the state of computing w.r.t. how earlier markets evolved from early adopter phases into maturity.
Just built up a new computer. The power supply worked once, then turned into a doorstop on the second cold boot. I think the company who made it was a little too agressive in their implementation of the OP spec. 8-)
Further complicating the problem is that even if someone were to develop an environment that attempted to prevent all of the problems caused by programmer errors, it would be horrendously complex and would likely kill performance.
IMO, a big part of the solution is factoring out solutions for major known security problem areas into the environments, languages, and frameworks that developers use on a day-to-day basis. E.g. if you're using a language with robust automatic memory management, there's little reason to go looking for C-style buffer overflow exploits coded by your developers.
In today's environments (e.g. Windows and current *nix systems) with current popular languages (e.g. C, C++) we're at a big disadvantage. Much of the discussion in this thread presumes that coders can/should amass total knowledge of all levels of security exploits, from binary code injection to cross-site scripting (aka CSS), SQL injection, etc. It becomes overwhelming to a dev who really should be able to focus on the value-added problems at hand. I'm aware of only one cost efficient approach: choose environments, languages, and/or tools that mitigate known security risks.
Where applicable, this can be done by leveraging environments that can limit the scope of attacks. See SELinux and GR Security for ways to patch Linux to meet thess needs, or the EROS project for a fresh view of OS security and compartmentalization models. Environment choise is most relevant to folks providing networked services, where they can control the platform specifics.
The cause can also be aided by using languages/frameworks that encapsulate security knowledge. This can be as "simple" as using a language with automatic memory management(to factor out common buffer overflow problems), or along the lines of using scripting frameworks that standardize policies for correctly managing more complex security issues (e.g. cookie management, web input/output validation, CSS issues, etc).
I'd argue that it is possible to improve software security practices significantly simply by careful choices of tools and techniques available today. But it takes a saavy organization to really commit to providing secure software solutions, and to be able to do so in a cost effective manner. As always, the hard part of the equation is programming the wetware. 8-)
Read the manga, from which the anime was derived. Judging Appleseed on the first anime version is like judging Frank Herbert's _Dune_ on David Lynch's 1984 movie.
The challenge that any attempt to realize Appleseed as anime faces is that the manga has a *lot* going on. Global politics, layers of social and racial turmoil, the affects of high technology on society (and vice versa), etc. With such a rich world and story line, creating a compelling version of that story in even one or two movie length features is very difficult.
Last but not least, if you want your notions of superhero comics turned on their head, go pick up one of the graphic novels from Kurt Busiek's _Astro City_ series. Great characters, detailed world, and compelling storytelling. Oh, yeah, and with superheroes. 8-)
Do you know if anyone has considered using wind or solar energy to power the ethanol producing equipment?
Speaking strictly in the context of this article, is there any evidence that this would improve the total energy storage yield over an approach like electrolysis using solar-generated electricity? If you really need a biological element, there were researchers working on improving the efficiency of a hydrogen-generating algae a while back, for another more direct approach to sun+water= hydrogen. Seems like the whole corn production and conversion to ethanol is rather roundabout.
Plasma still exists because it has one advantage over LCD/DLP in the price/performance war: Bigger direct-view screens that can be easily mounted on a wall.
This isn't a big advantage anymore. Sharp and a few other manufacturers have 30+" and 40+" direct-view widescreen LCD displays now. One new 45" Sharp display, subject of a recent announcement at CES, is a 1080p display! Units in the 32+" range I saw this weekend were priced in the ~$3300 USD range.
Perhaps it's time that computer science curriculums start teaching assembly language first.
Having taught an assembly/into computer arch class, I agree with the sentiment that students who get "under the hood" gain valuable knowledge and working skills. Not just pounding ASM, but in learning how the machine works. Point agreed.
Also having taught first year computer science students, and seen how some of academia's transitions in pedagogy affected students... I have to say that the idea of teaching first year students in assembly is friggin' daft.
My reasoning is the same as why I strongly advocated an objects-first teaching model. It is increasingly critical for students to build a strong sense of software design and abstraction early on. This foundation makes students much better prepared to solve problems of many different scales (asm to component-systems) in the long run.
There's evidence from a paper in one of the Empirical Studies of Programmers workshops that this approach does trade off design skills for purely algorithmic reasoning for students at the end of their first year. But my own experience, as well as that of some prominent Comp Sci Education (CSE) folks seems to indicate that this is far more than compensated for as a student's skills grow.
Here's my theory as to why this is the case: The details of debugging, alogrithmic thinking, and problem solving are very much skill building exercises that really require time of exposure to improve. But it is much more difficult in my experience for students to build good design sense on their own. Once the framework for thinking in terms of good abstractions is laid down, it provides much stronger support for later filling all of those gory low-level details.
Historical perspective: Ironically, this same reasoning is much of why I believe that academia's switch to C++ from languages like Pascal, Modula-2, etc. was an educational disaster for many years. The astute reader is now thinking: "hey, you just said you like objects-first; what up?" In the Procedural Era, many schools wouldn't expose students to C in the first year, as it had too many pitfalls that distracted from learning the basics of algorithmic thinking and important abstraction skills. Once the foundation was put in place, it was okay to swtich 'em to C for the rest of the program.
When C++ and the early object boom really hit, this put on big pressure to teach first year students using C++. At one point in the mid-90's, upwards of 75% of 4-year institutions were teaching their first year in C++. Thus a language that had plenty more pitfalls than C, previously shunned for its pedagogical failings, entered the classroom. Combined with a lack of of proper OO mental retooling on the part of first year instructors and faculty made for something of a skills disaster on a broad scale. At best, students learned "Modula-C" instead of good OO style. At worst, they were so confused by this melange of one-instance classes and sloppy hybrid typing that they didn't get a cohesive foundation whatsoever.
[HD-DVD] is mostly an excuse to introduce a new CSS system since the old one is cracked..
I disagree. The big CE companies are all vying for marketshare in the forthcoming HDTV space. This includes the entire signal chain, of which DVDs are just a part. The old DVD format doesn't support HDTV resolutions, so it had to go eventually. With CSS having been 0wn3ed, of course it'll be replaced. Even if only to refresh the associated patents.
Moreover, despite DeCSS, I believe that CSS has been a big success for the DVD Copy Control Association. The cracking of CSS has had little effect on real-world products or markets. Has there been an explosion of mass market DeCSS-based region-free DVD players? Nope. Has DeCSS done _anything_ measurable to reduce the ability of the DVD Copy Control Association (and its supporting industries) to write global trade laws (re: region coding) into firmware? Not that I can discern. CSS is certainly a perceived threat, but that's a forward-looking concern that worries about the coming of a video P2P phenomenon like the music industry has witnessed.
A professional music director/organist of my acquaintance played a large, wonderful, and somewhat elderly pipe organ at a local church. During the winter before it was finally renovated, the old organ was getting quite wheezy. They rented an electric organ for the season. He rather disparagingly referred to it as "the toaster". Seems that was a conventional term for the pipe-elitists to use. 8-)
This thread on the Debian mailing lists talks about this issue, and a poster in this thread notes that SE Linux is capable of closing this hole (with example). I don't recall offhand what tools are available in grsecurity (www.grsecurity.net) to address this issue; check out the grsec mailing lists for more info.
That mechanism is an excellent means to DRM. The loader only loads files signed by the OS provider and nothing more.
I disagree with your assessment. It depends on how the separation of mechanism and policy are implemented in the system. The "fear zone" you describe could only apply to a proprietary, binary-distributed system. Consider an environment where the system installer (call 'em the Admin) can install a public key at system setup time. Then, assuming the correctness of the signing system, the Admin can be assured that only properly signed binaries are run on that system. You'd want the build system and signing system to be off-network and physically secured.
That said I think signed binaries are a stopgap, not an OS-level security architectural feature. You'd have to refuse to sign any interpreters, or else modify all of them to run only signed code. Furthermore, this doesn't address questions of code injection into an already-running application.
That's a silly reason for plugging DRM. Simply mount all user-writable space with option "noexec" and you have the same level of security.
Life is more complicated than that. Regular binaries can be run as:/lib/ld-linux.so/noexeced_path/myprog
Even locking this out, any available program that is itself an interpreter (e.g. Perl, etc.) can be used to run code. Assume that any attacker (or their scripts) know this and will leverage it.
I'm seriously beginning to think that we won't be able to achieve secure systems that reliably push the security problem to the social boundary until ground-up designs such as the Extremely Reliable Operating System mature.
Recall the assumptions inherent to a game console software platform. Portability is explicitly traded away for performance and implementation simplicity/stability. The cut-down embedded NT kernel the XBox team uses (not "Windows") will certainly need some porting work for an entirely new processor. However, there's almost certainly an embedded NT kernel port to PPC already available. Whether or not this particular IBM PPC chip has a little-endian mode will probably no more than determine the NT group's starting branch & build number to be used as the seed cut for XBox2 development.
Likewise, DirectX for the XBox is not a port of the PC library -- it's a bare-metal optimized reimplementation. MS chose the DirectX API to simplify the lives of game developers coding to the XBox platform, not to reduce their own development work. To achieve meaningful performance and feature gains in XBox2, with entirely new CPU and graphics hardware, DirectX support has to be reimplemented pretty much by definition. At least at this point in time, this sort of thing is part and parcel of the console software platform world.
Lockheed-Martin and Worldscape Defense presented the results of their work using ClearSpeed's processing solutions.
They benchmarked FFT and pulse compression algorithms and found between 20 and 30 times improvement in performance per watt against competitive solutions.
That page also has a PDF of their presentation at the 2003 Microprocessor Forum. Whether this technology will pan out is a matter for the markets, but ClearSpeed isn't looking very vaporous.
I don't even think it's necessary for Apple to try and get a bigger marketshare.
Perhaps, but things I've heard from small developers and software companies suggest that a slightly bigger market could help the Mac platform.
One primary cycle in a healthy "platform ecology" is that a healthy userbase drives the platform desirability for developers. The other half of this cycle is that a rich developer base is a factor drawing users to a platform.
The flip side is a downward spiral where insufficient users or insufficient developers cause platform acceptance to dwindle over time.
While Apple doesn't need to dominate the world, they do want a "healthy" (that word again) steady-state market size that supports vibrant user and developer commmunities.
Side note: I've deliberately used vague terms such as "healthy" and "rich" above to cover many variables that affect these groups. For simplicity, think of these as size of these groups.
Kind of like how DVDs support "optional" encryption?...let me know when you find one without...
Ghost in the Shell. In fact, a mess of my anime DVDs, movies and series both, don't have any CSS employed. E.g. they'll play in stock non-CSS Xine out of Debian. My guess is that some smaller publishers just don't bother with CSS.
A truly amazing fact, is the response to nervous system stimulants among individuals diagnosed with ADHD. When a "normal" individual takes such drugs, they tend to become very hyperactive, whereas the inverse is observed among ADHD patients: stimulants slow them down.
This slowing down isn't as surprising when you understand some of the principles on which the brain is currently believed to work, and current theories on what's happening in those diagnosed with ADHD. The first important item is that the brain has numerous structures with an important inhibitory function instead of an activating function. That is, when excited, these structures act to inhibit other regions of brain activity. There's some fascinating work relating to sleep mechanisms on this very point. In ADHD folks, it's believed that some important inhibitory systems don't work with the same effectiveness as in non-ADHD folks. It is thought that a stimulant's effect on an ADHD person excites all regions of the CNS, but also acts to bring the inhibitory systems into better relative balance in the global brain context, thus ameloriating the symptoms of ADHD.
Alas, I don't have any of my refs on hand, but check out a neurophisiology text for activating and inhibitory functions, or the neurophysiology parts of the excellent book Zen and the Brain.
This used to be true ten years ago, but you are way out of date. OCaml works great for I/O. If available Debian packages are any measure, OCaml has had quite the active and growing developer base too.
The major semantic hurdles for even (mostly-)pure functional languages (c.f. Haskell) were solved many years ago. (Look up the papers of John Launchbury, Simon Peyton-Jones, and others on State Transformers in Haskell. See also papers about how the use of the 'monad' from category theory introduced an incredibly powerful tool into languages such as Haskell). The Fox project at CMU used Standard ML to create a nifty layered TCP/IP stack and HTTP sever back in the mid 90's.
The various current functional languages may have issues, social and/or technical, w.r.t. mass adoption... but the I/O problem definitely isn't one of them anymore.
When did putting in a word to something to insult it [become] so popular[...]?
Just as soon as various internet technologies failed utterly to communicate emotional nuance. c.f. the whole history of smileys and other forms of 'net, IRC, and IM meta-language. Plain language in plain ASCII (or your local fave encoding) doesn't carry emotional tone, period.
To wit: in an in-person conversation, this poster might simply have sufficed with facial expression, body language, and/or a tone of hesitancy or outright derision. Alas, the impressive facility of the limbic brain to interpret such nuance and render it fluidly into additional meaning goes "bonk" in 'net communication.
Besides, this poster was utterly plain in a simply stated dislike of BestBuy. You'd *rather* yet another offtopic slashdot rant? (tounge firmly in cheek..;-) I see no need for further "valid arguments" to establish this opinion. If the poster's attitude piques your curiosity, maybe the "mature" thing to do would be to just ask, "hey, what've you got against BestBuy?"
I use Google because it is fast, efficient, and has unobtrusive advertising.
I'll add something to that -- Google is one of the very few sites that receives ad clicks from me! There are (at least) two big mistakes that so many web ads are prone to: 1) no personal relevance to the viewer and 2) they're damned annoying. Either of these is a deal-breaker for me.
Google manages to avoid the first failing by tying ads to the search topic. Thus if you're doing product research via Google, you're likely to encounter some relevant advertiser links.
Similarly, Google maintains control over the ad format. This dodges the second failing by ensuring that the ads are consistent with the unclutered nature of the site, are visually inoffensive, and are distinct from the search content. (Hmm... that seems oddly similar to sponsored placements on NPR stations. Go fig.)
It shouldn't be any more difficult to extend KHTML, at least not any more difficult than it would be to speed up Mozilla.
What follows isn't really about Safari/KHTML or */Gecko -- it's intended to play devil's advocate to the statment of work-equality presented above.
I propose that it probably isn't the case that extending KHTML (while retaining performance) is easier than optimizing Gecko. The folk wisdom of the field (attributed to Knuth?) suggests the following:
Start with a clean, elegant architecture and implementation.
Once that is complete and robust, then optimize on that basis.
KHTML is well regarded for its clean, robust codebase. On first glance, this jibes well with the first part of our rule of optimization, above. Looking deeper, let's put on our technical program manager hat. We're pleased to hear that KHTML has an elegant architecture and efficient codebase. But what keeps us up at night is the knowledge that the problem domain -- "correctly" rendering web content -- is inherently ugly. Our concern about moving the project forward is based on the gap between KHTML-now and KHTML that accurately models the so-called warts of the problem domain. Will it retain its performance as its architecture and code adapt?
Setting aside our open questions, let's consider Gecko. As Gecko essay writers have echoed, it's been hard work to cleanly model an ugly domain. Inevitably, some of the domain ugliness has complicated the architecture and code. That seemed unavoidable, but thankfully is largely past. What remains is to extract lessons learned, and refactor/optimize within a robust codebase to improve an project with a fairly complete model (read feature/compatibility set).
Now let's change roles to an imaginary V.P. or Director overseeing both of these projects. Our concern turns towards the timeline of the KHTML project. Why? Because experience suggests that closing the gap between a robust project and the domain it's trying to model (*/KHTML's task) generally holds more unforseen "surprises" and architectural challenges than optimizing a project that is also solid yet more-or-less architecture and feature complete (*/Gecko's task).
How does this relate to our folk-wisdom regarding optimization? We tend to like the idea of starting with a clean organization and staying that way, which at first glance lends a preference towards KHTML. But since KHTML's major effort lies in feature/compatibility completeness, it may encounter substantial time risks in dealing with the ugliness of web content presentation. Gecko, viewed in this light, would appear to be at or near the end of the "implement it" phase -- with some scars from the thorny domain -- and ready for optimization and cleanup. When considering the purely technical risks, Gecko seems to be at an advantage.
With the above in mind, I'm looking forward to seeing how and why these projects individually compare to the above speculation as they mature. Will the above short-term technical assessment pan out? What technical risks arose, were anticipated, and were the respective projects prepared for realized risks? Wait and see...
Because of my having to keep IE on hot standby, it doesn't even occur to me anymore to email MS (or any other site) and complain about lack of Opera testing. If they don't get feedback, they ain't gonna fix it.
Let's get to the heart of the matter here: the real bugaboo is pathetic web standards compliance, industry wide. I'd love to see the W3C start using the time-honored tactic of creating trademarked certification names and logos usable only by browser versions that pass a rigorous and public compliance suite. Then web developers could start a) targetting standards as they should and b) righteously flaming sites that do stupid non-standards based things (like serving up different content for different browsers as a workaround for standards non-compliance).
I guess the question is, what's holding back consumer electronics companies from implementing OGG and FLAC support?
Not much. Xiph offers ported and optimized fixed-point code for Ogg Vorbis to anyone who wants it on royalty-free terms (BSD or similar license IIRC). Moreover Xiph has been actively promoting its standards and codebases directly to the involved businesses.
Nevertheless, the trick is actually getting the end-product companies to make Vorbis/FLAC support a requirement for their next product/revision. I suspect it'll be Apple or a similar market leader that forces the hand of the competitors, since it seems that most marketing departments can't see further past their noses than their competitor's feature lists.
Slashdot Mirror
Rather than being bothered to actually try and understand something you just shrug your shoulders and say "magic".
I've noted a similar trend along these lines amongst myself and other geek friends lately. When mulling some topic to which the answer is unknown to the group, someone will expound something like "Google knows" or "imdb knows". Instead of supersition, we now have specific cultural icons for "knowledge somewhere out there." 8-)
I have said that *1000* times and been moded a troll every last time
I don't know about the other times, but you're a troll now. The earlier poster described a situation in which a company has transitioned beyond the early adopter phase, and is selling products based on what he called "signs". I.e. Apple has transitioned to using the marketing tactics of a mature industry, not an early adopter industry. You, however go on to make inflammatory and content-free statements like "People who buy Apples are the same irrational fanboys [deletia]." Go log off, troll.
Folks looking for great information on market transitions and computing w/o the rant and religion should go read the first several chapters of Don Norman's "The Invisible Computer". You'll get some fascinating history of market evolutions, and analysis of the state of computing w.r.t. how earlier markets evolved from early adopter phases into maturity.
Just built up a new computer. The power supply worked once, then turned into a doorstop on the second cold boot. I think the company who made it was a little too agressive in their implementation of the OP spec. 8-)
Further complicating the problem is that even if someone were to develop an environment that attempted to prevent all of the problems caused by programmer errors, it would be horrendously complex and would likely kill performance.
IMO, a big part of the solution is factoring out solutions for major known security problem areas into the environments, languages, and frameworks that developers use on a day-to-day basis. E.g. if you're using a language with robust automatic memory management, there's little reason to go looking for C-style buffer overflow exploits coded by your developers.
In today's environments (e.g. Windows and current *nix systems) with current popular languages (e.g. C, C++) we're at a big disadvantage. Much of the discussion in this thread presumes that coders can/should amass total knowledge of all levels of security exploits, from binary code injection to cross-site scripting (aka CSS), SQL injection, etc. It becomes overwhelming to a dev who really should be able to focus on the value-added problems at hand. I'm aware of only one cost efficient approach: choose environments, languages, and/or tools that mitigate known security risks.
Where applicable, this can be done by leveraging environments that can limit the scope of attacks. See SELinux and GR Security for ways to patch Linux to meet thess needs, or the EROS project for a fresh view of OS security and compartmentalization models. Environment choise is most relevant to folks providing networked services, where they can control the platform specifics.
The cause can also be aided by using languages/frameworks that encapsulate security knowledge. This can be as "simple" as using a language with automatic memory management(to factor out common buffer overflow problems), or along the lines of using scripting frameworks that standardize policies for correctly managing more complex security issues (e.g. cookie management, web input/output validation, CSS issues, etc).
I'd argue that it is possible to improve software security practices significantly simply by careful choices of tools and techniques available today. But it takes a saavy organization to really commit to providing secure software solutions, and to be able to do so in a cost effective manner. As always, the hard part of the equation is programming the wetware. 8-)
Read the manga, from which the anime was derived. Judging Appleseed on the first anime version is like judging Frank Herbert's _Dune_ on David Lynch's 1984 movie.
The challenge that any attempt to realize Appleseed as anime faces is that the manga has a *lot* going on. Global politics, layers of social and racial turmoil, the affects of high technology on society (and vice versa), etc. With such a rich world and story line, creating a compelling version of that story in even one or two movie length features is very difficult.
Last but not least, if you want your notions of superhero comics turned on their head, go pick up one of the graphic novels from Kurt Busiek's _Astro City_ series. Great characters, detailed world, and compelling storytelling. Oh, yeah, and with superheroes. 8-)
Do you know if anyone has considered using wind or solar energy to power the ethanol producing equipment?
Speaking strictly in the context of this article, is there any evidence that this would improve the total energy storage yield over an approach like electrolysis using solar-generated electricity? If you really need a biological element, there were researchers working on improving the efficiency of a hydrogen-generating algae a while back, for another more direct approach to sun+water= hydrogen. Seems like the whole corn production and conversion to ethanol is rather roundabout.
Plasma still exists because it has one advantage over LCD/DLP in the price/performance war: Bigger direct-view screens that can be easily mounted on a wall.
This isn't a big advantage anymore. Sharp and a few other manufacturers have 30+" and 40+" direct-view widescreen LCD displays now. One new 45" Sharp display, subject of a recent announcement at CES, is a 1080p display! Units in the 32+" range I saw this weekend were priced in the ~$3300 USD range.
Perhaps it's time that computer science curriculums start teaching assembly language first.
Having taught an assembly/into computer arch class, I agree with the sentiment that students who get "under the hood" gain valuable knowledge and working skills. Not just pounding ASM, but in learning how the machine works. Point agreed.
Also having taught first year computer science students, and seen how some of academia's transitions in pedagogy affected students... I have to say that the idea of teaching first year students in assembly is friggin' daft.
My reasoning is the same as why I strongly advocated an objects-first teaching model. It is increasingly critical for students to build a strong sense of software design and abstraction early on. This foundation makes students much better prepared to solve problems of many different scales (asm to component-systems) in the long run.
There's evidence from a paper in one of the Empirical Studies of Programmers workshops that this approach does trade off design skills for purely algorithmic reasoning for students at the end of their first year. But my own experience, as well as that of some prominent Comp Sci Education (CSE) folks seems to indicate that this is far more than compensated for as a student's skills grow.
Here's my theory as to why this is the case:
The details of debugging, alogrithmic thinking, and problem solving are very much skill building exercises that really require time of exposure to improve. But it is much more difficult in my experience for students to build good design sense on their own. Once the framework for thinking in terms of good abstractions is laid down, it provides much stronger support for later filling all of those gory low-level details.
Historical perspective: Ironically, this same reasoning is much of why I believe that academia's switch to C++ from languages like Pascal, Modula-2, etc. was an educational disaster for many years. The astute reader is now thinking: "hey, you just said you like objects-first; what up?" In the Procedural Era, many schools wouldn't expose students to C in the first year, as it had too many pitfalls that distracted from learning the basics of algorithmic thinking and important abstraction skills. Once the foundation was put in place, it was okay to swtich 'em to C for the rest of the program.
When C++ and the early object boom really hit, this put on big pressure to teach first year students using C++. At one point in the mid-90's, upwards of 75% of 4-year institutions were teaching their first year in C++. Thus a language that had plenty more pitfalls than C, previously shunned for its pedagogical failings, entered the classroom. Combined with a lack of of proper OO mental retooling on the part of first year instructors and faculty made for something of a skills disaster on a broad scale. At best, students learned "Modula-C" instead of good OO style. At worst, they were so confused by this melange of one-instance classes and sloppy hybrid typing that they didn't get a cohesive foundation whatsoever.
[HD-DVD] is mostly an excuse to introduce a new CSS system since the old one is cracked..
I disagree. The big CE companies are all vying for marketshare in the forthcoming HDTV space. This includes the entire signal chain, of which DVDs are just a part. The old DVD format doesn't support HDTV resolutions, so it had to go eventually. With CSS having been 0wn3ed, of course it'll be replaced. Even if only to refresh the associated patents.
Moreover, despite DeCSS, I believe that CSS has been a big success for the DVD Copy Control Association. The cracking of CSS has had little effect on real-world products or markets. Has there been an explosion of mass market DeCSS-based region-free DVD players? Nope. Has DeCSS done _anything_ measurable to reduce the ability of the DVD Copy Control Association (and its supporting industries) to write global trade laws (re: region coding) into firmware? Not that I can discern. CSS is certainly a perceived threat, but that's a forward-looking concern that worries about the coming of a video P2P phenomenon like the music industry has witnessed.
A professional music director/organist of my acquaintance played a large, wonderful, and somewhat elderly pipe organ at a local church. During the winter before it was finally renovated, the old organ was getting quite wheezy. They rented an electric organ for the season. He rather disparagingly referred to it as "the toaster". Seems that was a conventional term for the pipe-elitists to use. 8-)
Seems like a stupid security hole.
This thread on the Debian mailing lists talks about this issue, and a poster in this thread notes that SE Linux is capable of closing this hole (with example). I don't recall offhand what tools are available in grsecurity (www.grsecurity.net) to address this issue; check out the grsec mailing lists for more info.
I disagree with your assessment. It depends on how the separation of mechanism and policy are implemented in the system. The "fear zone" you describe could only apply to a proprietary, binary-distributed system. Consider an environment where the system installer (call 'em the Admin) can install a public key at system setup time. Then, assuming the correctness of the signing system, the Admin can be assured that only properly signed binaries are run on that system. You'd want the build system and signing system to be off-network and physically secured.
That said I think signed binaries are a stopgap, not an OS-level security architectural feature. You'd have to refuse to sign any interpreters, or else modify all of them to run only signed code. Furthermore, this doesn't address questions of code injection into an already-running application.
Recall the assumptions inherent to a game console software platform. Portability is explicitly traded away for performance and implementation simplicity/stability. The cut-down embedded NT kernel the XBox team uses (not "Windows") will certainly need some porting work for an entirely new processor. However, there's almost certainly an embedded NT kernel port to PPC already available. Whether or not this particular IBM PPC chip has a little-endian mode will probably no more than determine the NT group's starting branch & build number to be used as the seed cut for XBox2 development.
Likewise, DirectX for the XBox is not a port of the PC library -- it's a bare-metal optimized reimplementation. MS chose the DirectX API to simplify the lives of game developers coding to the XBox platform, not to reduce their own development work. To achieve meaningful performance and feature gains in XBox2, with entirely new CPU and graphics hardware, DirectX support has to be reimplemented pretty much by definition. At least at this point in time, this sort of thing is part and parcel of the console software platform world.
Perhaps, but things I've heard from small developers and software companies suggest that a slightly bigger market could help the Mac platform.
One primary cycle in a healthy "platform ecology" is that a healthy userbase drives the platform desirability for developers. The other half of this cycle is that a rich developer base is a factor drawing users to a platform.
The flip side is a downward spiral where insufficient users or insufficient developers cause platform acceptance to dwindle over time.
While Apple doesn't need to dominate the world, they do want a "healthy" (that word again) steady-state market size that supports vibrant user and developer commmunities.
Side note: I've deliberately used vague terms such as "healthy" and "rich" above to cover many variables that affect these groups. For simplicity, think of these as size of these groups.
Kind of like how DVDs support "optional" encryption? ...let me know when you find one without...
Ghost in the Shell. In fact, a mess of my anime DVDs, movies and series both, don't have any CSS employed. E.g. they'll play in stock non-CSS Xine out of Debian. My guess is that some smaller publishers just don't bother with CSS.
A truly amazing fact, is the response to nervous system stimulants among individuals diagnosed with ADHD. When a "normal" individual takes such drugs, they tend to become very hyperactive, whereas the inverse is observed among ADHD patients: stimulants slow them down.
This slowing down isn't as surprising when you understand some of the principles on which the brain is currently believed to work, and current theories on what's happening in those diagnosed with ADHD. The first important item is that the brain has numerous structures with an important inhibitory function instead of an activating function. That is, when excited, these structures act to inhibit other regions of brain activity. There's some fascinating work relating to sleep mechanisms on this very point. In ADHD folks, it's believed that some important inhibitory systems don't work with the same effectiveness as in non-ADHD folks. It is thought that a stimulant's effect on an ADHD person excites all regions of the CNS, but also acts to bring the inhibitory systems into better relative balance in the global brain context, thus ameloriating the symptoms of ADHD.
Alas, I don't have any of my refs on hand, but check out a neurophisiology text for activating and inhibitory functions, or the neurophysiology parts of the excellent book Zen and the Brain.
if they're lucky, they won't have to empty their bins so often.
Hmm.. this sounds like distributed.net's concept of a landfill. 8-)
can't connect them to real I/O
This used to be true ten years ago, but you are way out of date. OCaml works great for I/O. If available Debian packages are any measure, OCaml has had quite the active and growing developer base too.
The major semantic hurdles for even (mostly-)pure functional languages (c.f. Haskell) were solved many years ago. (Look up the papers of John Launchbury, Simon Peyton-Jones, and others on State Transformers in Haskell. See also papers about how the use of the 'monad' from category theory introduced an incredibly powerful tool into languages such as Haskell). The Fox project at CMU used Standard ML to create a nifty layered TCP/IP stack and HTTP sever back in the mid 90's.
The various current functional languages may have issues, social and/or technical, w.r.t. mass adoption... but the I/O problem definitely isn't one of them anymore.
Just as soon as various internet technologies failed utterly to communicate emotional nuance. c.f. the whole history of smileys and other forms of 'net, IRC, and IM meta-language. Plain language in plain ASCII (or your local fave encoding) doesn't carry emotional tone, period.
To wit: in an in-person conversation, this poster might simply have sufficed with facial expression, body language, and/or a tone of hesitancy or outright derision. Alas, the impressive facility of the limbic brain to interpret such nuance and render it fluidly into additional meaning goes "bonk" in 'net communication.
Besides, this poster was utterly plain in a simply stated dislike of BestBuy. You'd *rather* yet another offtopic slashdot rant? (tounge firmly in cheek..
I'll add something to that -- Google is one of the very few sites that receives ad clicks from me! There are (at least) two big mistakes that so many web ads are prone to: 1) no personal relevance to the viewer and 2) they're damned annoying. Either of these is a deal-breaker for me.
Google manages to avoid the first failing by tying ads to the search topic. Thus if you're doing product research via Google, you're likely to encounter some relevant advertiser links.
Similarly, Google maintains control over the ad format. This dodges the second failing by ensuring that the ads are consistent with the unclutered nature of the site, are visually inoffensive, and are distinct from the search content. (Hmm... that seems oddly similar to sponsored placements on NPR stations. Go fig.)
What follows isn't really about Safari/KHTML or */Gecko -- it's intended to play devil's advocate to the statment of work-equality presented above.
I propose that it probably isn't the case that extending KHTML (while retaining performance) is easier than optimizing Gecko. The folk wisdom of the field (attributed to Knuth?) suggests the following:
KHTML is well regarded for its clean, robust codebase. On first glance, this jibes well with the first part of our rule of optimization, above. Looking deeper, let's put on our technical program manager hat. We're pleased to hear that KHTML has an elegant architecture and efficient codebase. But what keeps us up at night is the knowledge that the problem domain -- "correctly" rendering web content -- is inherently ugly. Our concern about moving the project forward is based on the gap between KHTML-now and KHTML that accurately models the so-called warts of the problem domain. Will it retain its performance as its architecture and code adapt?
Setting aside our open questions, let's consider Gecko. As Gecko essay writers have echoed, it's been hard work to cleanly model an ugly domain. Inevitably, some of the domain ugliness has complicated the architecture and code. That seemed unavoidable, but thankfully is largely past. What remains is to extract lessons learned, and refactor/optimize within a robust codebase to improve an project with a fairly complete model (read feature/compatibility set).
Now let's change roles to an imaginary V.P. or Director overseeing both of these projects. Our concern turns towards the timeline of the KHTML project. Why? Because experience suggests that closing the gap between a robust project and the domain it's trying to model (*/KHTML's task) generally holds more unforseen "surprises" and architectural challenges than optimizing a project that is also solid yet more-or-less architecture and feature complete (*/Gecko's task).
How does this relate to our folk-wisdom regarding optimization? We tend to like the idea of starting with a clean organization and staying that way, which at first glance lends a preference towards KHTML. But since KHTML's major effort lies in feature/compatibility completeness, it may encounter substantial time risks in dealing with the ugliness of web content presentation. Gecko, viewed in this light, would appear to be at or near the end of the "implement it" phase -- with some scars from the thorny domain -- and ready for optimization and cleanup. When considering the purely technical risks, Gecko seems to be at an advantage.
With the above in mind, I'm looking forward to seeing how and why these projects individually compare to the above speculation as they mature. Will the above short-term technical assessment pan out? What technical risks arose, were anticipated, and were the respective projects prepared for realized risks? Wait and see...
Because of my having to keep IE on hot standby, it doesn't even occur to me anymore to email MS (or any other site) and complain about lack of Opera testing. If they don't get feedback, they ain't gonna fix it.
Let's get to the heart of the matter here: the real bugaboo is pathetic web standards compliance, industry wide. I'd love to see the W3C start using the time-honored tactic of creating trademarked certification names and logos usable only by browser versions that pass a rigorous and public compliance suite. Then web developers could start a) targetting standards as they should and b) righteously flaming sites that do stupid non-standards based things (like serving up different content for different browsers as a workaround for standards non-compliance).
I guess the question is, what's holding back consumer electronics companies from implementing OGG and FLAC support?
Not much. Xiph offers ported and optimized fixed-point code for Ogg Vorbis to anyone who wants it on royalty-free terms (BSD or similar license IIRC). Moreover Xiph has been actively promoting its standards and codebases directly to the involved businesses.
Nevertheless, the trick is actually getting the end-product companies to make Vorbis/FLAC support a requirement for their next product/revision. I suspect it'll be Apple or a similar market leader that forces the hand of the competitors, since it seems that most marketing departments can't see further past their noses than their competitor's feature lists.