I am 99.99% certain that OSX 10.2 (Jaguar) uses hardware texture mapping to blit/composite offscreen window buffers to the desktop. (previous versions of OSX did NOT use the hardware like this; it is a new optimization in Jaguar). Any Mac website should have the details.
I am not sure why they wouldn't use better filtering for the window-scrunching effects. I haven't used Jaguar myself yet so I don't know if this has changed. (obviously bilinear filtering would be very expensive in pre-Jaguar software mode).
Thanks for your ideas on resizing... I think OSX does actually perform eager allocation when enlarging windows; the slow resizing that most OSX users complain about may simply be due to the software 2D rendering... One complicating factor is that, as far as I know, OSX requires that ALL pixels in ALL open windows be stored all the time, even for portions of the window that are outside the screen. (I assume this is to eliminate the need for "damage/repaint" events; however the memory costs are quite substantial...)
Have you actually benchmarked it though? I have done kernel traces of X interacting with client programs. The read()/write() overhead (copying data across the socket) is insignificant compared to the "extra round-trip" problems that spitzak describes.
I would never work on DRM software. Currently I spend hours each day writing software to try to let people do more with their computers. It's very difficult and time-consuming, and I'm not always successful... I'd hate to be writing software that makes people do less with technology. That's just a disgusting waste of resources.
As Apple says, copyright infringement is a social issue, not a technological one. The media industry thinks ubiquitous DRM is the solution, when all they need to do is offer their content for download cheaply, in plaintext formats.
OK, so non-official DHCP servers should be banned. The fact that some WAPs happen to include DHCP servers is incidental. (someone could also try to set up their own DHCP server with a Win2K or Linux box)...
NJ gave itself the right to regulate rides after an accident where two were killed from a malfunction, not excessive Gs.
I hate this kind of misdirected legislation. It's like the new airline baggage screening requirements (helllooo! The 9/11 hijackers did not have any dangerous checked baggage!). Or gun control laws being passed in reaction to violence committed with illegally-possessed guns. (they were already illegal, see?)
You are correct. Satire (using elements of a copyrighted work for comical/ludicrous effect) is not protected. Only parody (using elements of a copyrighted work to make fun of the work itself) is.
e.g. if a Saturday Night Live sketch featured actors dressed up as Star Wars characters in order to make fun of Star Wars, that would be fair use (parody). But if they were making fun of American politics (satire), they would need a license from Lucasfilm.
Of course this distinction is pretty ridiculous... It's the result of copyright holders successfully claiming that copyright is an absolute "property right" (which it is not).
One thing this article clearly shows is the polar opposite viewpoints that people tend to take - the "enlightened" let's-find-a-way-to-benefit-from-new-technology view (exemplified by the narrator) and the "backward" let's-keep-things-the-way-they've-always-been view (the photographer). I bet she'd love to hear about Microsoft's upcoming ubiquitous DRM system. ("you mean you can send out a file that can't be copied more than once? And they have to buy it again if their computer crashes? Awesome!")
Unfortunately the "backward" side seems to be winning. Look at DVDs - DVD video could have been specified in a neutral video format that would play on any player, anywhere in the world. But the MPAA film studios didn't feel like re-negotiating all of their exclusive regional distribution contracts, so they slapped on the Region Coding system. So we have regressed - there are now MORE barriers to international video distribution than the simple NTSC/PAL dichotomy of the analog world.
And since more barriers always benefit the producer, and the producers have Congress in their pockets, it's going to get worse...
I think the biggest problem you'd have in adopting a digital voting system would be making it simple enough so that most people could understand it.
I'm assuming that most US citizens (myself included) would probably not be confident in, or willing to adopt, a system that they can't easily understand and trust.
A pencil-and-paper system is simple enough that anyone can get it - check the box, a human counts it, there's your vote. Even our wacky electoral college system is probably within most people's grasp. But once you start talking about public-key encryption or digital signature algorithms, only a tiny percentage of citizens are going be able to keep up. (and most of that tiny percentage will be white males - providing endless ammunition for politically correct fear-mongering =).
A digital voting system of the necessary sophistication would be beyond most people's understanding, and thus subject to claims of manipulation. (regardless of the system's actual resistance to fraud)
I really like QT/KDE, but I have to admit that one of QT's basic flaws is that it is tied to a simple one-owner memory management scheme. As a result the Python binding was a disaster - the binding had no way to prevent a QT object from being deallocated, so if you did certain things (like remove a widget from a window), you could easily segfault the interpreter.
It would be great to have a nice C# binding, but I don't see how one could feasibly interface QT with a garbage-collecting language. It's pretty much designed to be used from C++ only.
Re:Frequently Asked User Interface Questions
on
Inside Ximian
·
· Score: 2
All I want to do is copy information from "small" window B to "big" window A without A popping up and obscuring B.
Ah, I see... I don't do this kind of thing very often, but one example might be when I have two source code windows open and I'm alternating back and forth. I tend to set up the windows side-by-side, but since I write long lines they usually don't quite fit; they overlap a bit. And it's annoying because usually the wrong window is on top when I need it! Your suggestions would probably help in this case... But again this is pretty much the only example I can think of from my own experience, and you have to balance it against my years of conditioning with click-to-raise =).
One other issue that bears considering is minimizing switches between the mouse and keyboard. It may sound insignicant, but I really believe I work faster (and experience less hand/wrist stress) the more unnecessary trips to the mouse I can skip.
Of course what we really want isn't "point to type," it's "think to type" =)
Re:Frequently Asked User Interface Questions
on
Inside Ximian
·
· Score: 2
Yes, we are definitely entering religious-war territory...
Re: point-to-type - I am undecided on this one. Most of the time it works great for me and it saves mouse clicks. However, sometimes it is annoying because I accidentally leave the mouse outside of where I was typing, and have to move my hand to it, re-point the mouse, and move back to continue typing. Also I don't really like the "wild light show" effect I get when moving the mouse around (titlebars changing colors as I activate/deactivate windows by moving over them).
Re: pointer warp - I'm pretty strongly against this; I don't like the feel of having the pointer out of my control. (I think what you really might be asking for is better positioning of dialog boxes - many Linux window managers do a terrible job of deciding where to put pop-up/dialog windows).
Re: not raising windows on click or move - I bet you have a very different strategy for arranging windows... Personally I hate it when I have to use a system that doesn't raise windows on click. But it's probably because I depend on this feature for my subconscious "desktop navigation." I'd have to sit down and try your method to see if it's better.
(I do change my mind sometimes - not long ago I couldn't figure out what the big deal was with "tabbed" web browsing - then I discovered how awesome it is, and now I can't stand browsers that don't support tabbing! It's just a much better way to work than opening N different browser windows).
Re: exactly as many threads as CPUs - this is only possible if you have access to non-blocking APIs for everything (disk I/O, sockets, DNS lookups, libraries, etc). If you can only use standard read/write disk I/O, then you may need a pool of disk I/O threads to achieve enough parallelism.
Re: state machines being harder to write than threads - I actually disagree! I think many people have spent so much time learning all the concurrency control techniques (mutexes, semaphores, etc) that they forget what life was like before threads. e.g. consider that adding a mutex to a multithreaded program essentially doubles the program's state space (multiply "mutex locked" and "mutex unlocked" by all the existing states). But unlike a state machine, there is no way to control exactly when you enter or leave the state, and it's not always easy to even know what state you are in at any time (since thread scheduling is totally at the mercy of the OS kernel).
I can understand why people often implement "background tasks" like garbage collection and long-running computations as asynchronous threads. But in my own code I often do these things incrementally, explicitly interleaved with other actions. I don't find it terribly difficult, and I gain the advantage of explicit scheduling. (again threads are at the mercy of the kernel - you have NO control over when any background tasks actually run). And with threads you have to add in all that locking too... Finally, to my knowledge there is no portable way to terminate a background thread asynchronously without leaking memory or leaving some locks in an unknown state. The only safe way to shut threads down is to set a flag, and have the thread check it every so often. But if you're doing this then you are already half-way to an incremental state machine!
I'll finish with an example from a recent project - I wrote a real-time video player system that streams data from disk to an I/O card at a fixed rate. In order to get enough performance, I needed the disk I/O to take place asynchronously with respect to controlling the I/O card. Most people would use threads for this, but instead I used two forked processes - one constantly read data from disk and put it in a shared-memory buffer, the other read from the buffer and wrote to the card. The processes communicated through a pipe, so if the buffer got full or empty, the appropriate process would simply block in read() or write(). The design is simple, there is no need for locking (other than what UNIX pipes do automatically), and it only took me an hour or so to get it working =).
It's nice to know there are others out there who know state machines are the One True Way =). Ideally you have exactly as many threads as CPUs, and use non-blocking state machines for everything. (and unless the CPUs need to share a great deal of information, use processes rather than threads to side-step cache contention and locking; communicate with pipes or shared memory)
Unfortunately this ideal is sometimes hard to achieve because non-blocking APIs are not always available. (e.g. there is no way to poll/select a pipe on Windows, and true asynchronous file I/O is still in the testing stages on Linux)
Keeping this on topic - there are plenty of HTTP servers out there with more sane concurrency models - thttpd is one of many... (I can't really fault Apache for making the choices they did; their goals are more standards conformance and portability than raw speed).
I would actually place the blame for this on hardware makers, for making it so difficult to find out exactly what chipset is driving their product.
e.g. I was given a spare Asante ethernet card recently, and neither the vendor's site nor an extensive Google search could tell me what chipset it used. In desparation I peeled off the "Asante" sticker on the big chip in the middle of the board, and guess what, beneath the chip said "PNIC" on it. If the vendor had cared to mention its card was PNIC-based, I would not have had to waste so much time...
Network card makers seem to be the worst about this, followed by sound card companies. At least with video cards the chipset is usually part of the product name. (e.g. Super Whizbang Turbo Alpha Killer Mega GeForce 2)
I recently faxed the following letter to my Congressional representatives. Feel free to quote it in your own correspondence, with proper attribution of course. (apologies for the formatting; this is copied from LaTeX source)
I am proud to be both your constituent and the owner of a small but successful digital video studio. I have become very alarmed by recent changes to U.S. copyright law, and the direction in which it seems to be heading. The tremendous powers the law has granted to copyright owners, particularly large film and music studios, are having a deleterious effect on independent producers (such as myself) as well as consumers of these media.
Under the pretense of combating music and film piracy, the major U.S. recording companies and film studios have recently obtained legal powers that extend far beyond the reasonable, limited monopoly conferred by traditional copyright law. For example, the 1998 Digital Millennium Copyright Act (DMCA) outlawed the creation of tools that circumvent the copy-prevention systems now present in commercial VHS tapes, newer audio CDs, DVDs, and other digital media. This provision has hardly diminished the operations of music and film pirates. Instead, the primary effect of the DMCA's anti-circumvention provision has been to trample on ``fair use'' rights --- legal allowances to duplicate copyrighted material for personal or educational use. It is illegal to produce a device that circumvents the copy-prevention system on VHS tapes or DVD discs, even if the intended use is simply creating a personal back-up copy, excerpting for academic purposes, or converting the media into an alternative format (e.g. close-captioning for a hearing-impaired audience).
More significantly, small, independent producers are excluded from the DMCA's protection, since most copy-prevention systems are only available to the largest media studios (either due to high costs or exclusive licensing arrangements). As an independent studio, we have not seen any benefit from the DMCA. In fact, on several occasions we have been forced to abandon projects because copy-prevention systems barred us from duplicating materials, rights to which we had properly and legally obtained!
I have learned of upcoming copyright initiatives that would further worsen the situation. The Security Systems Standards and Certification Act (SSSCA), introduced by Sen. Ernest Hollings at the behest of the Disney Company and other large studios, would outlaw all digital audio and video equipment that does not contain an integrated, tamper-proof copy-prevention system. This measure would make life extremely difficult for independent digital studios like my own, which have thrived on the availability of cheap, flexible digital equipment for editing (and thus necessarily duplicating) audio and video. Large media companies will escape through an exception in the law for ``professional'' recording devices --- which will likely be priced beyond the budget of a small studio. This is already the present situation with VHS players: cheap ``consumer'' players by law must incorporate the Macrovision copy-prevention system, while expensive ``professional'' players are excepted!
Thankfully the SSSCA was withdrawn, but mandatory copy-prevention equipment appears in several other upcoming proposals. One such measure is the Consumer Broadband and Digital Television Promotion Act (CBDTPA), also to be introduced by Sen. Hollings. The Act's supporters, all major media companies, claim that having copy-prevention hardware in all digital TV equipment is necessary for the widespread adoption of digital TV. I see no reason for this. Many other media, like analog TV, radio, and the audio CD, have thrived despite the absence of copy-prevention systems. My own studio has no qualms about digital distribution channels that do not mandate copy-prevention. One effect of mandatory copy-prevention equipment is clear though: it will completely lock out independent artists and studios who do not have the ability to encode their work with the proper copy-prevention signals. I strongly suspect that this is the true effect the established industry intends to create with the CBDTPA.
In light of these facts, I urge you to take the following actions:
Oppose the further expansion of copyright powers. Pre-DMCA copyright law was already strong enough to encourage the creation of vast numbers of film, music, and literary works.
Do not support mandatory copy-prevention or ``content protection'' systems, as embodied in such measures as the CBDTPA and SSSCA. Media pirates will inevitably find ways around these systems. Mandatory copy-prevention will only have the effect of strengthening the established media monopolies at the expense of independent studios, artists, and consumers.
Support the efforts of legislators such as Rep. Rick Boucher (D-VA), who is working to scale back the Draconian provisions of the DMCA and write ``fair use'' into law as a guaranteed right.
Support H.R. 5285 - the Internet Radio Fairness Act - which will lower the unreasonably high music royalty rates imposed on independent internet music broadcasters.
I can think of no better way to erode America's world leadership in film, music, and digital media than to destroy the abilities of creative artists to produce works, and of consumers to enjoy them. Expanding the control of existing large media companies may lead to higher short-term profits for them, but will surely cause severe long-term hardship for all of us.
The graph is really neat, but I am kind of disappointed that it doesn't show much inter-file information (the position of source file boxes is essentially arbitrary, and there are no indications of connections between them)...
One thing I would love to see is some kind of graph that shows the dependencies between source files. i.e. who calls functions in this file; who is called by functions in this file; what headers does this file depend on (taking recursive inclusions into account), etc. That kind of information is really important when trying to understand code, even my own. (e.g. it should be really easy to spot unwanted header dependencies which are otherwise difficult to detect).
I am aware of some scripts based on GraphViz, like "cinclude2dot.pl" But the results aren't really what I am looking for.
I do know of at least one individual owner of software patents - Raph Levien. But yeah, you are certainly right about the industry as a whole.
I think software patents might work if they were limited to a very short term (1-2 years, 3 at the very most). This way you'd be encouraged to go out, invent something, and try to make a profit from it right away - rather than lurking around in a dark corner waiting to surprise the industry with an unexpected patent attack. (which seems to be par for the course these days...)
I totally agree with you... The problem is that the accessibility of the internet flies in the face of traditional licensing models for film and music. Record and film studios are accustomed to portioning out the rights to their products in nice tidy chunks - US broadcast rights for year X, European broadcast rights for year Y, VHS disribution rights for Africa, airline/radio play rights, sequel rights, rights to re-use the content in other productions, etc. (it used to be that natural borders kept these categories separate; now they have to use artifical borders like the DVD region coding system).
But with internet distribution there is only one "right" to sell: once the content is on the net, anyone can get it, anywhere, anytime. While a tremendous boon for consumers, this completely destroys the old, picture-perfect system of nice little independent packages of "rights." And that is why traditional media companies are keeping their heads buried in the sand, horrified at the collapse of their nice neat rights packages, hoping that this whole internet distribution thing will finally blow over. They are praying for ubiquitous DRM systems to re-create all those nice little borders...
I do however think that where the lives of so many people are at stake, then licensing must be affordable.
But this is the whole problem - you can't both have your cake and eat it too. You either have to accept higher prices (and thus no treatment for the poor), or less medical R&D. I think there are justifications for either choice. (though personally I would prefer to see a very expensive treatment for disease X rather than no treatment at all... Patents do expire eventually, and so the price can't stay high forever.)
My experience: broadband is great, and worth the money - I can't live without it; but the service is getting worse, and the price increases. There is something wrong there that needs to be investigated.
Wow, that is exactly how I would describe my own situation. (AOL/TW Road Runner Cable in central New York State). I suspect it's just them "tightening the screws" on us customers - it's not like we can actually switch to a competitor or anything. Business as usual.
I dearly hope wireless networks will eventually lead to more competition. Third parties might have a better chance when they don't need to worry about getting control of the wires leading into your house. But then again the wireless phone industry seems to have a lot of the same old problems.
In Canada, which has nearly twice the geographic area of the US and a tenth the population, I and many of my friends have had 2 MBit DSL for over 4 years now, and now I can get cable modems for 8 MBit for the same price. How much, you ask? US$25.66 per month.
To be completely fair though, you have to figure in the higher taxes in Canada which help subsidize these low rates...
Thanks for the thoughtful comments... There are lots of other ways the government could try to incentivize the development of drugs for rare diseases; I was mainly trying to point out that a "one size fits all" approach to patent duration isn't necessarily the best for all industries...
BTW, I can't agree with arguments that go "the price of X is too high, because it's way above the cost of making X." The pricing of a monopoly producer (e.g. drug company or record label) is always above the cost of production - and much higher if the marginal unit cost is low (e.g. drugs and CDs). High-priced treatments are the inevitable result of private medical research. If you want private investment in medicine, you've got to pay the price. If you want all medicines to be cheap, that's easy, just force all medical research into the public domain - but don't expect as much R&D to occur due to the diminished returns.
Not exactly what you're asking for, but I can give you an example of an industry that could be better served by longer patent terms - pharmaceuticals. Drug companies often complain that they can't pursue development of medicines for rare diseases, because the drugs wouldn't be profitable enough to justify the investment. As a result, sufferers of these diseases are out of luck, no matter how long they wait.
I think the industry would clearly benefit from the careful application of lengthened patents for specific things, such as one of these useful but not very profitable drugs.
It's already been discussed on Slashdot - advertisements will be incorporated into the scenes of each TV show. It will become impossible to separate "ad" from "show" without blacking out large portions of the screen...
Personally I'd love to pay by the show - after all I only consider about 1% of the TV we pay for (~200 cable channels) worth watching. But the studios would probably balk at this because they'd have a hard time introducing new shows...
As some others have pointed out, Echostar is doing precisely what the GPL requires of them and nothing more. (they released the kernel code and some common shell utils, the PVR-specific stuff is still secret)
This is like making a Slashdot headline for a company that buys a license for each copy of Windows and Office it is using. Why are we so excited they just obeyed the license?
Slashdot Mirror
I am 99.99% certain that OSX 10.2 (Jaguar) uses hardware texture mapping to blit/composite offscreen window buffers to the desktop. (previous versions of OSX did NOT use the hardware like this; it is a new optimization in Jaguar). Any Mac website should have the details.
I am not sure why they wouldn't use better filtering for the window-scrunching effects. I haven't used Jaguar myself yet so I don't know if this has changed. (obviously bilinear filtering would be very expensive in pre-Jaguar software mode).
Thanks for your ideas on resizing... I think OSX does actually perform eager allocation when enlarging windows; the slow resizing that most OSX users complain about may simply be due to the software 2D rendering... One complicating factor is that, as far as I know, OSX requires that ALL pixels in ALL open windows be stored all the time, even for portions of the window that are outside the screen. (I assume this is to eliminate the need for "damage/repaint" events; however the memory costs are quite substantial...)
Have you actually benchmarked it though? I have done kernel traces of X interacting with client programs. The read()/write() overhead (copying data across the socket) is insignificant compared to the "extra round-trip" problems that spitzak describes.
I would never work on DRM software. Currently I spend hours each day writing software to try to let people do more with their computers. It's very difficult and time-consuming, and I'm not always successful... I'd hate to be writing software that makes people do less with technology. That's just a disgusting waste of resources.
As Apple says, copyright infringement is a social issue, not a technological one. The media industry thinks ubiquitous DRM is the solution, when all they need to do is offer their content for download cheaply, in plaintext formats.
OK, so non-official DHCP servers should be banned. The fact that some WAPs happen to include DHCP servers is incidental. (someone could also try to set up their own DHCP server with a Win2K or Linux box)...
NJ gave itself the right to regulate rides after an accident where two were killed from a malfunction, not excessive Gs.
I hate this kind of misdirected legislation. It's like the new airline baggage screening requirements (helllooo! The 9/11 hijackers did not have any dangerous checked baggage!). Or gun control laws being passed in reaction to violence committed with illegally-possessed guns. (they were already illegal, see?)
You are correct. Satire (using elements of a copyrighted work for comical/ludicrous effect) is not protected. Only parody (using elements of a copyrighted work to make fun of the work itself) is.
e.g. if a Saturday Night Live sketch featured actors dressed up as Star Wars characters in order to make fun of Star Wars, that would be fair use (parody). But if they were making fun of American politics (satire), they would need a license from Lucasfilm.
Of course this distinction is pretty ridiculous... It's the result of copyright holders successfully claiming that copyright is an absolute "property right" (which it is not).
One thing this article clearly shows is the polar opposite viewpoints that people tend to take - the "enlightened" let's-find-a-way-to-benefit-from-new-technology view (exemplified by the narrator) and the "backward" let's-keep-things-the-way-they've-always-been view (the photographer). I bet she'd love to hear about Microsoft's upcoming ubiquitous DRM system. ("you mean you can send out a file that can't be copied more than once? And they have to buy it again if their computer crashes? Awesome!")
Unfortunately the "backward" side seems to be winning. Look at DVDs - DVD video could have been specified in a neutral video format that would play on any player, anywhere in the world. But the MPAA film studios didn't feel like re-negotiating all of their exclusive regional distribution contracts, so they slapped on the Region Coding system. So we have regressed - there are now MORE barriers to international video distribution than the simple NTSC/PAL dichotomy of the analog world.
And since more barriers always benefit the producer, and the producers have Congress in their pockets, it's going to get worse...
I think the biggest problem you'd have in adopting a digital voting system would be making it simple enough so that most people could understand it.
I'm assuming that most US citizens (myself included) would probably not be confident in, or willing to adopt, a system that they can't easily understand and trust.
A pencil-and-paper system is simple enough that anyone can get it - check the box, a human counts it, there's your vote. Even our wacky electoral college system is probably within most people's grasp. But once you start talking about public-key encryption or digital signature algorithms, only a tiny percentage of citizens are going be able to keep up. (and most of that tiny percentage will be white males - providing endless ammunition for politically correct fear-mongering =).
A digital voting system of the necessary sophistication would be beyond most people's understanding, and thus subject to claims of manipulation. (regardless of the system's actual resistance to fraud)
I really like QT/KDE, but I have to admit that one of QT's basic flaws is that it is tied to a simple one-owner memory management scheme. As a result the Python binding was a disaster - the binding had no way to prevent a QT object from being deallocated, so if you did certain things (like remove a widget from a window), you could easily segfault the interpreter.
It would be great to have a nice C# binding, but I don't see how one could feasibly interface QT with a garbage-collecting language. It's pretty much designed to be used from C++ only.
Ah, I see... I don't do this kind of thing very often, but one example might be when I have two source code windows open and I'm alternating back and forth. I tend to set up the windows side-by-side, but since I write long lines they usually don't quite fit; they overlap a bit. And it's annoying because usually the wrong window is on top when I need it! Your suggestions would probably help in this case... But again this is pretty much the only example I can think of from my own experience, and you have to balance it against my years of conditioning with click-to-raise =).
One other issue that bears considering is minimizing switches between the mouse and keyboard. It may sound insignicant, but I really believe I work faster (and experience less hand/wrist stress) the more unnecessary trips to the mouse I can skip.
Of course what we really want isn't "point to type," it's "think to type" =)
Yes, we are definitely entering religious-war territory...
Re: point-to-type - I am undecided on this one. Most of the time it works great for me and it saves mouse clicks. However, sometimes it is annoying because I accidentally leave the mouse outside of where I was typing, and have to move my hand to it, re-point the mouse, and move back to continue typing. Also I don't really like the "wild light show" effect I get when moving the mouse around (titlebars changing colors as I activate/deactivate windows by moving over them).
Re: pointer warp - I'm pretty strongly against this; I don't like the feel of having the pointer out of my control. (I think what you really might be asking for is better positioning of dialog boxes - many Linux window managers do a terrible job of deciding where to put pop-up/dialog windows).
Re: not raising windows on click or move - I bet you have a very different strategy for arranging windows... Personally I hate it when I have to use a system that doesn't raise windows on click. But it's probably because I depend on this feature for my subconscious "desktop navigation." I'd have to sit down and try your method to see if it's better.
(I do change my mind sometimes - not long ago I couldn't figure out what the big deal was with "tabbed" web browsing - then I discovered how awesome it is, and now I can't stand browsers that don't support tabbing! It's just a much better way to work than opening N different browser windows).
Thanks for the comments! Some responses...
Re: exactly as many threads as CPUs - this is only possible if you have access to non-blocking APIs for everything (disk I/O, sockets, DNS lookups, libraries, etc). If you can only use standard read/write disk I/O, then you may need a pool of disk I/O threads to achieve enough parallelism.
Re: state machines being harder to write than threads - I actually disagree! I think many people have spent so much time learning all the concurrency control techniques (mutexes, semaphores, etc) that they forget what life was like before threads. e.g. consider that adding a mutex to a multithreaded program essentially doubles the program's state space (multiply "mutex locked" and "mutex unlocked" by all the existing states). But unlike a state machine, there is no way to control exactly when you enter or leave the state, and it's not always easy to even know what state you are in at any time (since thread scheduling is totally at the mercy of the OS kernel).
I can understand why people often implement "background tasks" like garbage collection and long-running computations as asynchronous threads. But in my own code I often do these things incrementally, explicitly interleaved with other actions. I don't find it terribly difficult, and I gain the advantage of explicit scheduling. (again threads are at the mercy of the kernel - you have NO control over when any background tasks actually run). And with threads you have to add in all that locking too... Finally, to my knowledge there is no portable way to terminate a background thread asynchronously without leaking memory or leaving some locks in an unknown state. The only safe way to shut threads down is to set a flag, and have the thread check it every so often. But if you're doing this then you are already half-way to an incremental state machine!
I'll finish with an example from a recent project - I wrote a real-time video player system that streams data from disk to an I/O card at a fixed rate. In order to get enough performance, I needed the disk I/O to take place asynchronously with respect to controlling the I/O card. Most people would use threads for this, but instead I used two forked processes - one constantly read data from disk and put it in a shared-memory buffer, the other read from the buffer and wrote to the card. The processes communicated through a pipe, so if the buffer got full or empty, the appropriate process would simply block in read() or write(). The design is simple, there is no need for locking (other than what UNIX pipes do automatically), and it only took me an hour or so to get it working =).
It's nice to know there are others out there who know state machines are the One True Way =). Ideally you have exactly as many threads as CPUs, and use non-blocking state machines for everything. (and unless the CPUs need to share a great deal of information, use processes rather than threads to side-step cache contention and locking; communicate with pipes or shared memory)
Unfortunately this ideal is sometimes hard to achieve because non-blocking APIs are not always available. (e.g. there is no way to poll/select a pipe on Windows, and true asynchronous file I/O is still in the testing stages on Linux)
Keeping this on topic - there are plenty of HTTP servers out there with more sane concurrency models - thttpd is one of many... (I can't really fault Apache for making the choices they did; their goals are more standards conformance and portability than raw speed).
I would actually place the blame for this on hardware makers, for making it so difficult to find out exactly what chipset is driving their product.
e.g. I was given a spare Asante ethernet card recently, and neither the vendor's site nor an extensive Google search could tell me what chipset it used. In desparation I peeled off the "Asante" sticker on the big chip in the middle of the board, and guess what, beneath the chip said "PNIC" on it. If the vendor had cared to mention its card was PNIC-based, I would not have had to waste so much time...
Network card makers seem to be the worst about this, followed by sound card companies. At least with video cards the chipset is usually part of the product name. (e.g. Super Whizbang Turbo Alpha Killer Mega GeForce 2)
I recently faxed the following letter to my Congressional representatives. Feel free to quote it in your own correspondence, with proper attribution of course. (apologies for the formatting; this is copied from LaTeX source)
I am proud to be both your constituent and the owner of a small but
successful digital video studio. I have become very alarmed by recent
changes to U.S. copyright law, and the direction in which it seems to
be heading. The tremendous powers the law has granted to copyright
owners, particularly large film and music studios, are having a
deleterious effect on independent producers (such as myself) as well
as consumers of these media.
Under the pretense of combating music and film piracy, the major
U.S. recording companies and film studios have recently obtained legal
powers that extend far beyond the reasonable, limited monopoly
conferred by traditional copyright law. For example, the 1998 Digital
Millennium Copyright Act (DMCA) outlawed the creation of tools that
circumvent the copy-prevention systems now present in commercial VHS
tapes, newer audio CDs, DVDs, and other digital media. This provision
has hardly diminished the operations of music and film
pirates. Instead, the primary effect of the DMCA's anti-circumvention
provision has been to trample on ``fair use'' rights --- legal
allowances to duplicate copyrighted material for personal or
educational use. It is illegal to produce a device that circumvents
the copy-prevention system on VHS tapes or DVD discs, even if the
intended use is simply creating a personal back-up copy, excerpting
for academic purposes, or converting the media into an alternative
format (e.g. close-captioning for a hearing-impaired audience).
More significantly, small, independent producers are excluded from the
DMCA's protection, since most copy-prevention systems are only
available to the largest media studios (either due to high costs or
exclusive licensing arrangements). As an independent studio, we have
not seen any benefit from the DMCA. In fact, on several occasions we
have been forced to abandon projects because copy-prevention systems
barred us from duplicating materials, rights to which we had
properly and legally obtained!
I have learned of upcoming copyright initiatives that would further
worsen the situation. The Security Systems Standards and Certification
Act (SSSCA), introduced by Sen. Ernest Hollings at the behest of the
Disney Company and other large studios, would outlaw all digital audio
and video equipment that does not contain an integrated, tamper-proof
copy-prevention system. This measure would make life extremely
difficult for independent digital studios like my own, which have
thrived on the availability of cheap, flexible digital equipment for
editing (and thus necessarily duplicating) audio and video. Large
media companies will escape through an exception in the law for
``professional'' recording devices --- which will likely be priced
beyond the budget of a small studio. This is already the present
situation with VHS players: cheap ``consumer'' players by law must
incorporate the Macrovision copy-prevention system, while expensive
``professional'' players are excepted!
Thankfully the SSSCA was withdrawn, but mandatory copy-prevention
equipment appears in several other upcoming proposals. One such
measure is the Consumer Broadband and Digital Television Promotion Act
(CBDTPA), also to be introduced by Sen. Hollings. The Act's
supporters, all major media companies, claim that having
copy-prevention hardware in all digital TV equipment is necessary for
the widespread adoption of digital TV. I see no reason for this. Many
other media, like analog TV, radio, and the audio CD, have thrived
despite the absence of copy-prevention systems. My own studio has no
qualms about digital distribution channels that do not mandate
copy-prevention. One effect of mandatory copy-prevention equipment is
clear though: it will completely lock out independent artists and
studios who do not have the ability to encode their work with the
proper copy-prevention signals. I strongly suspect that this is
the true effect the established industry intends to create with the
CBDTPA.
In light of these facts, I urge you to take the following actions:
Oppose the further expansion of copyright powers. Pre-DMCA
copyright law was already strong enough to encourage the creation of
vast numbers of film, music, and literary works.
Do not support mandatory copy-prevention or ``content
protection'' systems, as embodied in such measures as the CBDTPA and
SSSCA. Media pirates will inevitably find ways around these
systems. Mandatory copy-prevention will only have the effect of
strengthening the established media monopolies at the expense of
independent studios, artists, and consumers.
Support the efforts of legislators such as Rep. Rick Boucher
(D-VA), who is working to scale back the Draconian provisions of the
DMCA and write ``fair use'' into law as a guaranteed right.
Support H.R. 5285 - the Internet Radio Fairness Act - which will
lower the unreasonably high music royalty rates imposed on independent
internet music broadcasters.
I can think of no better way to erode America's world leadership in
film, music, and digital media than to destroy the abilities of
creative artists to produce works, and of consumers to enjoy
them. Expanding the control of existing large media companies may lead
to higher short-term profits for them, but will surely cause severe
long-term hardship for all of us.
The graph is really neat, but I am kind of disappointed that it doesn't show much inter-file information (the position of source file boxes is essentially arbitrary, and there are no indications of connections between them)...
One thing I would love to see is some kind of graph that shows the dependencies between source files. i.e. who calls functions in this file; who is called by functions in this file; what headers does this file depend on (taking recursive inclusions into account), etc. That kind of information is really important when trying to understand code, even my own. (e.g. it should be really easy to spot unwanted header dependencies which are otherwise difficult to detect).
I am aware of some scripts based on GraphViz, like "cinclude2dot.pl" But the results aren't really what I am looking for.
I do know of at least one individual owner of software patents - Raph Levien. But yeah, you are certainly right about the industry as a whole.
I think software patents might work if they were limited to a very short term (1-2 years, 3 at the very most). This way you'd be encouraged to go out, invent something, and try to make a profit from it right away - rather than lurking around in a dark corner waiting to surprise the industry with an unexpected patent attack. (which seems to be par for the course these days...)
I totally agree with you... The problem is that the accessibility of the internet flies in the face of traditional licensing models for film and music. Record and film studios are accustomed to portioning out the rights to their products in nice tidy chunks - US broadcast rights for year X, European broadcast rights for year Y, VHS disribution rights for Africa, airline/radio play rights, sequel rights, rights to re-use the content in other productions, etc. (it used to be that natural borders kept these categories separate; now they have to use artifical borders like the DVD region coding system).
But with internet distribution there is only one "right" to sell: once the content is on the net, anyone can get it, anywhere, anytime. While a tremendous boon for consumers, this completely destroys the old, picture-perfect system of nice little independent packages of "rights." And that is why traditional media companies are keeping their heads buried in the sand, horrified at the collapse of their nice neat rights packages, hoping that this whole internet distribution thing will finally blow over. They are praying for ubiquitous DRM systems to re-create all those nice little borders...
I do however think that where the lives of so many people are at stake, then licensing must be affordable.
But this is the whole problem - you can't both have your cake and eat it too. You either have to accept higher prices (and thus no treatment for the poor), or less medical R&D. I think there are justifications for either choice. (though personally I would prefer to see a very expensive treatment for disease X rather than no treatment at all... Patents do expire eventually, and so the price can't stay high forever.)
My experience: broadband is great, and worth the money - I can't live without it; but the service is getting worse, and the price increases. There is something wrong there that needs to be investigated.
Wow, that is exactly how I would describe my own situation. (AOL/TW Road Runner Cable in central New York State). I suspect it's just them "tightening the screws" on us customers - it's not like we can actually switch to a competitor or anything. Business as usual.
I dearly hope wireless networks will eventually lead to more competition. Third parties might have a better chance when they don't need to worry about getting control of the wires leading into your house. But then again the wireless phone industry seems to have a lot of the same old problems.
In Canada, which has nearly twice the geographic area of the US and a tenth the population, I and many of my friends have had 2 MBit DSL for over 4 years now, and now I can get cable modems for 8 MBit for the same price. How much, you ask? US$25.66 per month.
To be completely fair though, you have to figure in the higher taxes in Canada which help subsidize these low rates...
Thanks for the thoughtful comments... There are lots of other ways the government could try to incentivize the development of drugs for rare diseases; I was mainly trying to point out that a "one size fits all" approach to patent duration isn't necessarily the best for all industries...
BTW, I can't agree with arguments that go "the price of X is too high, because it's way above the cost of making X." The pricing of a monopoly producer (e.g. drug company or record label) is always above the cost of production - and much higher if the marginal unit cost is low (e.g. drugs and CDs). High-priced treatments are the inevitable result of private medical research. If you want private investment in medicine, you've got to pay the price. If you want all medicines to be cheap, that's easy, just force all medical research into the public domain - but don't expect as much R&D to occur due to the diminished returns.
Not exactly what you're asking for, but I can give you an example of an industry that could be better served by longer patent terms - pharmaceuticals. Drug companies often complain that they can't pursue development of medicines for rare diseases, because the drugs wouldn't be profitable enough to justify the investment. As a result, sufferers of these diseases are out of luck, no matter how long they wait.
I think the industry would clearly benefit from the careful application of lengthened patents for specific things, such as one of these useful but not very profitable drugs.
It's already been discussed on Slashdot - advertisements will be incorporated into the scenes of each TV show. It will become impossible to separate "ad" from "show" without blacking out large portions of the screen...
Personally I'd love to pay by the show - after all I only consider about 1% of the TV we pay for (~200 cable channels) worth watching. But the studios would probably balk at this because they'd have a hard time introducing new shows...
As some others have pointed out, Echostar is doing precisely what the GPL requires of them and nothing more. (they released the kernel code and some common shell utils, the PVR-specific stuff is still secret)
This is like making a Slashdot headline for a company that buys a license for each copy of Windows and Office it is using. Why are we so excited they just obeyed the license?