10gp weigh a pound, so 5000gp is 500 pounds of gold. At around $965 an ounce, and 16 ounces to a pound (am I using the right pounds?) that works out to $7,720,000.00.
A VS1/D diamond in the 1.0 caret range runs about $10,500.00 per caret. So that's about 735 carets of very nice diamonds.
Paul
P.S. That's all 3rd Edition and 3.5 Edition numbers. I don't recall what Gary's own rules said, and that'd be the right set of guidelines to use...
Aren't certain Sun Microsystems implementations of SPARC doing pretty well in terms of performance per watt, compared to x86?
In fact, aren't almost all x86 processors spectacularly bad at power consumption, with the exception of Intel's Core 2 sub-architecture? Sure. There are probably lots of better choices from a purely technical standpoint.
But from a shipping-a-product standpoint, I can imagine there are more requirements than "in theory, this will work." I bet that availability was a concern, as was future stability.
I could see an argument that betting the farm on Sun might not be a good long-term strategy. I don't know enough to know if I'd agree, but I imagine that was at least one of the considerations.
And while I don't know the specifics of each processor's power consumption, I'm willing to bet they were looked at. The PowerPC roadmap had spectacularly bad power consumption for performance. The move to x86 might just have been the simplest way to solve a power problem, and some related problems.
As someone else mentioned, no PowerPC-based processors were even on the roadmap at the time that would give PowerPC G5 performance with anything close to reasonable power consumption for a laptop. Sure, Freescale was making low-power CPUs, but they didn't have decent performance for high-bandwidth video, etc.
Plus, Freescale didn't exactly have a long-term track record of delivering on time. Neither IBM nor Motorola met their goals in time to meet Apple's publicly stated objectives. There was no reason to think Freescale wouldn't slip, too.
The reason given, which people seem to keep forgetting, was pretty simple and believable:
Performance per watt.
The PPC architecture was not improving _at all_ in performance per watt. Apple's market was growing fastest in the portable space, but it was becoming impossible to keep temperatures and power consumption down with PPC processors.
And IBM's future plans for the product line were focusing on the Power series (for high-end servers) and the Core processors (for Xbox 360's) and not on the PowerPCs themselves.
While I've never had any particular love for the x86 instruction sets, I, for one, enjoy the performance of my Macbook Pro Core 2 Duo, and the fact that it doesn't burn my lap off, like a PowerPC G5-based laptop would.
The patch was in Mac OS X 10.4.5, I believe. I've seen no announcement or suggestion of new timezone files for any earlier releases of Mac OS X.
The Java 1.4.2_09 shipping with Mac OS X 10.4.x doesn't include the timezone changes, nor will it. Unless Apple ships a new Java 1.4.2, the only Java supporting the new timezone changes on Mac OS X is Java 5.
It also looks like WebObjects uses its own timezone files, and these haven't been updated in quite a while. Anyone doing any time/date manipulation in a WO app will want to look at that pretty closely.
If you had read any of the many linked articles about ZFS, they'd have answered these questions, and then you wouldn't look silly, blathering in public about stuff that ZFS doesn't do.
But since you won't, here's what they would have told you:
When an application writes to a file, ZFS doesn't overwrite existing blocks. That's what "copy on write" is. This means, if you have a file that's 1024K long, then write one block of data (say, 4K) over part of the original file, it keeps the entire original file and your new 4K block is written somewhere new.
ZFS does not hash every block of every piece of data you write, and search your disk, Google, and your underwear drawer to see if it happens to already be there.
It just allocates a new block for every write, rather than overwriting data. Which is really, really, amazingly useful when you want a snapshot, or you want to recover your data when the drive lost power _during_ the write.
Apple's LOM does not provide a remote console login.
The only supported remote login solution is Apple Remote Desktop. This is not available until the system has come up completely, and is not capable of tasks like "repair the boot filesystem in single-user mode."
There may be some limited, unsupported serial port functionality, not via the LOM. This, too, cannot allow you to select a boot device or otherwise interact the boot process.
If you believe otherwise, I'd love to hear specifics?
This is the same guy who held the fake Mac worm contest.
His track record shows a history of stealing products from other companies and selling them as his own, or designing "great new products" and disappearing with the investment money.
His reputation is foul, at best, and my personal dealings with him have upheld that reputation.
He is perfectly happy pimping Slashdot for publicity while he (presumably) bilks investors or whatever it is he is doing to make a quick buck.
Read the Design of Everyday Things, an incredible book.
Almost everything people do with a device requires some pre-knowledge. When you walk into a dark room, you reach for a lightswitch. Where is it? It's where you expect it to be. When it isn't, that is a source of frustration.
What pre-knowledge do people have of mouse buttons? None. You know that right-clicking brings up options specific to the item the mouse is pointing to, not because it's obvious, but because you learned it.
Many applications in many operating systems offer options only reachable from a right-click. These options are not visible on the screen, nor do they descend from anything marked as a menu. They're magical.
How often have you right-clicked on something, and nothing happened, because the application author didn't create any functionality there?
How many applications on Windows and other OSes have places where right-clicking doesn't provide a menu, but instead performs a specific action?
How frustrating is it when the lightswitch is on the other side of that dark room?
On Mac OS X, there is _no_ right-click action. Ever. Control-click brings up a contextual menu, which, according to the human interface guidelines, should contain no options that are not available elsewhere. Right-click is a shortcut to the contextual menu, which itself is a shortcut to other actions elsewhere in the _visible_ interface.
What does that mean? It means my Mom never has to call me to ask how to do something that's apparently a "secret" only for people who use computers on a daily basis.
I have used plenty of Macs. I've used plenty of Windows machines. I've used FreeBSD on a laptop for a year in a company where IT insisted we all use Windows. I have multi-button mice on most of my Macs, but only for the scroll wheels.
I find myself only using the right button in those applications which I use often enough that I care about shortcuts. And I typically prefer keyboard shortcuts over right-clicks.
The real question is this: if you need a second button on your mouse to be productive, why doesn't a third make you even more productive? Or a fourth? Or a fifth?
The additional buttons are for additional actions. Pointing and clicking make a lot of sense as metaphors. But multiple buttons with which to click are just bad interface design.
I imagine that left-clicking and right-clicking are hard skills to pick up for severely dyslexic folks, too.
Having worked with a large number of cross-platform environments, I can assure you that the "problems" that occur with formatting also occur between Windows computers running various versions of Office. Or even the same version of Office. I once spent 20 minutes trying to explain to someone that there was nothing _I_ could do to make her resume look the same on my computer as it did on hers, since we both had Windows 2000, and we both had Office 2000, and the resume was an Office 2000 document, and used the standard Windows-installed fonts.
People who use Word day-to-day typically are quickly stripped of any expectation of consistency of presentation across computers...
So such a problem won't be a big deal between platforms, where there's at least a buyable explanation.
I ran the original distributed.net RC5 client on one CPU of an 8-cpu C-90. It got about 85Kkeys/sec. Yes, that's _85_. Not 600+ like intel processors of the time get.
C-90's do vectors. They don't do integer work. vi? slow as a dog. emacs? slow as a dog. CFD simulations? it'll knock your socks off.
Most people were very surprised when they would log in and see how _slow_ it was running a shell. Think 2-3 seconds to get a response to the 'date' command.
Would you use a sprint car to go to the grocery store? Wouldn't get you there any faster than my Geo Metro, would it?
C-90's are incredible machines; the details would fill you with awe. But given that there's no hardware documentation available, and hence no OS's other than COS and Unicos for them, and limitations like _no MMU_, it's really only useful for batch processing of vector work, i.e. floating point.
It'd make a kick-ass rendering back-end, if you could get someone to write the software. Otherwise, leave it alone.
"this is the first message" "now here is the second string"
(i guessed at the last part, since they were of unequal length).
it took me about 15 minutes to hack together some perl code to help me do it--easier than doing it by hand.
and i've never done this before.;-)
it's amazingly simple, actually. you have two plaintexts, T1 and T2, a key, K, and two ciphertexts, C1 and C2. you're trying to find T1 and T2. you don't know (and don't really care about) K, and you know C1 and C2.
so you have:
C1= T1 XOR K C2= T2 XOR K
now the problem is, we don't know K. so we think about things briefly and suddenly realize:
C1 XOR C2 = T1 XOR T2
which takes the key entirely out of things, making it simply a case of finding two plaintexts XORed together. which is a piece of cake (especially for simple plaintexts like what you provided).
specifically, i took C1 XOR C2 (call it R) and went through it sequentially, XORing the string ' the ' (with the spaces).
this gave me two hits: 07.......e is 11........... firs
figuring it was likely that this string occurred in both T1 and T2, and unlikely that it occurred twice in any one string in such close proximity, i figured these were each parts of T1 and T2, respectively.
then i XORed ' first ' with R in the right spot, and it gave me ' the se'. i tried all the letters a-z after the 'se' which formed part of a word, i.e. not 'sez' or 'sek' or 'sej'.
with some experimentation, part of the message became clear, and it was easy to extrapolate to get the rest.
with some effort, a program could be written to throw a dictionary at it (in nearly any language, and any character encoding or file format) and see what develops. pretty straightforward stuff.
The site that I administer is run using apache under IRIX. While I don't actually like IRIX, it provides a utility IMON which is necessary for our configuration.
We have a source host where user accounts are made. Each user can log into this host and access the html source files as necessary. Editing is handled via normal user and group permissions. This machine DOES NOT have apache installed. This machine only answers on port 22 (for ssh access).
A second "server" host runs apache. This machine only answers on port 80 and port 22 (apache and sshd), plus a selected high port (described later).
The source host uses IMON to monitor the inodes of all files in all directories containing HTML source. When a file is modified, the file info is passed to a daemon which then transfers the file (via that high port mentioned above) to the actual server.
In the process, the ownership and permissions of the file are modified to meet policy--users have no control over file permissions on the actual web server.
The transfer is accomplished with a daemon that listens on a high port and uses SSL to transfer the file. The daemon requires that the connection be both from the proper IP and provide the proper certification, to prevent spoofing.
Finally, the web server runs as a user 'apache'. The files are all owned by a user 'webuser'. Both are members of group 'web', and read permission is set on the files to allow the HTML source files to be read by the web server, but not written. No files or directories are owned by the web server. A regularly-run find command reports any files that are owned by the web server.
The web server also runs in a chrooted environment. Neither the real root or the chroot environment have any "evil" utilities installed. All binaries have been removed and only replaced when a need for them was demonstrated.
CGI access is even more strictly limited. Any user requesting CGI access is given an account on a test web server. This test server only accepts connections (via router filters) from limited hosts. This server runs apache and allows the users to code their CGI's. When a user is ready to "publish" their code, they request an account for it. Two accounts are made on the "server" machine: one for the cgi-bin script itself, and one for its data.
All data files are created and chown'ed to the data user. The cgi code is installed and chown'ed to the script user. No directories are owned by either user.
Because a new set of users is generated for _each_ CGI, there is no easy way for one cgi to overwrite/change/read data owned by another. Each cgi runs as a unique user, with data files owned by another user, and a common group used to allow write access.
This also leaves the cgi's themselves, and their data files, unreadable to the apache user.
Any unauthorized user who gains access to any one of these uid's is still strictly limited in what they can do. No X binaries are available on the web servers. The only "easy" avenue of attack is the source server, which is protected in the usual ways, including sitting on a subnet which is not visible from outside our network.
As a result, our users (we have 200+ people preparing web pages) have relatively simple access to their pages, while anyone attempting to crack the servers will be hard pressed to see results.
If your server is going to be relatively static, without any cgi or any other need to write data, you can run the server chrooted to a read-only null_fs partition, allowing regular users access to the real partition, but giving the web server no ability to write any data anywhere. Or run two servers, one set up this way to access the static content, and a second just for cgi, on another port.
--plambert
Exactly how is the Win95 / MacOS easier than KDE?
on
After Linux-Apple?
·
· Score: 1
Apple has spent a great deal of money learning what people really want. And as annoying as it may be sometimes, people won't use things they don't want.
All of Apple's research has shown, for example, that most users prefer a one-button mouse. I, personally, use a three-button trackball, on any machine I possibly can.
But I am not Apple's target audience. Readers of/. are not Apple's target customers.
My Mom prefers a one-button mouse. Most people off the street prefer a one-button mouse. Sure, it'd be nice to have a forty-two button mouse, completely changeable window managers, etc, but who is going to teach everyone to use them?
Read the Design of Everyday Things, by Donald A. Norman, ISBN 0385267746. It's $12.76 at Amazon.com as I write this, and well worth every penny.
Sure KDE offers advantages. So do manual transmissions, but people buy automatics. No one really cares how _powerful_ a tool _can be_, if they don't know how to use it, and don't want to invest the time to learn.
Apple's strengths lie in their (mostly) strict adherance to their Human Interface Guidelines. Ease-of-use is something that many power users forget.
My favorite editor is vi. I can do things with it that people using Word can only dream about. Yet, I'm not teaching my brother how to use it. He uses AppleWorks. It has fewer features than Word, and fewer features than emacs, and yet, he gets far more done with it than he could with either of those, because he really, truly, honestly doesn't care to learn how to use them.
Slashdot Mirror
The iPhone doesn't have a page file. It doesn't swap anything to disk.
10gp weigh a pound, so 5000gp is 500 pounds of gold. At around $965 an ounce, and 16 ounces to a pound (am I using the right pounds?) that works out to $7,720,000.00.
A VS1/D diamond in the 1.0 caret range runs about $10,500.00 per caret. So that's about 735 carets of very nice diamonds.
Paul
P.S. That's all 3rd Edition and 3.5 Edition numbers. I don't recall what Gary's own rules said, and that'd be the right set of guidelines to use...
In fact, aren't almost all x86 processors spectacularly bad at power consumption, with the exception of Intel's Core 2 sub-architecture? Sure. There are probably lots of better choices from a purely technical standpoint.
But from a shipping-a-product standpoint, I can imagine there are more requirements than "in theory, this will work." I bet that availability was a concern, as was future stability.
I could see an argument that betting the farm on Sun might not be a good long-term strategy. I don't know enough to know if I'd agree, but I imagine that was at least one of the considerations.
And while I don't know the specifics of each processor's power consumption, I'm willing to bet they were looked at. The PowerPC roadmap had spectacularly bad power consumption for performance. The move to x86 might just have been the simplest way to solve a power problem, and some related problems.
As someone else mentioned, no PowerPC-based processors were even on the roadmap at the time that would give PowerPC G5 performance with anything close to reasonable power consumption for a laptop. Sure, Freescale was making low-power CPUs, but they didn't have decent performance for high-bandwidth video, etc.
Plus, Freescale didn't exactly have a long-term track record of delivering on time. Neither IBM nor Motorola met their goals in time to meet Apple's publicly stated objectives. There was no reason to think Freescale wouldn't slip, too.
Sorry, typo, I did not mean to capitalize core.
The point remains: IBM's roadmap was (and is) _ugly_ for notebooks and low-power general purpose computers.
I imagine Apple might have been looking at other markets, but surely didn't want to be forced into other markets by their supplier.
The reason given, which people seem to keep forgetting, was pretty simple and believable:
Performance per watt.
The PPC architecture was not improving _at all_ in performance per watt. Apple's market was growing fastest in the portable space, but it was becoming impossible to keep temperatures and power consumption down with PPC processors.
And IBM's future plans for the product line were focusing on the Power series (for high-end servers) and the Core processors (for Xbox 360's) and not on the PowerPCs themselves.
While I've never had any particular love for the x86 instruction sets, I, for one, enjoy the performance of my Macbook Pro Core 2 Duo, and the fact that it doesn't burn my lap off, like a PowerPC G5-based laptop would.
The patch was in Mac OS X 10.4.5, I believe. I've seen no announcement or suggestion of new timezone files for any earlier releases of Mac OS X.
The Java 1.4.2_09 shipping with Mac OS X 10.4.x doesn't include the timezone changes, nor will it. Unless Apple ships a new Java 1.4.2, the only Java supporting the new timezone changes on Mac OS X is Java 5.
It also looks like WebObjects uses its own timezone files, and these haven't been updated in quite a while. Anyone doing any time/date manipulation in a WO app will want to look at that pretty closely.
If you had read any of the many linked articles about ZFS, they'd have answered these questions, and then you wouldn't look silly, blathering in public about stuff that ZFS doesn't do.
But since you won't, here's what they would have told you:
When an application writes to a file, ZFS doesn't overwrite existing blocks. That's what "copy on write" is. This means, if you have a file that's 1024K long, then write one block of data (say, 4K) over part of the original file, it keeps the entire original file and your new 4K block is written somewhere new.
ZFS does not hash every block of every piece of data you write, and search your disk, Google, and your underwear drawer to see if it happens to already be there.
It just allocates a new block for every write, rather than overwriting data. Which is really, really, amazingly useful when you want a snapshot, or you want to recover your data when the drive lost power _during_ the write.
Apple's LOM does not provide a remote console login.
The only supported remote login solution is Apple Remote Desktop. This is not available until the system has come up completely, and is not capable of tasks like "repair the boot filesystem in single-user mode."
There may be some limited, unsupported serial port functionality, not via the LOM. This, too, cannot allow you to select a boot device or otherwise interact the boot process.
If you believe otherwise, I'd love to hear specifics?
Contact iTunes University.
/
http://www.apple.com/education/solutions/itunes_u
This is the same guy who held the fake Mac worm contest.
His track record shows a history of stealing products from other companies and selling them as his own, or designing "great new products" and disappearing with the investment money.
His reputation is foul, at best, and my personal dealings with him have upheld that reputation.
He is perfectly happy pimping Slashdot for publicity while he (presumably) bilks investors or whatever it is he is doing to make a quick buck.
http://www.macintouch.com/mactable.html
Read the Design of Everyday Things, an incredible book.
Almost everything people do with a device requires some pre-knowledge. When you walk into a dark room, you reach for a lightswitch. Where is it? It's where you expect it to be. When it isn't, that is a source of frustration.
What pre-knowledge do people have of mouse buttons? None. You know that right-clicking brings up options specific to the item the mouse is pointing to, not because it's obvious, but because you learned it.
Many applications in many operating systems offer options only reachable from a right-click. These options are not visible on the screen, nor do they descend from anything marked as a menu. They're magical.
How often have you right-clicked on something, and nothing happened, because the application author didn't create any functionality there?
How many applications on Windows and other OSes have places where right-clicking doesn't provide a menu, but instead performs a specific action?
How frustrating is it when the lightswitch is on the other side of that dark room?
On Mac OS X, there is _no_ right-click action. Ever. Control-click brings up a contextual menu, which, according to the human interface guidelines, should contain no options that are not available elsewhere. Right-click is a shortcut to the contextual menu, which itself is a shortcut to other actions elsewhere in the _visible_ interface.
What does that mean? It means my Mom never has to call me to ask how to do something that's apparently a "secret" only for people who use computers on a daily basis.
I have used plenty of Macs. I've used plenty of Windows machines. I've used FreeBSD on a laptop for a year in a company where IT insisted we all use Windows. I have multi-button mice on most of my Macs, but only for the scroll wheels.
I find myself only using the right button in those applications which I use often enough that I care about shortcuts. And I typically prefer keyboard shortcuts over right-clicks.
The real question is this: if you need a second button on your mouse to be productive, why doesn't a third make you even more productive? Or a fourth? Or a fifth?
The additional buttons are for additional actions. Pointing and clicking make a lot of sense as metaphors. But multiple buttons with which to click are just bad interface design.
I imagine that left-clicking and right-clicking are hard skills to pick up for severely dyslexic folks, too.
It may check your IP address, but that can be easily circumvented; they surely wouldn't rely on just that.
I believe the point is that the iTunes Music Store requires that any credit card used have an address inside the United States.
Reselling gift certificates would then allow folks outside the U.S. to access the store as if they were in the U.S.
Except I think you have to have valid credit card information whether or not you use a gift certificate. I am not certain, though.
--plambert
That'd be Symantec.
HTH.
--plambert
Having worked with a large number of cross-platform environments, I can assure you that the "problems" that occur with formatting also occur between Windows computers running various versions of Office. Or even the same version of Office. I once spent 20 minutes trying to explain to someone that there was nothing _I_ could do to make her resume look the same on my computer as it did on hers, since we both had Windows 2000, and we both had Office 2000, and the resume was an Office 2000 document, and used the standard Windows-installed fonts.
People who use Word day-to-day typically are quickly stripped of any expectation of consistency of presentation across computers...
So such a problem won't be a big deal between platforms, where there's at least a buyable explanation.
--plambert
Because they want the speed and performance of SGI's clustering protocols, and not the generic flexibility of a clustering system.
You speak with the words of a master, but only the _meaning_ of a master implies mastery, young grasshopper.
--plambert
I ran the original distributed.net RC5 client on one CPU of an 8-cpu C-90. It got about 85Kkeys/sec. Yes, that's _85_. Not 600+ like intel processors of the time get.
C-90's do vectors. They don't do integer work. vi? slow as a dog. emacs? slow as a dog. CFD simulations? it'll knock your socks off.
Most people were very surprised when they would log in and see how _slow_ it was running a shell. Think 2-3 seconds to get a response to the 'date' command.
Would you use a sprint car to go to the grocery store? Wouldn't get you there any faster than my Geo Metro, would it?
C-90's are incredible machines; the details would fill you with awe. But given that there's no hardware documentation available, and hence no OS's other than COS and Unicos for them, and limitations like _no MMU_, it's really only useful for batch processing of vector work, i.e. floating point.
It'd make a kick-ass rendering back-end, if you could get someone to write the software. Otherwise, leave it alone.
--plambert
"this is the first message"
;-)
;-)
"now here is the second string"
(i guessed at the last part, since they were of unequal length).
it took me about 15 minutes to hack together some perl code to help me do it--easier than doing it by hand.
and i've never done this before.
it's amazingly simple, actually. you have two plaintexts, T1 and T2, a key, K, and two ciphertexts, C1 and C2. you're trying to find T1 and T2. you don't know (and don't really care about) K, and you know C1 and C2.
so you have:
C1= T1 XOR K
C2= T2 XOR K
now the problem is, we don't know K. so we think about things briefly and suddenly realize:
C1 XOR C2 = T1 XOR T2
which takes the key entirely out of things, making it simply a case of finding two plaintexts XORed together. which is a piece of cake (especially for simple plaintexts like what you provided).
specifically, i took C1 XOR C2 (call it R) and went through it sequentially, XORing the string ' the ' (with the spaces).
this gave me two hits:
07.......e is
11........... firs
figuring it was likely that this string occurred in both T1 and T2, and unlikely that it occurred twice in any one string in such close proximity, i figured these were each parts of T1 and T2, respectively.
then i XORed ' first ' with R in the right spot, and it gave me ' the se'. i tried all the letters a-z after the 'se' which formed part of a word, i.e. not 'sez' or 'sek' or 'sej'.
with some experimentation, part of the message became clear, and it was easy to extrapolate to get the rest.
with some effort, a program could be written to throw a dictionary at it (in nearly any language, and any character encoding or file format) and see what develops. pretty straightforward stuff.
does that answer your question?
--plambert
The site that I administer is run using apache under IRIX. While I don't actually like IRIX, it provides a utility IMON which is necessary for our configuration.
We have a source host where user accounts are made. Each user can log into this host and access the html source files as necessary. Editing is handled via normal user and group permissions. This machine DOES NOT have apache installed. This machine only answers on port 22 (for ssh access).
A second "server" host runs apache. This machine only answers on port 80 and port 22 (apache and sshd), plus a selected high port (described later).
The source host uses IMON to monitor the inodes of all files in all directories containing HTML source. When a file is modified, the file info is passed to a daemon which then transfers the file (via that high port mentioned above) to the actual server.
In the process, the ownership and permissions of the file are modified to meet policy--users have no control over file permissions on the actual web server.
The transfer is accomplished with a daemon that listens on a high port and uses SSL to transfer the file. The daemon requires that the connection be both from the proper IP and provide the proper certification, to prevent spoofing.
Finally, the web server runs as a user 'apache'. The files are all owned by a user 'webuser'. Both are members of group 'web', and read permission is set on the files to allow the HTML source files to be read by the web server, but not written. No files or directories are owned by the web server. A regularly-run find command reports any files that are owned by the web server.
The web server also runs in a chrooted environment. Neither the real root or the chroot environment have any "evil" utilities installed. All binaries have been removed and only replaced when a need for them was demonstrated.
CGI access is even more strictly limited. Any user requesting CGI access is given an account on a test web server. This test server only accepts connections (via router filters) from limited hosts. This server runs apache and allows the users to code their CGI's. When a user is ready to "publish" their code, they request an account for it. Two accounts are made on the "server" machine: one for the cgi-bin script itself, and one for its data.
All data files are created and chown'ed to the data user. The cgi code is installed and chown'ed to the script user. No directories are owned by either user.
Because a new set of users is generated for _each_ CGI, there is no easy way for one cgi to overwrite/change/read data owned by another. Each cgi runs as a unique user, with data files owned by another user, and a common group used to allow write access.
This also leaves the cgi's themselves, and their data files, unreadable to the apache user.
Any unauthorized user who gains access to any one of these uid's is still strictly limited in what they can do. No X binaries are available on the web servers. The only "easy" avenue of attack is the source server, which is protected in the usual ways, including sitting on a subnet which is not visible from outside our network.
As a result, our users (we have 200+ people preparing web pages) have relatively simple access to their pages, while anyone attempting to crack the servers will be hard pressed to see results.
If your server is going to be relatively static, without any cgi or any other need to write data, you can run the server chrooted to a read-only null_fs partition, allowing regular users access to the real partition, but giving the web server no ability to write any data anywhere. Or run two servers, one set up this way to access the static content, and a second just for cgi, on another port.
--plambert
Apple has spent a great deal of money learning what people really want. And as annoying as it may be sometimes, people won't use things they don't want.
/. are not Apple's target customers.
All of Apple's research has shown, for example, that most users prefer a one-button mouse. I, personally, use a three-button trackball, on any machine I possibly can.
But I am not Apple's target audience. Readers of
My Mom prefers a one-button mouse. Most people off the street prefer a one-button mouse. Sure, it'd be nice to have a forty-two button mouse, completely changeable window managers, etc, but who is going to teach everyone to use them?
Read the Design of Everyday Things, by Donald A. Norman, ISBN 0385267746. It's $12.76 at Amazon.com as I write this, and well worth every penny.
Sure KDE offers advantages. So do manual transmissions, but people buy automatics. No one really cares how _powerful_ a tool _can be_, if they don't know how to use it, and don't want to invest the time to learn.
Apple's strengths lie in their (mostly) strict adherance to their Human Interface Guidelines. Ease-of-use is something that many power users forget.
My favorite editor is vi. I can do things with it that people using Word can only dream about. Yet, I'm not teaching my brother how to use it. He uses AppleWorks. It has fewer features than Word, and fewer features than emacs, and yet, he gets far more done with it than he could with either of those, because he really, truly, honestly doesn't care to learn how to use them.
And frankly, that's how the real world works.