Re:A very different potential hole in the GPL...
on
Hole in GNU GPL?
·
· Score: 1
I agree with this, which is why I specifically posited a situation whereby the "key" is NOT written down, but merely stored in someone's head. Since it is not part of a file anywhere, and is never generated (it's merely typed in on the command line), it's harder to call it part of the source.
Actually doing this is likely to be very difficult in practice, and it's entirely possible that it wouldn't hold up (being a clear attempt to get around something with very obvious meaning), but I wouldn't put it entirely past someone to try it...
SourceForge is a service provided by VA to the open source community. The URL is sourceforge.net. They provide a complete hosting solution, including disk space, CVS repository, mailing lists, web space, and many other services that I'm only starting to explore. It appears to be well funded, with three people and quite a stack of hardware. I'm trying it for my own project, enhancing the Print plugin for the Gimp (check it out, although I only got started yesterday with SourceForge).
Another possibility would be to contact Red Hat and VA to see if they would be interested in funding your project (i. e. hiring you as an employee or a consultant).
The copyright holder is not bound by the GPL. The GPL only binds others. So the copyright holder can release the code under any terms and conditions s/he chooses, including different licenses for different purposes.
However, there's a catch to all this. If you release code under the GPL, then any modifications to it are also GPL. This means that you cannot take changes that other people make and relicense them under a proprietary license. So you either have to refrain from using changes others make, unless you get their permission (they hold copyright to their code, and it's under the GPL, so you're bound WRT their code), or you use a license like the MPL (which as I understand it is designed for this situation). However, the free software community seems less eager to contribute to MPL projects than GPL (understandable, because they're giving someone else the right to use their code in a proprietary product).
A very different potential hole in the GPL...
on
Hole in GNU GPL?
·
· Score: 2
There's a very different potential way to get around the GPL. Thus far it's purely theoretical (so far as I know). It's essentially a cryptographic attack.
Section 3 of the GPL reads in part:
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
Here's the catch, though. It doesn't say that the actual commands used to build the executable must be configured. So the source code could be obfuscated by a stack of #ifdef's. The actual command to build the (modified) source is
make CFLAGS='-DA0=1 -DA1=0 -DA2=1...'
See where I'm going? The sequence of preprocessor definitions on the command line amounts to a cryptographic key. If the wrong "key" is entered the program might not compile, or it might simply do something different. If this is done pervasively in the modifications it might be impossible to use the source code in practice.
This, again, is a theoretical attack, and would take a lot of work to do in practice. There would also be the risk of whoever's distributing the software forgetting the key, since including it in the script would amount to it being part of the required source.
When I mentioned this to RMS, he wasn't terribly worried about it. I don't think it's all that great of a concern in practice, but it's interesting to think about...
A patent is a government grant of a monopoly to a private individual. It's not even remotely based on the notion of a contract, as copyright could be construed to be (not that I'm in favor of very strong copyright "protection" either, but that's another matter), or a matter of honest identification (as trademarks are).
Oddly, I'm not really a libertarian. I do believe that there's a legitimate role for government that extends beyond the military and protection of private property. I just don't think that the government should extend to one individual the right to forbid others from using knowledge, whatever the benefits may (or may not) be. I guess that in this regard I go even further than RMS. So be it.
I could envision some kind of voluntary patent system, where individuals or corporations could opt in or out of in its entirety (opting in or out of individual patents is obviously ludicrous). So those of us who are opposed to patents could opt out of the patent system entirely -- we would not be bound by any patents, but we could not file for, contribute any work to, or hold any either.
There are obvious practical problems here -- how does one switch sides, as it were? The obvious solution is that one can change sides, but with a mandatory two-year waiting period during which time one is bound by the patent system but cannot receive any benefit from it.
That's only the start of things, too -- how to handle issues of employees pursuing their own interests vs. employers on the other side of the fence (either direction); patent-free subsidiaries of opted-in holding companies, and so forth. But it strikes me as an interesting idea, at least as an intellectual exercise (and possibly, in the long run, a way out of the current mess).
If the main objection is to patents per se, then I would say we are a bunch of hypocrytes. The whole high tech industry which produces all the goodies we love to play with is driven by patents. IBM is not going to spend billions researching "copper" etc. and give as those lovely gigahertz processors if some company in tiawan can rip off the design as soon as it is working.
Hypocrisy is a bit strong; just because someone is opposed to something that provides them with a benefit doesn't make that person hypocritical. What would be hypocritical (IMHO) is one who opposes patents in general but supports them for his particular purpose.
I'm opposed to patents in general. There may be reason in the pharmaceutical industry (note that I work in the software industry, not the pharmaceutical industry) due to the heavy regulatory burden that is faced (drug trials and all that). Even there, I would prefer explicit compensation for their expenses or outright subsidies over patents.
If nothing else, I simply think it's wrong for the government to grant an individual a monopoly on the use of an idea.
Corel fixed their first license. Their second one still had the over-18 clause, but that apparently passed muster with RMS. If I remember correctly, the wording was such that it only restricted who was allowed to download from their site to those who are of legal age to bind to a contract. It did not restrict use or further distribution. If my memory is correct on that point, that's not much different from the FSF agreeing to give you a tape only if you agree to pay them for it.
A film consisting of continuous still shots is another matter. I still think that for most mass market films this resolution would be quite adequate. And it wouldn't have other problems, such as dust on the print and all that...
I'm an (amateur, but serious) photographer. I do indeed like using Fuji Velvia and other fine grained, high resolution films wherever practical. I use a tripod whenever I can. So why do I think that a resolution that would be unacceptable for me for serious photography would be just fine for movies?
Last night I printed one of our wedding photographs on my Epson Stylus Photo EX (and before anyone starts commenting on this gross violation of copyright, not to mention photographic etiquette, I'll point out that our deal with the photographer included throwing in the negatives and all that). This was a fairly low resolution scan (1280x1024, I did it for a screen background). The print is on an 11x17 piece of glossy film. It's using the Gimp's print plugin that Michael Sweet originally wrote that I've enhanced (URL below). I can see the pixelation -- if I look at it carefully from less than 12" away with my left eye, which has unusually acute close-in vision. Even then I can only see the pixelation in sharp transitions, such as between my tuxedo jacket and my shirt where the line is only about 15 degrees off parallel. It's obvious if I look reasonably carefully that it's not as sharp as a good quality photographic print, but it doesn't look pixelized.
And the point is? A movie theatre is not an optimal location for spotting imperfections. For one, it's in constant motion, so it's usually impossible to focus on any one spot for long enough to see any artifacts. Secondly, if the projector is even slightly out of focus, any pixelation will be blurred out of existence.
I'm not an expert on motion picture film, but the resolution enhancement over normal 35 mm film is not as great as the 70 mm format would lead one to believe. Taking into account the sprocket holes and the soundtrack, I'd be surprised if the actual frame width on 70 mm movie film is greater than 50 mm or thereabouts. If it's 50 mm wide, the length of a frame should be about 27 mm (at least if the depiction at http://www.theatres.sre.sony.com/imax/film.html is reasonably accurate -- the long side of the film stretches across the width, rather than the length). 35 mm still film is 24x36. So the movie frame is bigger than the 35 mm frame, but not spectacularly so (it's smaller than the smallest "medium format" photographic format, which is nominally 60x45 mm but actually a bit less). High end consumer digital cameras are currently in the range of 1800x1200 pixels, and they produce quite satisfactory non-critical prints.
2 Mp resolution might not be sufficient for Imax (very large format, with a huge screen), particularly at theatres such as the Omnimax at the Boston Science Museum), but I suspect that for most motion picture purposes, it's quite adequate.
Death Wish actually has a good reputation. And I think they move a lot of stuff besides pianos, but people know who they are. Of course, there's also Gentle Giant. That's actually a good name for a moving company.
All of this is, IMHO, simply a reflection on the general spinelessness of contemporary American business. People can't afford to trust something that isn't done by large, faceless bureaucracies because they're afraid they'll be sued for not doing their due diligence.
It's all part of the "the only thing that matters is that there's someone else to blame" mentality. It's really sad that punditi like Jesse Berst can get away with actually saying in print that that's a good reason not to use Linux.
(I used to work for Thinking Machines. Whatever one might say about the company, the name was actually distinctive. There was a slogan there that predated me -- for obvious reasons, they couldn't really use it -- "When we say thinking, we mean business!" It helps to know that they tried to call themselves International Thinking Machines at one point. There were plenty of other problems with that outfit, but name recognition wasn't one of them.)
Will it be possible to turn off session management? A major reason that I don't use KDE is that it wants to restore my previous session. I personally prefer to restart all of my apps through my.xinitrc (or perhaps through some kind of explicit startup mechanism); I really don't want my previous session restored automatically.
Actually, it makes eminent sense in its own way. I'll have to give 4.0 a try with GNU Emacs. Unfortunately, there are a few behaviors of XEmacs that I haven't figured out how to turn off that make it simply too unpleasant for me to use (the two most notably that you have to actually turn on the region -- I like the GNU Emacs behavior that the region is always active; I can't stand having to do something just to kill off a huge blob of text -- and that if you type with the region active the active region is replaced, rather than text simply being inserted. Grr...).
I do use emacs to read mail (rmail) and news (gnus), and it would be nice to really be able to do all my web stuff in that environment. Same reason that a lot of people like office suites, I guess.
That said, I would not want emacs lisp to be a scripting language; it simply wasn't designed for any real security. Personally I'd just as soon have no client-side smarts at all beyond rendering and supplying cookies on demand, but whatever.
None of the scenarios anyone has presented look (to my untrained eye, at any rate) like they're covered:
It only covers trademarks that are distinctive at the time of registration. So somebody can't register a trademark and then go after someone who previously had the domain registered.
If it comes to trial, the court is suggested to consider issues such as any (other) trademarks that the person registering the domain may have referring to the domain name, whether the domain name consists of the person's legal name, prior lawful commercial use, lawful noncommercial or fair use, etc.
Read the bill. The last time this came up, a number of people noted that it was actually well written.
In short, we can treat integration and maintenance as requirements.
Indeed. That's probably the best way I've seen this expressed.
Like anything, it's possible to analyze a particular project and decide that integration with something else, or maintenance, are not important. But if people at least start with the viewpoint that these requirements are just as valid as any other functionality/performance requirements, there's some hope that they'll treat these issues with the respect that they deserve and make rational decisions.
Do you believe that the purchase of a $20,000 case tool would make a methodology work even if no one understands the system?
Of course not, and that's half the problem. My point is that open source projects typically don't even have an opportunity to go down this rathole. It's usually companies that want to change themselves and decide that they should buy a packaged solution from a guru.
What usually seems to happen is that some aggressive manager or wannabe brings one of these things in, to prove (maybe to themselves, I don't like to believe that they're all intentionally dishonest) that they're up with the latest technology.
Basically, my take on this (and I'm fighting the same battle where I am, where we don't use anything particularly fancy) is that the best process support programmers can give each other is to simply write everything down in a reasonably well organized fashion. I started my current job only about 3 months ago, and since then I've been making a lot of noise about the lack of process documentation and (more importantly, IMHO) writing a process document (read: web page) myself explaining how to actually build our software from scratch. My manager agrees with me, but I'm trying to work with him to come up with some way to make people understand that
writing things down is every bit as important as coding, and that
the amount of time wasted because knowledge isn't at hand is significant, and is probably greater than the amount of time saved by not writing it all down.
Quality circles are one of the few recent fads that I actually like, because they're simple, they're based on accumulating knowledge about best practices (or rather, "what works"), and they work off of recognition. Actually, of course, they're not all that new.
I'd rather not worry about "really good" process improvement to start out with; it's better to simply take a deep breath and understand what's actually going on, and do a few simple things that people can understand that have a recognizable early payoff.
I've decided over the years that engineering is 90% common sense applied to 10% specialized knowledge. The civil and mechanical and chemical engineers have understood this all along. You don't go build a chemical plant and add all sorts of fancy wheezes and gizmos and then skimp on the operating manual, because you'll have an explosion on your hands very quickly. But software's easy and cheap to change (you can guess what my real thoughts on that matter are, both as to veracity and consequences), and if it fails maybe the machine just reboots. We also studied "computer science", so we think that our work can be reduced to formula and applied as though it's the first law of thermodynamics. What we really are is a bunch of overgrown high school hot shots who think that because we can write code that makes computers do really neat things that we're somehow better than everyone else and that basic principles of system design don't apply to us (either we can be fast and loose, or we can follow a magic cookbook and everything will turn out right in the end). Well, the old timers can teach still teach us a few lessons that they learned on the knee of their ancestors.
2) Company tries to do too much and winds up with feature-packed garbage that's eons late and getting later in real time.
3) Company gets religion about engineering standards and practices and tries following the methodology de l'heur.
4) Next release is just as bad, partly because everyone has been fumbling over methodology.
5) Everyone forgets the good intentions altogether and goes back to the usual chaos
Note that this doesn't strictly have to apply only to commercial software, but open source projects typically don't have the money to go out and buy the fancy stuff. Also, there aren't many open source project leaders who could force that kind of nonsense on unwilling engineers.
As I read the review, though, this book isn't advocating that kind of approach; it sounded more like an iterative kind of thing that in practice is the only thing that can really work.
If Linux had not been open sourced (I believe that the GPL was a particularly critical choice, for reasons I'll get into below), I doubt very much that we'd even be hearing about it. Possibly there'd be something else that would have been open source that we'd have heard about, possibly (but I suspect not) BSD would have filled the void. That's just a guess, of course.
Linux got a lot of very powerful (not in the financial/political sense, but in the technical and later marketing sense) mindshare concentrated around it fairly quickly. IMHO, that is why it survived and thrived -- there were a lot of people out there who were attracted to that kind of project, who had the oomph needed to make it work.
BSD has, as I see it, three disadvantages from this standpoint:
1) The development model is closed -- it's a very tight core of people. That makes it hard for new people to jump on board. The BSD folks seem to like to tout it as an advantage. I don't think so. Whatever advantage there may be in having a small core of very highly qualified people and not having to worry about "substandard" code is more than outweighed by the sheer creative energy and new ideas unleashed by the openness of the Linux development process.
2) BSD's been around a lot longer and has gotten a bit stale. This partly related to (1), but partly it's also the natural tendency of something that has been around for a long time getting tired. I don't intend this as harshly as it comes across (and I'm well aware that it sounds nasty, although that's not my intent). The BSD folks are dedicated and very good, but they've been working on the same thing for a long time (in their various camps). Linux doesn't have a lot of baggage, and it's a lot easier to try new things. Of course, this implies that in 5-10 years Linux will be in much the same position. Probably it will. Linus tries to stave it off (he said this somewhere a year or two ago) by being picky about what goes into the kernel, and the greater turnover of developers is probably also healthy, but it's also not the be-all and end-all of systems. Eventually it's going to get tired too, and somebody else will come up with something better.
3) The GPL. It's really a finely tuned instrument for maximizing code availability and minimizing the destructive kind of forking. This, more than anything else, is RMS's greatest contribution. The really nifty thing about the GPL is that it ensures that all changes that anyone wants to distribute to anyone are made available to everyone, but it also ensures that nobody has any premature veto over anything. Linus can decide what he'll put into the Linux kernel that he distributes, but he can't stop anyone from distributing something else. Likewise, somebody else can't take the Linux kernel, make useful but proprietary changes, and force a split (particularly when other people make other changes with incompatible licensing, and force people to choose). The first effect ensures that Linus stays on his toes; he can't ignore something very useful that someone else has done just because he doesn't like that person -- he can ignore the specific bit of code, but if enough people like it, he'll eventually have to allow in something that does what's desired. It also exposes all new ideas to the light of day very quickly, where the market -- not the "owner" -- can evaluate them. The second ensures -- in a PRACTICAL sense -- that things can't get so incompatible that everything gets out of hand.
Whatever the theoretical risks of forking (which are much overblown, to put it mildly), the GPL is probably the one form of public license that allows for wide-open public participation but really does have great immunity against forking. As Vinod put it in Halloween (2?), being able to fix bugs or add features -- and then contributing them back, and seeing them get public use -- is very empowering.
It's very nice to be able to sit back and say "I have some code in the Linux kernel that millions of people are using" even if it's some trivial little thing (in my case, it's something like a 5-line patch to speed up argv handling in exec()). I suspect that that factor has a much bigger part to play in the early success of Linux than many give it credit for -- there was nothing else around at the time that did that.
Then we have another feature of the GPL -- the Great Equalizer. Some people say that the GPL is very business-unfriendly, since it doesn't allow for proprietary enhancements, and that the BSD license should be preferred on those grounds. I think not; the fact that your competitor is under the same constraints makes for a very equal situation. Under the BSD license, if you want to add value and resell it, you almost have to make your changes proprietary, because otherwise your competitor can take your public changes and put them into a proprietary product. The GPL forbids this; you can make a useful change and contribute it back with no fear that your competitor can use your own work against you. So everyone is equal under it; nobody can steal an advantage by means of hiding information; you need to execute better.
There's no such thing as complete freedom; there do have to be basic ground rules to ensure some basic level of cooperation, or else there are too many people who are looking to twist things to their short term advantage. That's where the GPL excels. And that, I think, is a big part of why Linux got where it is today. That, and executing well.
Whether this is new or not (and I suspect that it's fairly unusual for a major publication to offer an article for review to a broad audience), Jon did identify and describe this phenomenon, and backed it up with a strong case study. Doing something isn't enough; only by recording and analyzing it is it possible to add it to our portfolio of ways of doing things.
I've used Solid, and it works pretty well. It's a lot simpler to administer than Oracle, and it fully supports transactions, with various concurrency options. Check out www.solidtech.com. I've used it personally, although it was really as an object repository rather than a large data store. It has a good ODBC driver, and it exists for many systems.
The problem is in the VM system, not the filesystem. The 64-bit read/write/open system calls are in glibc presumably because other operating systems support them; I don't know what happens with them on Linux (they probably degrade to the normal 32-bit ones, and the library simply translates the parameters).
In any event, it doesn't matter with Oracle, or Solid, or any other halfway rationally designed database. They all allow multiple tablespaces, or datafiles, or whatever you want to call it. It isn't simply a matter of 32-bit compatibility either; there's the little matter of disk/filesystem limits and load sharing.
Slashdot Mirror
I agree with this, which is why I specifically posited a situation whereby the "key" is NOT written down, but merely stored in someone's head. Since it is not part of a file anywhere, and is never generated (it's merely typed in on the command line), it's harder to call it part of the source.
Actually doing this is likely to be very difficult in practice, and it's entirely possible that it wouldn't hold up (being a clear attempt to get around something with very obvious meaning), but I wouldn't put it entirely past someone to try it...
SourceForge is a service provided by VA to the open source community. The URL is sourceforge.net. They provide a complete hosting solution, including disk space, CVS repository, mailing lists, web space, and many other services that I'm only starting to explore. It appears to be well funded, with three people and quite a stack of hardware. I'm trying it for my own project, enhancing the Print plugin for the Gimp (check it out, although I only got started yesterday with SourceForge).
Another possibility would be to contact Red Hat and VA to see if they would be interested in funding your project (i. e. hiring you as an employee or a consultant).
The copyright holder is not bound by the GPL. The GPL only binds others. So the copyright holder can release the code under any terms and conditions s/he chooses, including different licenses for different purposes.
However, there's a catch to all this. If you release code under the GPL, then any modifications to it are also GPL. This means that you cannot take changes that other people make and relicense them under a proprietary license. So you either have to refrain from using changes others make, unless you get their permission (they hold copyright to their code, and it's under the GPL, so you're bound WRT their code), or you use a license like the MPL (which as I understand it is designed for this situation). However, the free software community seems less eager to contribute to MPL projects than GPL (understandable, because they're giving someone else the right to use their code in a proprietary product).
There's a very different potential way to get around the GPL. Thus far it's purely theoretical (so far as I know). It's essentially a cryptographic attack.
Section 3 of the GPL reads in part:
Here's the catch, though. It doesn't say that the actual commands used to build the executable must be configured. So the source code could be obfuscated by a stack of #ifdef's. The actual command to build the (modified) source is
make CFLAGS='-DA0=1 -DA1=0 -DA2=1...'
See where I'm going? The sequence of preprocessor definitions on the command line amounts to a cryptographic key. If the wrong "key" is entered the program might not compile, or it might simply do something different. If this is done pervasively in the modifications it might be impossible to use the source code in practice.
This, again, is a theoretical attack, and would take a lot of work to do in practice. There would also be the risk of whoever's distributing the software forgetting the key, since including it in the script would amount to it being part of the required source.
When I mentioned this to RMS, he wasn't terribly worried about it. I don't think it's all that great of a concern in practice, but it's interesting to think about...
A patent is a government grant of a monopoly to a private individual. It's not even remotely based on the notion of a contract, as copyright could be construed to be (not that I'm in favor of very strong copyright "protection" either, but that's another matter), or a matter of honest identification (as trademarks are).
Oddly, I'm not really a libertarian. I do believe that there's a legitimate role for government that extends beyond the military and protection of private property. I just don't think that the government should extend to one individual the right to forbid others from using knowledge, whatever the benefits may (or may not) be. I guess that in this regard I go even further than RMS. So be it.
I could envision some kind of voluntary patent system, where individuals or corporations could opt in or out of in its entirety (opting in or out of individual patents is obviously ludicrous). So those of us who are opposed to patents could opt out of the patent system entirely -- we would not be bound by any patents, but we could not file for, contribute any work to, or hold any either.
There are obvious practical problems here -- how does one switch sides, as it were? The obvious solution is that one can change sides, but with a mandatory two-year waiting period during which time one is bound by the patent system but cannot receive any benefit from it.
That's only the start of things, too -- how to handle issues of employees pursuing their own interests vs. employers on the other side of the fence (either direction); patent-free subsidiaries of opted-in holding companies, and so forth. But it strikes me as an interesting idea, at least as an intellectual exercise (and possibly, in the long run, a way out of the current mess).
There's a little bit of irony in the juxtaposition of claims of @Stake's vendor neutrality and L0pht's KMFMS button, methinks...
As someone who worked for Dan Geer at Athena, though, I can certainly vouch for his personal integrity. Very sharp (and very low key), too...
Hypocrisy is a bit strong; just because someone is opposed to something that provides them with a benefit doesn't make that person hypocritical. What would be hypocritical (IMHO) is one who opposes patents in general but supports them for his particular purpose.
I'm opposed to patents in general. There may be reason in the pharmaceutical industry (note that I work in the software industry, not the pharmaceutical industry) due to the heavy regulatory burden that is faced (drug trials and all that). Even there, I would prefer explicit compensation for their expenses or outright subsidies over patents.
If nothing else, I simply think it's wrong for the government to grant an individual a monopoly on the use of an idea.
Corel fixed their first license. Their second one still had the over-18 clause, but that apparently passed muster with RMS. If I remember correctly, the wording was such that it only restricted who was allowed to download from their site to those who are of legal age to bind to a contract. It did not restrict use or further distribution. If my memory is correct on that point, that's not much different from the FSF agreeing to give you a tape only if you agree to pay them for it.
http://www.tiac.net/users/rlk/print-3.0.2.tar.gz
Particularly if you have an Epson Stylus printer (vintage Photo EX or older), and you're running the Gimp 1.1, you might want to give this a try.
A film consisting of continuous still shots is another matter. I still think that for most mass market films this resolution would be quite adequate. And it wouldn't have other problems, such as dust on the print and all that...
I'm an (amateur, but serious) photographer. I do indeed like using Fuji Velvia and other fine grained, high resolution films wherever practical. I use a tripod whenever I can. So why do I think that a resolution that would be unacceptable for me for serious photography would be just fine for movies?
Last night I printed one of our wedding photographs on my Epson Stylus Photo EX (and before anyone starts commenting on this gross violation of copyright, not to mention photographic etiquette, I'll point out that our deal with the photographer included throwing in the negatives and all that). This was a fairly low resolution scan (1280x1024, I did it for a screen background). The print is on an 11x17 piece of glossy film. It's using the Gimp's print plugin that Michael Sweet originally wrote that I've enhanced (URL below). I can see the pixelation -- if I look at it carefully from less than 12" away with my left eye, which has unusually acute close-in vision. Even then I can only see the pixelation in sharp transitions, such as between my tuxedo jacket and my shirt where the line is only about 15 degrees off parallel. It's obvious if I look reasonably carefully that it's not as sharp as a good quality photographic print, but it doesn't look pixelized.
And the point is? A movie theatre is not an optimal location for spotting imperfections. For one, it's in constant motion, so it's usually impossible to focus on any one spot for long enough to see any artifacts. Secondly, if the projector is even slightly out of focus, any pixelation will be blurred out of existence.
I'm not an expert on motion picture film, but the resolution enhancement over normal 35 mm film is not as great as the 70 mm format would lead one to believe. Taking into account the sprocket holes and the soundtrack, I'd be surprised if the actual frame width on 70 mm movie film is greater than 50 mm or thereabouts. If it's 50 mm wide, the length of a frame should be about 27 mm (at least if the depiction at http://www.theatres.sre.sony.com/imax/film.html is reasonably accurate -- the long side of the film stretches across the width, rather than the length). 35 mm still film is 24x36. So the movie frame is bigger than the 35 mm frame, but not spectacularly so (it's smaller than the smallest "medium format" photographic format, which is nominally 60x45 mm but actually a bit less). High end consumer digital cameras are currently in the range of 1800x1200 pixels, and they produce quite satisfactory non-critical prints.
2 Mp resolution might not be sufficient for Imax (very large format, with a huge screen), particularly at theatres such as the Omnimax at the Boston Science Museum), but I suspect that for most motion picture purposes, it's quite adequate.
Death Wish actually has a good reputation. And I think they move a lot of stuff besides pianos, but people know who they are. Of course, there's also Gentle Giant. That's actually a good name for a moving company.
It's all part of the "the only thing that matters is that there's someone else to blame" mentality. It's really sad that punditi like Jesse Berst can get away with actually saying in print that that's a good reason not to use Linux.
(I used to work for Thinking Machines. Whatever one might say about the company, the name was actually distinctive. There was a slogan there that predated me -- for obvious reasons, they couldn't really use it -- "When we say thinking, we mean business!" It helps to know that they tried to call themselves International Thinking Machines at one point. There were plenty of other problems with that outfit, but name recognition wasn't one of them.)
Does that symbolize that company's desire to devour the world?
Will it be possible to turn off session management? A major reason that I don't use KDE is that it wants to restore my previous session. I personally prefer to restart all of my apps through my .xinitrc (or perhaps through some kind of explicit startup mechanism); I really don't want my previous session restored automatically.
Actually, it makes eminent sense in its own way. I'll have to give 4.0 a try with GNU Emacs. Unfortunately, there are a few behaviors of XEmacs that I haven't figured out how to turn off that make it simply too unpleasant for me to use (the two most notably that you have to actually turn on the region -- I like the GNU Emacs behavior that the region is always active; I can't stand having to do something just to kill off a huge blob of text -- and that if you type with the region active the active region is replaced, rather than text simply being inserted. Grr...).
I do use emacs to read mail (rmail) and news (gnus), and it would be nice to really be able to do all my web stuff in that environment. Same reason that a lot of people like office suites, I guess.
That said, I would not want emacs lisp to be a scripting language; it simply wasn't designed for any real security. Personally I'd just as soon have no client-side smarts at all beyond rendering and supplying cookies on demand, but whatever.
None of the scenarios anyone has presented look (to my untrained eye, at any rate) like they're covered:
Read the bill. The last time this came up, a number of people noted that it was actually well written.
Indeed. That's probably the best way I've seen this expressed.
Like anything, it's possible to analyze a particular project and decide that integration with something else, or maintenance, are not important. But if people at least start with the viewpoint that these requirements are just as valid as any other functionality/performance requirements, there's some hope that they'll treat these issues with the respect that they deserve and make rational decisions.
Of course not, and that's half the problem. My point is that open source projects typically don't even have an opportunity to go down this rathole. It's usually companies that want to change themselves and decide that they should buy a packaged solution from a guru.
What usually seems to happen is that some aggressive manager or wannabe brings one of these things in, to prove (maybe to themselves, I don't like to believe that they're all intentionally dishonest) that they're up with the latest technology.
Basically, my take on this (and I'm fighting the same battle where I am, where we don't use anything particularly fancy) is that the best process support programmers can give each other is to simply write everything down in a reasonably well organized fashion. I started my current job only about 3 months ago, and since then I've been making a lot of noise about the lack of process documentation and (more importantly, IMHO) writing a process document (read: web page) myself explaining how to actually build our software from scratch. My manager agrees with me, but I'm trying to work with him to come up with some way to make people understand that
Quality circles are one of the few recent fads that I actually like, because they're simple, they're based on accumulating knowledge about best practices (or rather, "what works"), and they work off of recognition. Actually, of course, they're not all that new.
I'd rather not worry about "really good" process improvement to start out with; it's better to simply take a deep breath and understand what's actually going on, and do a few simple things that people can understand that have a recognizable early payoff.
I've decided over the years that engineering is 90% common sense applied to 10% specialized knowledge. The civil and mechanical and chemical engineers have understood this all along. You don't go build a chemical plant and add all sorts of fancy wheezes and gizmos and then skimp on the operating manual, because you'll have an explosion on your hands very quickly. But software's easy and cheap to change (you can guess what my real thoughts on that matter are, both as to veracity and consequences), and if it fails maybe the machine just reboots. We also studied "computer science", so we think that our work can be reduced to formula and applied as though it's the first law of thermodynamics. What we really are is a bunch of overgrown high school hot shots who think that because we can write code that makes computers do really neat things that we're somehow better than everyone else and that basic principles of system design don't apply to us (either we can be fast and loose, or we can follow a magic cookbook and everything will turn out right in the end). Well, the old timers can teach still teach us a few lessons that they learned on the knee of their ancestors.
What I've typically seen happen is:
1) Company goes along producing software
2) Company tries to do too much and winds up with feature-packed garbage that's eons late and getting later in real time.
3) Company gets religion about engineering standards and practices and tries following the methodology de l'heur.
4) Next release is just as bad, partly because everyone has been fumbling over methodology.
5) Everyone forgets the good intentions altogether and goes back to the usual chaos
Note that this doesn't strictly have to apply only to commercial software, but open source projects typically don't have the money to go out and buy the fancy stuff. Also, there aren't many open source project leaders who could force that kind of nonsense on unwilling engineers.
As I read the review, though, this book isn't advocating that kind of approach; it sounded more like an iterative kind of thing that in practice is the only thing that can really work.
With a sufficiently finegrained filter, you can accept banner ads on selected pages while refusing them from elsewhere. Check out the referer: field.
(Myself, I refuse Doubleclick and all of the other big ones period, even from sites that I like.)
If Linux had not been open sourced (I believe that the GPL was a particularly critical choice, for reasons I'll get into below), I doubt very much that we'd even be hearing about it. Possibly there'd be something else that would have been open source that we'd have heard about, possibly (but I suspect not) BSD would have filled the void. That's just a guess, of course.
Linux got a lot of very powerful (not in the financial/political sense, but in the technical and later marketing sense) mindshare concentrated around it fairly quickly. IMHO, that is why it survived and thrived -- there were a lot of people out there who were attracted to that kind of project, who had the oomph needed to make it work.
BSD has, as I see it, three disadvantages from this standpoint:
1) The development model is closed -- it's a very tight core of people. That makes it hard for new people to jump on board. The BSD folks seem to like to tout it as an advantage. I don't think so. Whatever advantage there may be in having a small core of very highly qualified people and not having to worry about "substandard" code is more than outweighed by the sheer creative energy and new ideas unleashed by the openness of the Linux development process.
2) BSD's been around a lot longer and has gotten a bit stale. This partly related to (1), but partly it's also the natural tendency of something that has been around for a long time getting tired. I don't intend this as harshly as it comes across (and I'm well aware that it sounds nasty, although that's not my intent). The BSD folks are dedicated and very good, but they've been working on the same thing for a long time (in their various camps). Linux doesn't have a lot of baggage, and it's a lot easier to try new things. Of course, this implies that in 5-10 years Linux will be in much the same position. Probably it will. Linus tries to stave it off (he said this somewhere a year or two ago) by being picky about what goes into the kernel, and the greater turnover of developers is probably also healthy, but it's also not the be-all and end-all of systems. Eventually it's going to get tired too, and somebody else will come up with something better.
3) The GPL. It's really a finely tuned instrument for maximizing code availability and minimizing the destructive kind of forking. This, more than anything else, is RMS's greatest contribution. The really nifty thing about the GPL is that it ensures that all changes that anyone wants to distribute to anyone are made available to everyone, but it also ensures that nobody has any premature veto over anything. Linus can decide what he'll put into the Linux kernel that he distributes, but he can't stop anyone from distributing something else. Likewise, somebody else can't take the Linux kernel, make useful but proprietary changes, and force a split (particularly when other people make other changes with incompatible licensing, and force people to choose). The first effect ensures that Linus stays on his toes; he can't ignore something very useful that someone else has done just because he doesn't like that person -- he can ignore the specific bit of code, but if enough people like it, he'll eventually have to allow in something that does what's desired. It also exposes all new ideas to the light of day very quickly, where the market -- not the "owner" -- can evaluate them. The second ensures -- in a PRACTICAL sense -- that things can't get so incompatible that everything gets out of hand.
Whatever the theoretical risks of forking (which are much overblown, to put it mildly), the GPL is probably the one form of public license that allows for wide-open public participation but really does have great immunity against forking. As Vinod put it in Halloween (2?), being able to fix bugs or add features -- and then contributing them back, and seeing them get public use -- is very empowering.
It's very nice to be able to sit back and say "I have some code in the Linux kernel that millions of people are using" even if it's some trivial little thing (in my case, it's something like a 5-line patch to speed up argv handling in exec()). I suspect that that factor has a much bigger part to play in the early success of Linux than many give it credit for -- there was nothing else around at the time that did that.
Then we have another feature of the GPL -- the Great Equalizer. Some people say that the GPL is very business-unfriendly, since it doesn't allow for proprietary enhancements, and that the BSD license should be preferred on those grounds. I think not; the fact that your competitor is under the same constraints makes for a very equal situation. Under the BSD license, if you want to add value and resell it, you almost have to make your changes proprietary, because otherwise your competitor can take your public changes and put them into a proprietary product. The GPL forbids this; you can make a useful change and contribute it back with no fear that your competitor can use your own work against you. So everyone is equal under it; nobody can steal an advantage by means of hiding information; you need to execute better.
There's no such thing as complete freedom; there do have to be basic ground rules to ensure some basic level of cooperation, or else there are too many people who are looking to twist things to their short term advantage. That's where the GPL excels. And that, I think, is a big part of why Linux got where it is today. That, and executing well.
Whether this is new or not (and I suspect that it's fairly unusual for a major publication to offer an article for review to a broad audience), Jon did identify and describe this phenomenon, and backed it up with a strong case study. Doing something isn't enough; only by recording and analyzing it is it possible to add it to our portfolio of ways of doing things.
I've used Solid, and it works pretty well. It's a lot simpler to administer than Oracle, and it fully supports transactions, with various concurrency options. Check out www.solidtech.com. I've used it personally, although it was really as an object repository rather than a large data store. It has a good ODBC driver, and it exists for many systems.
The problem is in the VM system, not the filesystem. The 64-bit read/write/open system calls are in glibc presumably because other operating systems support them; I don't know what happens with them on Linux (they probably degrade to the normal 32-bit ones, and the library simply translates the parameters).
In any event, it doesn't matter with Oracle, or Solid, or any other halfway rationally designed database. They all allow multiple tablespaces, or datafiles, or whatever you want to call it. It isn't simply a matter of 32-bit compatibility either; there's the little matter of disk/filesystem limits and load sharing.