No, they have a trademark that covers that particular sillohouette rendition of his head. You can't "trademark a character", you need an actual image.
The fact that they tried to use trademark law to glom onto Mickey as well is kind of disgusting, though. For Chrissake, I think they've milked enough out of the work of dead artists.
No. I don't use Evolution, but I thought it would be really cool to buy a coupla pizzas with money generated from open source coding, make a big deal out if it.
And aside from all the reasons why the FSF is more likely to be better justified in having the copyright, and aside from the fact that I've never submitted a line of code to a GNU project, the FSF controls the GPL anyway, so you *have* to trust them.
Still, it makes one wonder why exactly they feel that skyscrapers would be a good choice. The surface area of them that is actually in sunlight is not much larger than something at ground level. Exhaust particles and dust kicked up by car motion will more easily cover panels.
I mean, this is neat, but it looks like a solution in search of a problem -- some situation where you both need full visibility and need to generate power. I just can't think of anything like that.
Sorry, I intended to refer to Dragon's Lair, not Dragon Warrior.
My apologies to any Dragon Warrior fans.
For those unfamiliar with Dragon's Lair, it is literally nothing but a stream of pre-recorded video and audio during which you must hit the proper controls at the appropriate times. Thus, since a winning game is always played the same way each time, audio can be the same each time.
The gentleman writing this article seems to hold as his primary goal pushing forward the field, advancing the arena, conducting experimentation, and then complains that game producers are too "cowardly" to produce such music. The problem is that this is *not* a game producer's goal. His goal is to impact the emotions of the player as much as possible to increase the effect of the game.
Perhaps if I want an epic scene, I would choose choir singing, and perhaps with an action scene metal. That's because people *have* formed associations in their head between music and the meanings associated with that music. To ignore those associations is on par with ignoring other learned languages, like English, and simply making random sounds because they are "experimental."
I tend to dislike most synth sounds. I think that people dislike identical stimuli very much -- our brains seek to avoid it, be it from boredom or whatnot, it is clearly not something that we have evolved to consider good. Try listening to a medium-volume sine or square wave for ten minutes or so. It's maddening and unpleasant. Much synth music suffers from the same effect, because it is similarly repetitive -- identical, even.
My guess is that the reason we like traditional analog instruments (aside from the longer evolutionary period than the handful of years that synth has been around) is that each sound is very different. The volume, pitch, hold, and tiny variations crop up. That's important to making music appealing -- it constantly exposes us to unknown stimuli.
I'm also guessing that we tend to like identifying patterns, and classical music is full of apparent patterns for our brains to discover.
I simply find the sound of an analog guitar more appealing than a synth guitar, or of a simple sine wave.
That being said, I do agree with the general argument that video game audio has moved too close to traditional audio, and is not really taking advantage of modern technology.
First, I was very disappointed when Creative beat out Aureal in the short sound card wars a few years back -- we were looking at a GPU-like era of new ideas and rapid improvement. Creative pushed EAX, basically a reverb model. Aureal pushed A3D, modelling 3d environments and actually bouncing sound around. If a wall is close to your right year, sounds are different than if there is simply empty space there. We are very capable of picking up on spatial hints from sound, and there are currently no such hints provided in game audio.
It will increasingly become possible to do this sort of thing in software -- we now enjoy software-generated Doppler effects, and I look forward to 3d modelling.
Second, we are only now seeing anything other than a linear track of audio that plays. Game audio is intended to accompany a changing environment. Events and the game environment change at different times. Unless you're playing Dragon Warrior, that probably means that a suitable soundtrack is not the same each time!
We implemented a simple version of this early on, when music tempo increased to indicate a warning in many video games. Later, games like Total Annihilation had two tracks that they could switch between depending upon how "dangerous" the environment is. Since then, we've taken the step of slightly more intelligent transitions (transitioning from the first track to the second on beats and the like). In general, though, our composition techniques and tools are poorly suited to anything but a single, static sequence of music.
A proper modern game audio engine should include a set of, say, states. Once I change states (from, say, STATE_NORMAL to STATE_FIGHTING), the audio engine waits until the first transition point in the audio and then kicks into the STATE_FIGHTING audio). There should be the ability to add a transition sequence of music associated with the transition between those two states at this point in music. So I'd store a bunch o
I don't think it will happen. I've heard people concerned about this, but it doesn't seem likely.
The FCC has regulatory power over a number of environments -- phone, radio, etc, but does not regulate the Internet due to (a) an unusually impressive amount of restraint on the part of two successive US Presidents and (b) the fact that the United States promotes technology worship and such regulation has already been called out as "limiting innovation" -- magic phrase, that, and (c) because the current FCC chairman, Michael Powell, is remarkably sane and well-informed when it comes to the Internet.
Similarly, the software world has seen little regulation.
Not surprisingly, the software world and the Internet have seen some of the fastest rates of technological improvement of any field -- new ideas are produced, implemented, mature, and die out, all in the space of a few years.
To try to control all media playback devices, the media companies would need to get Congress and the Senate to extend the FCC's mandate to include software and the Internet. Being seen as impeding technological progress is *not* something that any legislator wants.
Frankly, I think the whole thing is a bit silly. Disney is probably being irrational because of something like the following: a bunch of DRM consultants are asked if they have a solution, and when they realize the size of Disney's pocketbook, they say "Yes, we certainly do!".
No attempt to implement DRM in a manner intended to prevent initial leaks from a controlled to an uncontrolled environment (from "DRM-enabled platform" to "Joe's MP3 Player Software") has ever succeeded on a large scale. Heck, it hasn't even worked on a small scale -- screener DVDs are regularly leaked.
Put simply, Disney is trying to keep alive the mechanism that allows their business practice in an environment that simply does not permit it.
The worst thing is that I'm sure if Disney had technically-aware management, they'd realize the impossibility of stopping such copying, and find another approach. Instead, because the only people who are talking to them are those with an interest in providing them with pricy DRM service (I remember one engineer that used to work at a company before I knew him where he kept working on DRM, even though he knew it was hopeless in the real world, because that's where his paycheck was coming from -- he certainly wouldn't say anything about it to senior management). They're going to keep banging away on the only thing that they can think of. More potentially workable models, like tip-based payment to artists for recordings, or subscription-based full-library-access would generally entail a huge reduction in the need for the services of publishers like Disney.
I'd love to see a real, open forum run by Disney where feedback can actually reach their upper management, and where we can set aside all the bullshit on each side (MP3 traders claiming that they're "trading to fight the oppressive publishers" and publishers that they're "protecting the artist for moral reasons", and just tried to examine the most workable system for all involved.
That, unfortunately, is not likely to happen. The corporate structure encourages people to say what they think their boss or employer will want to hear, not to give an honest evaluation of the situation, and the rest of us will have to live through the ten or so years of bad laws, propaganda from both sides, and marketing dollars blown as the publishers messily have reality forced upon them.
As mentioned in the article, this isn't meant to be a catch all interface used for all tasks, rather it's mainly useful for rarely used operations where the individual is unlikely to retain working knowledge over the time gaps seperating usage.
I realize that. I'm just thinking that many "uncommon" tasks aren't quite as "uncommon" as one might expect. Setting up a network interface, for instance, would probably be something that most folks would call "uncommon", but when a network guy has to configure a mass of machines where he works, he really doesn't want his only interface to be an "type in number, hit enter, type in number, hit enter, etc, etc..."-looking interface.
All this is is Novell trying to institute an old-world, pre-GPL code-ownership model... but without having to pay developers benefits or pricing.
I reckon that there are some people that will do this, but there are much better gigs. Some places will let you do contract work and GPL that work (if there's no competitive disadvantage) and give it away to others. In that case, you get paid well for the code *and* the world gets a GPL-licensed piece of software (not this DFSG-compliant-and-maybe-GPL-if-Novell-feels-like- it business).
I was actually going to do a bounty on Evolution this month -- wanted to see how it'd work out. Now I'm glad that I put it off from last month. Screw 'em. I've got more lucrative ways to earn money, and better projects to work on. When I want to write GPLed code, I'll write GPLed code and keep my copyright.
If Novell was innocent and just out to cover their asses WRT their closed source software, they could have done something like the NPL (which folks *still* didn't accept) where Netscape gets a license to use the software. Novell wants the bleeding *copyright* signed over.
I think it makes sense to make Fedora packages for your own software - that way, you have some assurance that it will be packaged correctly. Beyond that, because of the vastly unequal partnership, I fear that a volunteer developer would be making himself an unpaid employee of Red Hat rather than a member of a real community.
So make your own derivative distro from Fedora like Enterprise Edition. Red Hat won't stop you, and hasn't stopped a number of people that has done exactly that. Red Hat is probably the most Free-oriented major distro developer, aside from the Debian Project, of course.
Gnu / BSD / X11 / Sell Grandmother into slavery - I don't care.
Ever use another popular email program named pine? You know why it's increasingly dead? Because it has a *bad license*. You ever hear people complaining about the problems with djbdns's license, or qmail's license?
Just because a license doesn't directly impact you at the moment doesn't mean that it won't in the future, or won't do so indirectly (and possibly just as significantly).
Because Evolution is licensed under the GPL there is zero concern about the software itself. The issue is not "does this violate the GPL", this issue is "will people contribute patches if they (a) have a problem with the licensing, or (B) have to go through the hassle of signing Novell's forms".
The license specifies DFSG-compliant, not GPLed. That's less innocent.
The worst possible light you can put on this is that Ximian is forking Evolution to be non-GPL. That does nothing to the current coebase. If people are interested in maintaining Evolution, they're certainly free to produce their own "true, GPLed forever" fork. Look at XFree86 and xorg.
I think that people should be using mutt, anyway.:-)
There are three main approaches to implementing DRM:
* Disable use on systems after a leak and redistribution. Generally done with some kind of watermarking scheme. Never going to happen. Watermarking is a cute research idea, but it turns out that efficient compression (eliminating data that isn't visually/aurally important) eliminates the same set of data that watermarks need to play with. There are a host of other problems as well -- generally, if someone can detect a watermark, they can remove it. Caught a bit of interest early on, pretty much went away.
* Stop redistribution after a leak. The RIAA/MPAA are still working on this, but it's ultimately a doomeed effort. Computers and networks were made to copy data.
* Try to prevent the inital copy from leaking. Never going to happen. There are too many places for an initial leak to come from with any kind of widely-distributed data. There's a hybrid approach using this and watermarks to identify initial leaks followed by legal action against the source of the leak. This doesn't even work against small-scale distribution systems like screener DVDs -- it will *not* work for a large-scale system.
That's not so bad. It just means that the econonmy of our society is changing once again. Attempts to keep the rules from shifting and the econonmy from adjusting are as useless as the feudal lords trying to keep merchants from becoming the new powerful class.
No. It's actually a different metaphor. I really think that this guy is still missing the point -- I really think that Apple Guide-style interfaces are the best approach around. Here's a breakdown:
* Wizard-style interfaces. The purpose of these is to allow either a simpler or faster interface that is an alternative to the regular interface. A more limited featureset is available from a wizard, ideally representing the most common tasks. This in theory inconveniences neither basic users nor advanced users, since advanced users can simply use the full interface, and basic users can stick with the wizard for their "common" tasks. The main drawback is that knowledge gained about one interface fails to carry over to the other interface -- there are largely two pieces of software present. In addition, it's the most expensive to maintain, since there are two full interfaces present.
* This IUI business, based on the article, involves use of a single interface (unlike the twin-interface wizard approach, which has a "basic" and a "full" interface), and simply places instructions for what the user must do throughout the interface. It serializes tasks ("do A, then B, then C"), and probably trades off speed of use for an experienced user to help inexperienced users know how to perform the operation. IUIs are probably the easiest of the three to implement, but they also annoy the bajezus out of people that know what they're doing.
* The third approach, Apple Guide-style, which is what the old Mac UI engineers came up with. Unfortunately, their implementation wasn't so hot -- a pain to actually do up Apple Guide docs, so it fell into disuse. The concept, though, is excellent. A developer provides the full, advanced interface, just as with wizards. However, they then provide a large set of interactive help files that walk a user through common tasks, circling the widgets to click onscreen, and so forth. With this approach, the user is rapidly converted into an advanced user, and can take advantage of the full interface, though it may be slower than wizards to do a common task the first time. The only issue with the AG-style approach is that sometimes wizards are used to provide macro-like functionality -- suppose setting up a network interface for a particular common configuration involved entering the same number in three different places (say, allowing UDP from the nameserver through the firewall, telling the resolver to use the nameserver, and telling a network monitor program to use the nameserver as the box to ping to determine if the interface is having problems or not). A wizard could take a single value and slap it in three different places, but the AG-style approach would still require the user to enter the number three times.
On the whole, I think that IUI is just a poor replacement (though somwhat cheaper to implement) than AG-style interface. Take the *IX philosophy -- we'll try to empower you as much as possible, just as long as you're willing to learn, and add the phrase "and we'll also teach you as you work", and you have a good idea of what the AG approach is.
Just another amazing piece of work from Apple in it's golden days of interface design that unfortunately wound up dead. Sigh.
Hmm...speaking of LCD displays...that's actually a very interesting idea.
Currently, smartcards have one huge hole for use in secure environments -- they have no secure user-input or user-output channels. This means that if someone sets up a bogus ATM/card reader (which has been done oh so many times), they can swipe your PIN and since the interface, including hitting "OK" or not is all done through the reader, can hit "OK" for you.
But if you can build a small computer with a simple interface (CF is a good choice, though a smartcard interface would also work), you can slap a display on it (actually, all you need is a calculator-style alphanumeric LCD strip) and a nine-button numeric keypad. You can enter your PIN directly to your card, and you can trust that the price being displayed on the card is the price that you are actually paying, and the payee being displayed is actually who the money is going to.
For a long time, I've been wondering how long it will be until smartcards become standard for sales. The attacks on smartcards are largely doable because of a lack of untrusted readers (as I said, no keypad or display on-card). Smartcards are great for e-commerce, where you can have a reasonably trusted reader in the form of your computer. I figured that one day AmEx or someone will partner with Dell and Dell will start bundling smartcard readers with their systems (the cost of a smartcard reader is very, very low, and the potential savings with not having to deal with constant fraud attempts on credit cards, and the ability of vendors to actually trust and allow purchases coming from, say, Nigeria, is a significant benefit). Nobody's got around to shipping lots of computers with smartcard interfaces -- but *lots* of computers have CompactFlash interfaces. All that's needed is an open standard for communicating with "smartcard on CompactFlash", someone figuring out where they can get their paws on some cheap, durable LCD displays, slap some buttons on it, and you have one hell of a compelling commerce mechanism to replace the credit card.
FWIW, while I'm sure credit card vendors have no interest in allowing such a thing, a smartcard vendor could provide actual privacy, not knowing about each one of your transactions, since your transactions cannot be (reasonably) forged.
God, that would be cool. Anyone know how many mW CF can provide?
Because most people, unfortunately, are not geek hobbyists, and think of computers in terms of application, not of mechanism. To them, this reconfigurability is just additional cost, complexity, and fragility to get a "follow the directions to assemble it yourself" device that performs some task that they want to do, like store lists of phone numbers. Sure, it drives us bonkers that we don't have a pretty interface and better support for the I2C bus (or internal USB in cases), interesting input (knobs, sliders, etc that can be interfaced with) devices, cheap interesting output devices (LED/LCD/VFD front-panel displays), thermometers, and the like. The typical computer user, though, doesn't give a damn about extending or reconfiguring their computer, because they want to accomplish a task, and don't really want to "figure out what to do to their computer to accomplish that task".
Slashdot Mirror
No, they have a trademark that covers that particular sillohouette rendition of his head. You can't "trademark a character", you need an actual image.
The fact that they tried to use trademark law to glom onto Mickey as well is kind of disgusting, though. For Chrissake, I think they've milked enough out of the work of dead artists.
No. I don't use Evolution, but I thought it would be really cool to buy a coupla pizzas with money generated from open source coding, make a big deal out if it.
And aside from all the reasons why the FSF is more likely to be better justified in having the copyright, and aside from the fact that I've never submitted a line of code to a GNU project, the FSF controls the GPL anyway, so you *have* to trust them.
Well, yeah. If there's no light inside, how are you going to operate your solar-powered flashlight?
Still, it makes one wonder why exactly they feel that skyscrapers would be a good choice. The surface area of them that is actually in sunlight is not much larger than something at ground level. Exhaust particles and dust kicked up by car motion will more easily cover panels.
I mean, this is neat, but it looks like a solution in search of a problem -- some situation where you both need full visibility and need to generate power. I just can't think of anything like that.
Thank you. :-)
Yes, exactly.
Sorry, I intended to refer to Dragon's Lair, not Dragon Warrior.
My apologies to any Dragon Warrior fans.
For those unfamiliar with Dragon's Lair, it is literally nothing but a stream of pre-recorded video and audio during which you must hit the proper controls at the appropriate times. Thus, since a winning game is always played the same way each time, audio can be the same each time.
Interesting thoughts. However...
The gentleman writing this article seems to hold as his primary goal pushing forward the field, advancing the arena, conducting experimentation, and then complains that game producers are too "cowardly" to produce such music. The problem is that this is *not* a game producer's goal. His goal is to impact the emotions of the player as much as possible to increase the effect of the game.
Perhaps if I want an epic scene, I would choose choir singing, and perhaps with an action scene metal. That's because people *have* formed associations in their head between music and the meanings associated with that music. To ignore those associations is on par with ignoring other learned languages, like English, and simply making random sounds because they are "experimental."
I tend to dislike most synth sounds. I think that people dislike identical stimuli very much -- our brains seek to avoid it, be it from boredom or whatnot, it is clearly not something that we have evolved to consider good. Try listening to a medium-volume sine or square wave for ten minutes or so. It's maddening and unpleasant. Much synth music suffers from the same effect, because it is similarly repetitive -- identical, even.
My guess is that the reason we like traditional analog instruments (aside from the longer evolutionary period than the handful of years that synth has been around) is that each sound is very different. The volume, pitch, hold, and tiny variations crop up. That's important to making music appealing -- it constantly exposes us to unknown stimuli.
I'm also guessing that we tend to like identifying patterns, and classical music is full of apparent patterns for our brains to discover.
I simply find the sound of an analog guitar more appealing than a synth guitar, or of a simple sine wave.
That being said, I do agree with the general argument that video game audio has moved too close to traditional audio, and is not really taking advantage of modern technology.
First, I was very disappointed when Creative beat out Aureal in the short sound card wars a few years back -- we were looking at a GPU-like era of new ideas and rapid improvement. Creative pushed EAX, basically a reverb model. Aureal pushed A3D, modelling 3d environments and actually bouncing sound around. If a wall is close to your right year, sounds are different than if there is simply empty space there. We are very capable of picking up on spatial hints from sound, and there are currently no such hints provided in game audio.
It will increasingly become possible to do this sort of thing in software -- we now enjoy software-generated Doppler effects, and I look forward to 3d modelling.
Second, we are only now seeing anything other than a linear track of audio that plays. Game audio is intended to accompany a changing environment. Events and the game environment change at different times. Unless you're playing Dragon Warrior, that probably means that a suitable soundtrack is not the same each time!
We implemented a simple version of this early on, when music tempo increased to indicate a warning in many video games. Later, games like Total Annihilation had two tracks that they could switch between depending upon how "dangerous" the environment is. Since then, we've taken the step of slightly more intelligent transitions (transitioning from the first track to the second on beats and the like). In general, though, our composition techniques and tools are poorly suited to anything but a single, static sequence of music.
A proper modern game audio engine should include a set of, say, states. Once I change states (from, say, STATE_NORMAL to STATE_FIGHTING), the audio engine waits until the first transition point in the audio and then kicks into the STATE_FIGHTING audio). There should be the ability to add a transition sequence of music associated with the transition between those two states at this point in music. So I'd store a bunch o
I don't think it will happen. I've heard people concerned about this, but it doesn't seem likely.
The FCC has regulatory power over a number of environments -- phone, radio, etc, but does not regulate the Internet due to (a) an unusually impressive amount of restraint on the part of two successive US Presidents and (b) the fact that the United States promotes technology worship and such regulation has already been called out as "limiting innovation" -- magic phrase, that, and (c) because the current FCC chairman, Michael Powell, is remarkably sane and well-informed when it comes to the Internet.
Similarly, the software world has seen little regulation.
Not surprisingly, the software world and the Internet have seen some of the fastest rates of technological improvement of any field -- new ideas are produced, implemented, mature, and die out, all in the space of a few years.
To try to control all media playback devices, the media companies would need to get Congress and the Senate to extend the FCC's mandate to include software and the Internet. Being seen as impeding technological progress is *not* something that any legislator wants.
Frankly, I think the whole thing is a bit silly. Disney is probably being irrational because of something like the following: a bunch of DRM consultants are asked if they have a solution, and when they realize the size of Disney's pocketbook, they say "Yes, we certainly do!".
No attempt to implement DRM in a manner intended to prevent initial leaks from a controlled to an uncontrolled environment (from "DRM-enabled platform" to "Joe's MP3 Player Software") has ever succeeded on a large scale. Heck, it hasn't even worked on a small scale -- screener DVDs are regularly leaked.
Put simply, Disney is trying to keep alive the mechanism that allows their business practice in an environment that simply does not permit it.
The worst thing is that I'm sure if Disney had technically-aware management, they'd realize the impossibility of stopping such copying, and find another approach. Instead, because the only people who are talking to them are those with an interest in providing them with pricy DRM service (I remember one engineer that used to work at a company before I knew him where he kept working on DRM, even though he knew it was hopeless in the real world, because that's where his paycheck was coming from -- he certainly wouldn't say anything about it to senior management). They're going to keep banging away on the only thing that they can think of. More potentially workable models, like tip-based payment to artists for recordings, or subscription-based full-library-access would generally entail a huge reduction in the need for the services of publishers like Disney.
I'd love to see a real, open forum run by Disney where feedback can actually reach their upper management, and where we can set aside all the bullshit on each side (MP3 traders claiming that they're "trading to fight the oppressive publishers" and publishers that they're "protecting the artist for moral reasons", and just tried to examine the most workable system for all involved.
That, unfortunately, is not likely to happen. The corporate structure encourages people to say what they think their boss or employer will want to hear, not to give an honest evaluation of the situation, and the rest of us will have to live through the ten or so years of bad laws, propaganda from both sides, and marketing dollars blown as the publishers messily have reality forced upon them.
As mentioned in the article, this isn't meant to be a catch all interface used for all tasks, rather it's mainly useful for rarely used operations where the individual is unlikely to retain working knowledge over the time gaps seperating usage.
I realize that. I'm just thinking that many "uncommon" tasks aren't quite as "uncommon" as one might expect. Setting up a network interface, for instance, would probably be something that most folks would call "uncommon", but when a network guy has to configure a mass of machines where he works, he really doesn't want his only interface to be an "type in number, hit enter, type in number, hit enter, etc, etc..."-looking interface.
Thank you.
... but without having to pay developers benefits or pricing.
- it business).
All this is is Novell trying to institute an old-world, pre-GPL code-ownership model
I reckon that there are some people that will do this, but there are much better gigs. Some places will let you do contract work and GPL that work (if there's no competitive disadvantage) and give it away to others. In that case, you get paid well for the code *and* the world gets a GPL-licensed piece of software (not this DFSG-compliant-and-maybe-GPL-if-Novell-feels-like
I was actually going to do a bounty on Evolution this month -- wanted to see how it'd work out. Now I'm glad that I put it off from last month. Screw 'em. I've got more lucrative ways to earn money, and better projects to work on. When I want to write GPLed code, I'll write GPLed code and keep my copyright.
If Novell was innocent and just out to cover their asses WRT their closed source software, they could have done something like the NPL (which folks *still* didn't accept) where Netscape gets a license to use the software. Novell wants the bleeding *copyright* signed over.
I think it makes sense to make Fedora packages for your own software - that way, you have some assurance that it will be packaged correctly. Beyond that, because of the vastly unequal partnership, I fear that a volunteer developer would be making himself an unpaid employee of Red Hat rather than a member of a real community.
So make your own derivative distro from Fedora like Enterprise Edition. Red Hat won't stop you, and hasn't stopped a number of people that has done exactly that. Red Hat is probably the most Free-oriented major distro developer, aside from the Debian Project, of course.
Gnu / BSD / X11 / Sell Grandmother into slavery - I don't care.
Ever use another popular email program named pine? You know why it's increasingly dead? Because it has a *bad license*. You ever hear people complaining about the problems with djbdns's license, or qmail's license?
Just because a license doesn't directly impact you at the moment doesn't mean that it won't in the future, or won't do so indirectly (and possibly just as significantly).
So. YOU write the code and then you give ALL THE RIGHTS to Novell.
Then Novell licenses YOUR CODE BACK TO YOU.
This is the sort of thing that could only happen in Japan.
Because Evolution is licensed under the GPL there is zero concern about the software itself. The issue is not "does this violate the GPL", this issue is "will people contribute patches if they (a) have a problem with the licensing, or (B) have to go through the hassle of signing Novell's forms".
The license specifies DFSG-compliant, not GPLed. That's less innocent.
As soon as your code is accepted and put into CVS, you can check it back out, under the GPL.
Nope. Re-read the license. It says "DFSG compliant", not "GPLed". I dunno what licenses fit the DFSG, though.
The worst possible light you can put on this is that Ximian is forking Evolution to be non-GPL. That does nothing to the current coebase. If people are interested in maintaining Evolution, they're certainly free to produce their own "true, GPLed forever" fork. Look at XFree86 and xorg.
:-)
I think that people should be using mutt, anyway.
There are three main approaches to implementing DRM:
* Disable use on systems after a leak and redistribution. Generally done with some kind of watermarking scheme. Never going to happen. Watermarking is a cute research idea, but it turns out that efficient compression (eliminating data that isn't visually/aurally important) eliminates the same set of data that watermarks need to play with. There are a host of other problems as well -- generally, if someone can detect a watermark, they can remove it. Caught a bit of interest early on, pretty much went away.
* Stop redistribution after a leak. The RIAA/MPAA are still working on this, but it's ultimately a doomeed effort. Computers and networks were made to copy data.
* Try to prevent the inital copy from leaking. Never going to happen. There are too many places for an initial leak to come from with any kind of widely-distributed data. There's a hybrid approach using this and watermarks to identify initial leaks followed by legal action against the source of the leak. This doesn't even work against small-scale distribution systems like screener DVDs -- it will *not* work for a large-scale system.
That's not so bad. It just means that the econonmy of our society is changing once again. Attempts to keep the rules from shifting and the econonmy from adjusting are as useless as the feudal lords trying to keep merchants from becoming the new powerful class.
"Your mother was a hamster and your father smelled of elderberries!"
So this means... more wizard-style interfaces?
No. It's actually a different metaphor. I really think that this guy is still missing the point -- I really think that Apple Guide-style interfaces are the best approach around. Here's a breakdown:
* Wizard-style interfaces. The purpose of these is to allow either a simpler or faster interface that is an alternative to the regular interface. A more limited featureset is available from a wizard, ideally representing the most common tasks. This in theory inconveniences neither basic users nor advanced users, since advanced users can simply use the full interface, and basic users can stick with the wizard for their "common" tasks. The main drawback is that knowledge gained about one interface fails to carry over to the other interface -- there are largely two pieces of software present. In addition, it's the most expensive to maintain, since there are two full interfaces present.
* This IUI business, based on the article, involves use of a single interface (unlike the twin-interface wizard approach, which has a "basic" and a "full" interface), and simply places instructions for what the user must do throughout the interface. It serializes tasks ("do A, then B, then C"), and probably trades off speed of use for an experienced user to help inexperienced users know how to perform the operation. IUIs are probably the easiest of the three to implement, but they also annoy the bajezus out of people that know what they're doing.
* The third approach, Apple Guide-style, which is what the old Mac UI engineers came up with. Unfortunately, their implementation wasn't so hot -- a pain to actually do up Apple Guide docs, so it fell into disuse. The concept, though, is excellent. A developer provides the full, advanced interface, just as with wizards. However, they then provide a large set of interactive help files that walk a user through common tasks, circling the widgets to click onscreen, and so forth. With this approach, the user is rapidly converted into an advanced user, and can take advantage of the full interface, though it may be slower than wizards to do a common task the first time. The only issue with the AG-style approach is that sometimes wizards are used to provide macro-like functionality -- suppose setting up a network interface for a particular common configuration involved entering the same number in three different places (say, allowing UDP from the nameserver through the firewall, telling the resolver to use the nameserver, and telling a network monitor program to use the nameserver as the box to ping to determine if the interface is having problems or not). A wizard could take a single value and slap it in three different places, but the AG-style approach would still require the user to enter the number three times.
On the whole, I think that IUI is just a poor replacement (though somwhat cheaper to implement) than AG-style interface. Take the *IX philosophy -- we'll try to empower you as much as possible, just as long as you're willing to learn, and add the phrase "and we'll also teach you as you work", and you have a good idea of what the AG approach is.
Just another amazing piece of work from Apple in it's golden days of interface design that unfortunately wound up dead. Sigh.
No. I chose my language to make explicit the thing that should be changed -- this involved only a change of a single digit from the original.
Hmm...speaking of LCD displays...that's actually a very interesting idea.
Currently, smartcards have one huge hole for use in secure environments -- they have no secure user-input or user-output channels. This means that if someone sets up a bogus ATM/card reader (which has been done oh so many times), they can swipe your PIN and since the interface, including hitting "OK" or not is all done through the reader, can hit "OK" for you.
But if you can build a small computer with a simple interface (CF is a good choice, though a smartcard interface would also work), you can slap a display on it (actually, all you need is a calculator-style alphanumeric LCD strip) and a nine-button numeric keypad. You can enter your PIN directly to your card, and you can trust that the price being displayed on the card is the price that you are actually paying, and the payee being displayed is actually who the money is going to.
For a long time, I've been wondering how long it will be until smartcards become standard for sales. The attacks on smartcards are largely doable because of a lack of untrusted readers (as I said, no keypad or display on-card). Smartcards are great for e-commerce, where you can have a reasonably trusted reader in the form of your computer. I figured that one day AmEx or someone will partner with Dell and Dell will start bundling smartcard readers with their systems (the cost of a smartcard reader is very, very low, and the potential savings with not having to deal with constant fraud attempts on credit cards, and the ability of vendors to actually trust and allow purchases coming from, say, Nigeria, is a significant benefit). Nobody's got around to shipping lots of computers with smartcard interfaces -- but *lots* of computers have CompactFlash interfaces. All that's needed is an open standard for communicating with "smartcard on CompactFlash", someone figuring out where they can get their paws on some cheap, durable LCD displays, slap some buttons on it, and you have one hell of a compelling commerce mechanism to replace the credit card.
FWIW, while I'm sure credit card vendors have no interest in allowing such a thing, a smartcard vendor could provide actual privacy, not knowing about each one of your transactions, since your transactions cannot be (reasonably) forged.
God, that would be cool. Anyone know how many mW CF can provide?
Why hasn't this been done yet?
Because most people, unfortunately, are not geek hobbyists, and think of computers in terms of application, not of mechanism. To them, this reconfigurability is just additional cost, complexity, and fragility to get a "follow the directions to assemble it yourself" device that performs some task that they want to do, like store lists of phone numbers. Sure, it drives us bonkers that we don't have a pretty interface and better support for the I2C bus (or internal USB in cases), interesting input (knobs, sliders, etc that can be interfaced with) devices, cheap interesting output devices (LED/LCD/VFD front-panel displays), thermometers, and the like. The typical computer user, though, doesn't give a damn about extending or reconfiguring their computer, because they want to accomplish a task, and don't really want to "figure out what to do to their computer to accomplish that task".
Sigh.
You sure you don't mean "it was duped 2 times"?
So, I'm now curious as to whether the story and this comment are just an astroturfing scheme.
I think that all right-thinking people use emacs, not vi. That being said, what about fmt logfile >logfile-formatted?