Yeah, and it will have the same effect on the laser weapon that it has on the stars, too. In other words, that'll be 100,000 watts of burning, annihilating, twinkling death raining down on you.
Nope, the treaty you mentioned is the Geneva Convention, and it bans weapons whose sole purpose is to blind. Just about any laser ranging or designation device can blind if used (or misused) in just the right way; none of these devices is regulated by the Geneva Convention.
The purpose of this laser weapon is to destroy stuff, not to blind people. So it's A-OK, too.
At these levels of power, the reflective material would have to reflect virtually all light in order to be safe. And when I say "virtually all," I mean on the order of 99.999%. I believe a 12 watt laser can cut through sheet aluminum pretty handily, and aluminum is both somewhat reflective and highly heat-conductive. A kilowatt-scale laser should be able to cut through just about anything, shiny or otherwise.
What you're talking about is absolutely possible. More than that, it's a key feature of fibre channel technology. And, in my sincerely humble opinion, it's really the only effective way to do a SAN: connect all the computers and all the storage devices to a big fabric, then give computers exclusive read-write or non-exclusive read-only access to each LUN. Shared access is hardly ever worth the trouble that goes into setting it up.
Your HP solution sounds pretty much like IRIS FailSafe, from SGI. The storage device is shared between two (or more) hosts, but only one host has access to it at any given time. When that host fails, the other host automatically mounts the storage device and takes up the failed node's responsibilities. Shared storage is a requirement for that kind of configuration; in the old days, we used to do it with SCSI.
I have no idea whether FireWire can support multiple hosts on a chain. Obviously it can handle more than one target, but I don't know about more than one initiator.
Also, the "LUN security" feature you talked about is sometimes called "LUN masking" or "LUN mapping," depending on how you do it. You can map a LUN to a switch port-- that's LUN mapping. Or you can set it up so that a port specifically doesn't see certain LUNs; that's LUN masking. I haven't worked with fibre channel on Windows in an age, but back when I did we had to use LUN mapping/LUN masking. At that time, the Windows host would try to send a device reset command to every LUN when it initialized its HBA. This was, of course, a very bad thing. So you had to set up your switch so that the Windows machines only saw the LUNs that they would be mounting. It was a little bit of a pain in the rear to set up, especially if the switch only supported LUN masking and not LUN mapping. If you add LUNs to your fabric, you have to go in and adjust all of your masks to mask the new LUNs out. On the other hand, if you use LUN mapping, the mapped ports will just ignore the new LUNs unless you specifically tell them not to.
So basically what you're saying is that the GPL means freedom, but only if you don't use it?
Face it, guys, this article spelled it out far more clearly than I ever could. The GPL should not-- must not, even-- be equated with freedom. It is restrictive, just like any other license. Six bleedin' pages of restrictions, for that matter. The BSD license is a truly free license: do whatever you want with this code. Period.
First of all, lock files aren't going to cut it. All we have to do is come up with a very simple scenario. You open up a file on the disk for reading, and start reading data out of it. You read a chunk, do something, then read another chunk.
Meanwhile, I come along and unlink the file.
In a single-access system, this isn't a problem. If I unlink the file while you've got it open, nothing really happens until you close it. After you close it, the file disappears and its space is reclaimed. This is because the kernel keeps track of who's got which files open, and prevents one process from pulling the rug-- so to speak-- out from under another process.
(This is also the source of the age-old trick of opening a file and immediately unlinking it. It's a good way of handling the automatic reclamation of temporary files.)
But if we've got two systems, each with a totally independent kernel, talking to the same disk, the problem suddenly gets a lot harder. When I unlink the file, my kernel will look at its tables and conclude that nobody else has the file open, so it will immediately try to reclaim the blocks on the disk. This will send your application, which is actively trying to read from the file, into shitfits.
No amount of lock files would save you in this situation. All I did was type "rm somefile." The rm command doesn't check for the presence of a lock file. Unless you want to rewrite all the file utilities, lock files aren't going to do the job.
(And extended attributes, of course, aren't portable. They're also tied to the inode, which raises its own set of problems.)
I just think you're grossly underestimating the complexity of this issue. If all you want is to share files across a network, then just use NAS. It'll work better and your life will be easier.
That's a common, and totally 100% wrong, misconception.
SAN and NAS are fundamentally different implementations. They have the same basic purpose: computer A and computer B need to access the same data on the same storage device at the same time. But that's where the similarities end.
NAS is strictly a client-server system. All the clients talk to the server, but not to each other. Clients make read requests to the server, which queues and handles the requests, caching the data along the way. The server handles things like file permissions, access control, locking, and synchronization issues. The server also arbitrates contention situations, by putting I/O requests into a queue.
Shared-access SANs are completely different. In a shared-access SAN there is no server, which means there's no central arbiter of things like permissions, access control, locking, synchronization, and request queuing. Instead, each client computer simply talks directly to the disks. In theory, taking out the middle man this way decreases latency and increases bandwidth, but in practice contention issues arise that eliminate any gains. Since there's no arbiter for things like permissions and access control, the clients all have to talk to one another somehow; that's where cluster-aware filesystems like CXFS or Centravision come in. These filesystem are complex in ways that most people fail to realize, and they are highly prone to failure. In particular, an election-based system like CXFS doesn't tolerate the coming and going of nodes to and from the cluster very well. At any time, any node can be the control node, and if it disappears, the filesystem can become wedged for a time until a new election occurs. So these types of filesystems work best in tightly coupled groups of systems, like highly available clusters, or parallel processing clusters.
SANs and NAS are only similar on the surface. Beneath the surface, they're very, very different.
Dude, with all respect, you're not hearing me. It is not possible to lock files at the application layer with a shared-access SAN. You have two independent application on two separate computers trying to access the same filesystem. No synchronization mechanism exists between them... unless you're planning to write one, which means we're back in special filesystem land. That would be an absurd amount of work for what you're actually trying to accomplish.
As for NFS-style locking, there is no server on which to run the lock daemon. If there were a server, we'd be talking about NAS instead of a SAN, which is a different thing altogether. With a SAN, there's nothing but computers and disks, and the disks are not smart. You can't do file locking at the disk level. You have to have a mechanism through which the two computers can communicate with each other directly... which puts us back into special filesystem territory yet again.
I'm not quite sure why, but it's clear that we're not communicating well here. What can I say to make this more clear to you?
How is it handled in a SAN normal envorment? Do it the same way.
Now you're starting to understand. Shared-access SANs are highly proprietary things requiring complex multi-node-aware filesystems, like Centravision or CXFS. It is not an easy thing. In most situations, it simply doesn't work at all.
Big SAN arrays have internal cache so I think they like for the OSes to do as little cacheing as possible.
First of all, there's no such thing as a "SAN array." There are disk arrays and storage systems that can be used on a SAN, but there's nothing special about them. They're just RAIDs, essentially, albeit sometimes with a few more bells and whistles.
And as for the caching thing, every operating system uses cached I/O for practically everything. (Direct, or unbuffered, I/O can be used in some situations where the data can be handled more efficiently by the application than by the OS; these situations are rare.) So let's say you and I are hooked up to the same hard drive. I open a file. Then you open the same file. I seek into the file and start reading. Let's say I read 1 MB of data into memory. Then you seek into the file and start writing. You write over the same blocks that I just read. I have no way of knowing this, of course, so I just keep doing what I'm doing, oblivious to the fact that the data I'm caching is out of date.
It gets worse. Say I decide to unlink the file... while you're in the middle of writing it. If we were talking about two applications on the same computer, I'd get an error back from the OS saying that you can't unlink an open file. (Or something, depending on the environment.) But since we're talking about two programs running on two different computers, I get no such error. Can't get one, in fact, unless my OS is keeping track of which files are currently open on your computer, and vice versa. Suddenly a normal filesystem won't work any more. We need something new, like CXFS or Centravision.
By this time, of course, we've given up on the whole damned thing and gone back to network-attached storage with Gigabit Ethernet interconnect. The last straw was the fact that my reading a file and your reading a file sent the shared drive into conniptions as the heads skittered all over the place. Disk contention is a bitch.
Shared-access SANs are incredibly complex. And, in general, they suck.
That's not what he was talking about. He was talking about using NFS or another IP-based networked filesystem. That's very different from what you're talking about.
And what you're talking about isn't such a great idea, either-- no offense. Leaving aside for a moment the technical challenges-- how do you turn a Linux system into a FireWire target, anyway?-- there would he serious cache coherency issues. How would you remotely invalidate a filesystem buffer cache, or a cached inode?
This issue is far more complex than you think it is.
Anybody can download Apple's source, read it, learn, and use Apple's ideas to implement their own software. People are prohibited merely from modifying Apple's code without telling Apple about it. This is a fine and good thing; Apple is sharing their innovations while still holding on to their valuable intellectual property. This is most certainly giving back to the community.
And yet you find fault anyway. Why is that, I wonder?
The problem here is that you, dh003i, have a political agenda. This agenda, which is based on the idea that no corporation or individual should own intellectual property, is incompatible with the modern world. This is why you have plenty of things to complain about. This is also why your complaints are irrelevant.
Let me show you what I mean. For purposes of discussion, I will adopt a political agenda. Let's say that agenda is... environmentalism. My goal in life is to protect the environment.
I now observe that the Apple license is notably silent on the subject of greenhouse gas emissions. According to the APSL, anybody can download Apple's source code while continuing to use as many fossil fuels and CFC's as they want! The license does not restrict in any way one's use of plastics or aluminum; it doesn't even have the standard clause that says, "All printed copies of this license must be recycled in an environmentally friendly paper recycling facility!" This license sucks!
See what I mean? If your agenda is orthogonal to the purpose of the license, you will find many things to which to object. But your objections will be meaningless, and they will be ignored.
I can't understand how anybody with even the slightest understand of how business works would say such a thing.
As much as I hate to say it, I think that Microsoft might actually have a point. A sizable fraction of the "free" software advocates out there-- including you, dh003i-- hold intractable anti-business positions. That concerns me.
On the one hand, we have the corporate world. Big companies doing business. On the other hand, we have the "free" software folks. I don't like to think that these two groups are in opposition to one another, but it sounds like they are after all. At least, the "free" software folks oppose the corporate world. The corporate world still seems to be pretty indifferent to the "free" software people, which is a good thing.
Anyway, you have these two groups, in opposition to one another. Comparing the contributions to the world that the "free" software people have made-- some software that's only useful to a tiny fraction of the population-- to the contributions to the world that the corporations have made-- in with a lot of bad stuff, a lot of good stuff like medicines and abundant food and relatively inexpensive housing-- I have to say that I'd side with the corporations.
Yeah, you people have the right to criticize Apple's license. And lord knows you exercise that right; the "free" software people are the most critical gang I've ever encountered. But that doesn't make you right. You're still a bunch of immature idealists who haven't really thought about the implications of what it is that you're advocating.
Anyway, the way they've been acting over the aqua interface is pathetic. They should have let people copy the aqua theme.
No offense, but you appear to lack a basic understanding of branding and marketing.
Apple wants people to buy Macs. Fundamentally, I think many people in Apple's upper management have higher motives-- their recent decisions show that they want to create new and beautiful things that make people's lives better-- but, as a company, they just want people to buy Macs.
Why do people buy Macs instead of other computers? Each Mac owner has his own set of reasons, but if you boil them all down you'll find that people buy Macs because they're Macs. Macs are different from other computers.
A Dell is pretty much the same as a Gateway, is pretty much the same as a Compaq as far as personal computers go. They all run the same software and do the same things. They differentiate from one another on price and on the way the case looks.
Macs are differentiated in several ways. Their industrial design is different. Their applications-- like iTunes and iPhoto and whatnot-- are different. And, yeah, their look-and-feel is different.
Take away what's different, and you lose the thing that makes a Mac a Mac. People lose their reason to buy a Mac-- after all, the only reason people buy Macs is because they're Macs, right?
So Apple has a vested interest in keeping Macs different from other computers. That extends to all aspects of "differentness," including the design and appearance of the user interface.
Apple would have been foolish if they hadn't defended their Aqua-related trademarks. They would have been giving away their market differentiation, which is the only thing that keeps them in business.
Based on the tone and content of your comment, I do not expect you to agree with this, or even to understand it. But it's the truth.
Apple took plenty from the FS / OSS communities via the UNIX-tools they incorporated into OS X. They pretty much took it unmodified and recompiled it for Apple hardware. A little bit hypocritical for them to ask that no one copy some of their good ideas.:sigh:
Apple took what was freely given (FreeBSD), and combined it with what was already theirs (NeXT's IP) and some new things (Quartz, Aqua) to come up with OS X.
Get that? Apple took what had been freely given. They are under no obligation-- moral, legal, or otherwise-- to give anything in return. They do so anyway.
Well, NeXT's dock goes back to about 1990. Find us a reference to a dock in use before that, and we'll accept that you're right. Until then....
But this is all pretty pointless. Apple hasn't (as far as I know) trademarked the dock. They've trademarked the entire look-and-feel of the Aqua user interface. It's a sum-of-all-parts thing, not an each-part-individually thing.
So fuck Apple. I have the right to make my UI look like whatever the hell I want to.
No, you don't. You have the right to make it look like whatever the hell you want up to the point where you're infringing on somebody else's trademark. This is just like names. If you make a beverage, you are free to call it whatever you want... but you obviously can't call it Coca-Cola. Similarly, you can name your company whatever you want... but you can't call it American Airlines.
Trademarks are a really simple idea, dude. I'm concerned and saddened that you don't get them. Perhaps your trouble is the fact that you're a moron?
Even in the face of comments like this, there are still people out there who wonder why the software industry hates and fears the open source movement. Amazing.
Uh-huh. Sounds to me like you're using your SAN "to let multiple computers talk to the same set of storage devices." In your case, you may be using a shared filesystem, or you may use LUN mapping to assign a unit of storage carved out of a central system to each computer on the SAN. In either case, this is a good example of what I was talking about.
SANs for storage consolidation, good. SANs for shared access to read-only data, good. SANs for shared access to read-write data, bad.
I assert to you that politics is a lousy reason to write software. Writing software for political reasons is like having a baby for the tax write-off. It just doesn't make sense.
And as for the translation, I did use Babelfish. That translation makes about as much sense to me as the instructions on a Japanese car part. It may be a perfect translation, and the original sentence was gibberish, or at least made no sense out of context.
Okay, I'm a geek. I didn't realize this would be a FAQ, because it never occurred to me that this would be a question at all, asked frequently or infrequently. I heard the name and thought, "Oh, yeah, Theora makes perfect since for a video codec since she was a television producer. Neat." And that was the end of it.
Slashdot Mirror
Yeah, and it will have the same effect on the laser weapon that it has on the stars, too. In other words, that'll be 100,000 watts of burning, annihilating, twinkling death raining down on you.
A laser will travel indefinately. If you miss your target, it's going to keep on going until it hits SOMETHING....
Um. Believe it or not, we have the same problem with missiles. If a missile misses, it just keeps going until it finds something to run into.
Strangely enough, we keep using them.
You seem to be forgetting that water is heavy.
"That craft on my tail is going to blast me if I don't zap it... LASER SAFETY OVERRIDE, FIRE, EJECT..."
Um... you do realize that you can accomplish the same ends just by pulling the bright yellow handle between your legs, right?
Nope, the treaty you mentioned is the Geneva Convention, and it bans weapons whose sole purpose is to blind. Just about any laser ranging or designation device can blind if used (or misused) in just the right way; none of these devices is regulated by the Geneva Convention.
The purpose of this laser weapon is to destroy stuff, not to blind people. So it's A-OK, too.
At these levels of power, the reflective material would have to reflect virtually all light in order to be safe. And when I say "virtually all," I mean on the order of 99.999%. I believe a 12 watt laser can cut through sheet aluminum pretty handily, and aluminum is both somewhat reflective and highly heat-conductive. A kilowatt-scale laser should be able to cut through just about anything, shiny or otherwise.
I cry I cry
I die die
No care for me.
I had a cat named Snowball.
She died! She died!
Mom said she was sleeping.
She lied! She lied!
-- Lisa Simpson
What you're talking about is absolutely possible. More than that, it's a key feature of fibre channel technology. And, in my sincerely humble opinion, it's really the only effective way to do a SAN: connect all the computers and all the storage devices to a big fabric, then give computers exclusive read-write or non-exclusive read-only access to each LUN. Shared access is hardly ever worth the trouble that goes into setting it up.
Your HP solution sounds pretty much like IRIS FailSafe, from SGI. The storage device is shared between two (or more) hosts, but only one host has access to it at any given time. When that host fails, the other host automatically mounts the storage device and takes up the failed node's responsibilities. Shared storage is a requirement for that kind of configuration; in the old days, we used to do it with SCSI.
I have no idea whether FireWire can support multiple hosts on a chain. Obviously it can handle more than one target, but I don't know about more than one initiator.
Also, the "LUN security" feature you talked about is sometimes called "LUN masking" or "LUN mapping," depending on how you do it. You can map a LUN to a switch port-- that's LUN mapping. Or you can set it up so that a port specifically doesn't see certain LUNs; that's LUN masking. I haven't worked with fibre channel on Windows in an age, but back when I did we had to use LUN mapping/LUN masking. At that time, the Windows host would try to send a device reset command to every LUN when it initialized its HBA. This was, of course, a very bad thing. So you had to set up your switch so that the Windows machines only saw the LUNs that they would be mounting. It was a little bit of a pain in the rear to set up, especially if the switch only supported LUN masking and not LUN mapping. If you add LUNs to your fabric, you have to go in and adjust all of your masks to mask the new LUNs out. On the other hand, if you use LUN mapping, the mapped ports will just ignore the new LUNs unless you specifically tell them not to.
:sigh:
So basically what you're saying is that the GPL means freedom, but only if you don't use it?
Face it, guys, this article spelled it out far more clearly than I ever could. The GPL should not-- must not, even-- be equated with freedom. It is restrictive, just like any other license. Six bleedin' pages of restrictions, for that matter. The BSD license is a truly free license: do whatever you want with this code. Period.
First of all, lock files aren't going to cut it. All we have to do is come up with a very simple scenario. You open up a file on the disk for reading, and start reading data out of it. You read a chunk, do something, then read another chunk.
Meanwhile, I come along and unlink the file.
In a single-access system, this isn't a problem. If I unlink the file while you've got it open, nothing really happens until you close it. After you close it, the file disappears and its space is reclaimed. This is because the kernel keeps track of who's got which files open, and prevents one process from pulling the rug-- so to speak-- out from under another process.
(This is also the source of the age-old trick of opening a file and immediately unlinking it. It's a good way of handling the automatic reclamation of temporary files.)
But if we've got two systems, each with a totally independent kernel, talking to the same disk, the problem suddenly gets a lot harder. When I unlink the file, my kernel will look at its tables and conclude that nobody else has the file open, so it will immediately try to reclaim the blocks on the disk. This will send your application, which is actively trying to read from the file, into shitfits.
No amount of lock files would save you in this situation. All I did was type "rm somefile." The rm command doesn't check for the presence of a lock file. Unless you want to rewrite all the file utilities, lock files aren't going to do the job.
(And extended attributes, of course, aren't portable. They're also tied to the inode, which raises its own set of problems.)
I just think you're grossly underestimating the complexity of this issue. If all you want is to share files across a network, then just use NAS. It'll work better and your life will be easier.
That's a common, and totally 100% wrong, misconception.
SAN and NAS are fundamentally different implementations. They have the same basic purpose: computer A and computer B need to access the same data on the same storage device at the same time. But that's where the similarities end.
NAS is strictly a client-server system. All the clients talk to the server, but not to each other. Clients make read requests to the server, which queues and handles the requests, caching the data along the way. The server handles things like file permissions, access control, locking, and synchronization issues. The server also arbitrates contention situations, by putting I/O requests into a queue.
Shared-access SANs are completely different. In a shared-access SAN there is no server, which means there's no central arbiter of things like permissions, access control, locking, synchronization, and request queuing. Instead, each client computer simply talks directly to the disks. In theory, taking out the middle man this way decreases latency and increases bandwidth, but in practice contention issues arise that eliminate any gains. Since there's no arbiter for things like permissions and access control, the clients all have to talk to one another somehow; that's where cluster-aware filesystems like CXFS or Centravision come in. These filesystem are complex in ways that most people fail to realize, and they are highly prone to failure. In particular, an election-based system like CXFS doesn't tolerate the coming and going of nodes to and from the cluster very well. At any time, any node can be the control node, and if it disappears, the filesystem can become wedged for a time until a new election occurs. So these types of filesystems work best in tightly coupled groups of systems, like highly available clusters, or parallel processing clusters.
SANs and NAS are only similar on the surface. Beneath the surface, they're very, very different.
Dude, with all respect, you're not hearing me. It is not possible to lock files at the application layer with a shared-access SAN. You have two independent application on two separate computers trying to access the same filesystem. No synchronization mechanism exists between them... unless you're planning to write one, which means we're back in special filesystem land. That would be an absurd amount of work for what you're actually trying to accomplish.
As for NFS-style locking, there is no server on which to run the lock daemon. If there were a server, we'd be talking about NAS instead of a SAN, which is a different thing altogether. With a SAN, there's nothing but computers and disks, and the disks are not smart. You can't do file locking at the disk level. You have to have a mechanism through which the two computers can communicate with each other directly... which puts us back into special filesystem territory yet again.
I'm not quite sure why, but it's clear that we're not communicating well here. What can I say to make this more clear to you?
How is it handled in a SAN normal envorment? Do it the same way.
Now you're starting to understand. Shared-access SANs are highly proprietary things requiring complex multi-node-aware filesystems, like Centravision or CXFS. It is not an easy thing. In most situations, it simply doesn't work at all.
Big SAN arrays have internal cache so I think they like for the OSes to do as little cacheing as possible.
First of all, there's no such thing as a "SAN array." There are disk arrays and storage systems that can be used on a SAN, but there's nothing special about them. They're just RAIDs, essentially, albeit sometimes with a few more bells and whistles.
And as for the caching thing, every operating system uses cached I/O for practically everything. (Direct, or unbuffered, I/O can be used in some situations where the data can be handled more efficiently by the application than by the OS; these situations are rare.) So let's say you and I are hooked up to the same hard drive. I open a file. Then you open the same file. I seek into the file and start reading. Let's say I read 1 MB of data into memory. Then you seek into the file and start writing. You write over the same blocks that I just read. I have no way of knowing this, of course, so I just keep doing what I'm doing, oblivious to the fact that the data I'm caching is out of date.
It gets worse. Say I decide to unlink the file... while you're in the middle of writing it. If we were talking about two applications on the same computer, I'd get an error back from the OS saying that you can't unlink an open file. (Or something, depending on the environment.) But since we're talking about two programs running on two different computers, I get no such error. Can't get one, in fact, unless my OS is keeping track of which files are currently open on your computer, and vice versa. Suddenly a normal filesystem won't work any more. We need something new, like CXFS or Centravision.
By this time, of course, we've given up on the whole damned thing and gone back to network-attached storage with Gigabit Ethernet interconnect. The last straw was the fact that my reading a file and your reading a file sent the shared drive into conniptions as the heads skittered all over the place. Disk contention is a bitch.
Shared-access SANs are incredibly complex. And, in general, they suck.
That's not what he was talking about. He was talking about using NFS or another IP-based networked filesystem. That's very different from what you're talking about.
And what you're talking about isn't such a great idea, either-- no offense. Leaving aside for a moment the technical challenges-- how do you turn a Linux system into a FireWire target, anyway?-- there would he serious cache coherency issues. How would you remotely invalidate a filesystem buffer cache, or a cached inode?
This issue is far more complex than you think it is.
Anybody can download Apple's source, read it, learn, and use Apple's ideas to implement their own software. People are prohibited merely from modifying Apple's code without telling Apple about it. This is a fine and good thing; Apple is sharing their innovations while still holding on to their valuable intellectual property. This is most certainly giving back to the community.
And yet you find fault anyway. Why is that, I wonder?
The problem here is that you, dh003i, have a political agenda. This agenda, which is based on the idea that no corporation or individual should own intellectual property, is incompatible with the modern world. This is why you have plenty of things to complain about. This is also why your complaints are irrelevant.
Let me show you what I mean. For purposes of discussion, I will adopt a political agenda. Let's say that agenda is... environmentalism. My goal in life is to protect the environment.
I now observe that the Apple license is notably silent on the subject of greenhouse gas emissions. According to the APSL, anybody can download Apple's source code while continuing to use as many fossil fuels and CFC's as they want! The license does not restrict in any way one's use of plastics or aluminum; it doesn't even have the standard clause that says, "All printed copies of this license must be recycled in an environmentally friendly paper recycling facility!" This license sucks!
See what I mean? If your agenda is orthogonal to the purpose of the license, you will find many things to which to object. But your objections will be meaningless, and they will be ignored.
I can't understand how anybody with even the slightest understand of how business works would say such a thing.
As much as I hate to say it, I think that Microsoft might actually have a point. A sizable fraction of the "free" software advocates out there-- including you, dh003i-- hold intractable anti-business positions. That concerns me.
On the one hand, we have the corporate world. Big companies doing business. On the other hand, we have the "free" software folks. I don't like to think that these two groups are in opposition to one another, but it sounds like they are after all. At least, the "free" software folks oppose the corporate world. The corporate world still seems to be pretty indifferent to the "free" software people, which is a good thing.
Anyway, you have these two groups, in opposition to one another. Comparing the contributions to the world that the "free" software people have made-- some software that's only useful to a tiny fraction of the population-- to the contributions to the world that the corporations have made-- in with a lot of bad stuff, a lot of good stuff like medicines and abundant food and relatively inexpensive housing-- I have to say that I'd side with the corporations.
Yeah, you people have the right to criticize Apple's license. And lord knows you exercise that right; the "free" software people are the most critical gang I've ever encountered. But that doesn't make you right. You're still a bunch of immature idealists who haven't really thought about the implications of what it is that you're advocating.
Anyway, the way they've been acting over the aqua interface is pathetic. They should have let people copy the aqua theme.
No offense, but you appear to lack a basic understanding of branding and marketing.
Apple wants people to buy Macs. Fundamentally, I think many people in Apple's upper management have higher motives-- their recent decisions show that they want to create new and beautiful things that make people's lives better-- but, as a company, they just want people to buy Macs.
Why do people buy Macs instead of other computers? Each Mac owner has his own set of reasons, but if you boil them all down you'll find that people buy Macs because they're Macs. Macs are different from other computers.
A Dell is pretty much the same as a Gateway, is pretty much the same as a Compaq as far as personal computers go. They all run the same software and do the same things. They differentiate from one another on price and on the way the case looks.
Macs are differentiated in several ways. Their industrial design is different. Their applications-- like iTunes and iPhoto and whatnot-- are different. And, yeah, their look-and-feel is different.
Take away what's different, and you lose the thing that makes a Mac a Mac. People lose their reason to buy a Mac-- after all, the only reason people buy Macs is because they're Macs, right?
So Apple has a vested interest in keeping Macs different from other computers. That extends to all aspects of "differentness," including the design and appearance of the user interface.
Apple would have been foolish if they hadn't defended their Aqua-related trademarks. They would have been giving away their market differentiation, which is the only thing that keeps them in business.
Based on the tone and content of your comment, I do not expect you to agree with this, or even to understand it. But it's the truth.
Apple took plenty from the FS / OSS communities via the UNIX-tools they incorporated into OS X. They pretty much took it unmodified and recompiled it for Apple hardware. A little bit hypocritical for them to ask that no one copy some of their good ideas. :sigh:
Apple took what was freely given (FreeBSD), and combined it with what was already theirs (NeXT's IP) and some new things (Quartz, Aqua) to come up with OS X.
Get that? Apple took what had been freely given. They are under no obligation-- moral, legal, or otherwise-- to give anything in return. They do so anyway.
And yet you say they're not doing enough.
You zealots amaze me.
Well, NeXT's dock goes back to about 1990. Find us a reference to a dock in use before that, and we'll accept that you're right. Until then....
But this is all pretty pointless. Apple hasn't (as far as I know) trademarked the dock. They've trademarked the entire look-and-feel of the Aqua user interface. It's a sum-of-all-parts thing, not an each-part-individually thing.
socialist radicals
You say that as if it's a bad thing.
It is a bad thing. Read your history.
So fuck Apple. I have the right to make my UI look like whatever the hell I want to.
No, you don't. You have the right to make it look like whatever the hell you want up to the point where you're infringing on somebody else's trademark. This is just like names. If you make a beverage, you are free to call it whatever you want... but you obviously can't call it Coca-Cola. Similarly, you can name your company whatever you want... but you can't call it American Airlines.
Trademarks are a really simple idea, dude. I'm concerned and saddened that you don't get them. Perhaps your trouble is the fact that you're a moron?
Even in the face of comments like this, there are still people out there who wonder why the software industry hates and fears the open source movement. Amazing.
Uh-huh. Sounds to me like you're using your SAN "to let multiple computers talk to the same set of storage devices." In your case, you may be using a shared filesystem, or you may use LUN mapping to assign a unit of storage carved out of a central system to each computer on the SAN. In either case, this is a good example of what I was talking about.
SANs for storage consolidation, good. SANs for shared access to read-only data, good. SANs for shared access to read-write data, bad.
I assert to you that politics is a lousy reason to write software. Writing software for political reasons is like having a baby for the tax write-off. It just doesn't make sense.
And as for the translation, I did use Babelfish. That translation makes about as much sense to me as the instructions on a Japanese car part. It may be a perfect translation, and the original sentence was gibberish, or at least made no sense out of context.
Okay, I'm a geek. I didn't realize this would be a FAQ, because it never occurred to me that this would be a question at all, asked frequently or infrequently. I heard the name and thought, "Oh, yeah, Theora makes perfect since for a video codec since she was a television producer. Neat." And that was the end of it.
I'm such a nerd.