There is so much friggin' voodoo science in the audio biz (both pro audio AND home audio) that it isn't funny. But it's such a metaphysical battle that those who try to use REAL science and common sense need not apply.
I noticed that if I load Doom onto my machine from different download sources, the creatures actually look different! And the flaming skulls just aren't as "crisp" if I save the distribution for more than a week.
Since I don't work for Sun, there's no pressure to maintain the image of "one OS is enough." We have a very mixed environment here. Most people use PCs with Windows, and many use Sun/Solaris boxes. Since the corporate types settled on Exchange/Outlook as the corporate mail system, they had to make that system available to all users.
To get it all to work, the engineering community (the primary Sun users) access Citrix servers via the ICA client for Solaris. With that, they can do their Outlook thing, and also get to the whole MS Office suite. It seems to integrate nicely with all the other apps.
I work in a fairly large company with thousands of Sun users. Generally speaking, homedirs and application are NFS mounted. And NIS lets any user log in anywhere inside the company as needed.
Yeah, it lets users move around, but that's not the biggest reason we do things this way. People still have their own cubes, and their own desks. But if their machine dies -- like via a HD failure something -- they can just move over to a vacant machine and continue their work.
Plus, establishing a standard OS load (jumpstart, in Sun terms), and building standard build scripts, we can make easy-to-swap machines for our users. Need a newer machine? Sure -- just log out, swap boxes, and log in. no muss, no fuss.
I also do almost exclusive perl. And I have to deal with several legacy web apps that are failry complicated. I totally agree with commenting logical blocks of code. And I have a few other places that are useful for reverse-engineers...
- If you have a fairly long subroutine, it helps the reader to comment the begninning AND the END of the block. Something like:
# Comment briefly describing the upcoming block of code
sub this_thing {
lengthy bit of code
} # End of this_thing
And how about this:
- Say you build a group of files where an executable chunk requires several other files. When you use a variable that is established/initialized in the "required" file, drop in a comment to tell the reader where the hell you got it from. It is extremely frustrating to see variables magically appear in a file, and then have to back-track a variable through 20 other files to figure out what you're doing with the value.
Slashdot Mirror
If they can retrofit a flat head and a mouth with lips, I'll be the first in line to buy it.
I looked it up and did the math. Consider an area a little over 4 times the land area of the entire UK.
FWIW, I don't even think most of us "damn yanks" have a concept of the size of Texas (or any of the states, for that matter).
There is so much friggin' voodoo science in the audio biz (both pro audio AND home audio) that it isn't funny. But it's such a metaphysical battle that those who try to use REAL science and common sense need not apply.
I noticed that if I load Doom onto my machine from different download sources, the creatures actually look different! And the flaming skulls just aren't as "crisp" if I save the distribution for more than a week.
Since I don't work for Sun, there's no pressure to maintain the image of "one OS is enough." We have a very mixed environment here. Most people use PCs with Windows, and many use Sun/Solaris boxes. Since the corporate types settled on Exchange/Outlook as the corporate mail system, they had to make that system available to all users.
To get it all to work, the engineering community (the primary Sun users) access Citrix servers via the ICA client for Solaris. With that, they can do their Outlook thing, and also get to the whole MS Office suite. It seems to integrate nicely with all the other apps.
I work in a fairly large company with thousands of Sun users. Generally speaking, homedirs and application are NFS mounted. And NIS lets any user log in anywhere inside the company as needed.
Yeah, it lets users move around, but that's not the biggest reason we do things this way. People still have their own cubes, and their own desks. But if their machine dies -- like via a HD failure something -- they can just move over to a vacant machine and continue their work.
Plus, establishing a standard OS load (jumpstart, in Sun terms), and building standard build scripts, we can make easy-to-swap machines for our users. Need a newer machine? Sure -- just log out, swap boxes, and log in. no muss, no fuss.
I also do almost exclusive perl. And I have to deal with several legacy web apps that are failry complicated. I totally agree with commenting logical blocks of code. And I have a few other places that are useful for reverse-engineers...
- If you have a fairly long subroutine, it helps the reader to comment the begninning AND the END of the block. Something like:
# Comment briefly describing the upcoming block of code
sub this_thing {
lengthy bit of code
} # End of this_thing
And how about this:
- Say you build a group of files where an executable chunk requires several other files. When you use a variable that is established/initialized in the "required" file, drop in a comment to tell the reader where the hell you got it from. It is extremely frustrating to see variables magically appear in a file, and then have to back-track a variable through 20 other files to figure out what you're doing with the value.
The one that automatically whines in response to other peoples posts. Let's call it "bitchbot". ;)