I want to second many of the above. I worked doing Industrial Control Systems for years, and I cannot emphasize enough the need for workrooms, conduit and isolating equipment.
Isolating Equipment Since your space is fairly small, try to wire everything hub and spoke and hub and spoke. For office equipment, run it all hub and spoke (run each outlet back to the central switching room). For industrial equipment, especially if they have low data volume (i.e. CNC, CMM), I strongly recommend putting them in local clusters (hence hub / spoke / hub/ spoke) with a dedicated fiber to a local switch for each cluster, and shielded cable from the local switch. All of the heavy, high-wattage equipment is necessarily very EM noisy. Giving them an extra switch isolated with fiber and short shielded cable runs, reduces the noise that you broadcast into the rest of your network. Also, (and perhaps obviously) all your networking equipment should be on an isolated power circuit from your industrial equipment. The voltage drop at startup is enough to brown out switches, and the reactive power is enough to fry them. I also recommend having backups on the shelf for all of the field devices, so that when a big breaker throws, or somebody accidently arc welds your equipment cabinet you can get them up and going in short order.
Conduit Conduit is key for maintenance and organization. So, go with 3x more conduit than necessary today; you will always need to pull new media. In the machine shop, use metal conduit to reduce noise from your machining environment. Put extra junction boxes in the conduit than needed. It makes pulling cable more difficult, but it make reconfiguration much simpler. Always leave behind a pull line for each length of conduit. Along the same lines, is raised (access) flooring in your server rooms. This is a lifesaver for running cable (and looks a lot tidier than the rats nest in the rack), and makes re-configuring the room a piece of cake. Also, with perforated tiles you can configure the HVAC for laminar air-flow (in from the top of the room and out the under the floor) which encourages the swarf in the air and on your clothes to stay out of your equipment and under the floor and in the filters like it belongs. Also, raised floors could save you from a pipe break or small flood. On a final conduit and cabling note, invest in a thermal labeling system, heat shrink cable labels and a barcode label and conduit database. Be sure to label the conduit end points, and the pull line ends. The heat shrink labels attach tight enough, that that can be pulled through conduit on the cable without snagging or coming off. So, you can label one end before you pull it, and label the other end after you cut it (so you only need one label printer and person labeling). The barcode lets you scan directly to your termination database which reduces transcription errors. You can purchase pre-printed barcode label pairs, but don't. Inevitably, one end of the cable won't install correctly, or you'll have to cut the cable, and the pre-printed cables require you to relabel both ends.
Workspace IT needs separate server rooms from power and telecom. The security requirements, access controls, typical tasks, and skillsets are different for the three disciplines. If you are in a warehouse type environment, the server room should have its own roofing and weather proof enclosure. This will save your equipment from a leaky warehouse roof, and fire sprinklers from the shop floor. Workrooms on the shop floor, provide a clean (isolation from swarf), quiet area for tackling shop floor related issues. Preferably, it would have windows onto or over the floor.
They way I understand it, it's the relationship between the intensity of gravity and the size of the sphere described by the orbit or the planet's surface.
I don't think the relationship is linear as described below, but I don't have the math handy to explain.
Essentially, given the intensity of the Moon's gravity well, and the surface area at the bottom of the well. A meteor strike per sqare meter on the moon is more likely than a meteor strike per square meter at LEO.
Even before you take into account the collateral danger aspects, I believe the Moon is a riskier surface.
I think it would be more fun though test it. We should roll out a square kilometer sheet of aluminum foil at LEO and another on the Moon. Leave them for a year. Then measure the difference in surface area between the two.
GLEO 9.10E+000 m/s^2
GMoon 1.62E+000 m/s^2 17.83%
ALEO 5.51E+014 m^2
AMoon 3.79E+013 m^2 6.88%
Don't get to excited about accurate calendaring. Our calendar has only been in use for a few hundred years.
Very few (except special purpose) databases do ancient dates correctly.
AD alone is highly revised. BC is all over the map,
This bug report for DEC VMS is amazing in its analysis:
D I G I T A L
SPR ANSWER FORM
SPR NO. 11-60903
SYSTEM VERSION PRODUCT VERSION COMPONENT SOFTWARE: VAX/VMS V3.2 VAX/VMS V3.2 Run-Time Library
PROBLEM:
The LIB$DAY Run-Time Library service "incorrectly" assumes the year 2000 is a leap year.
RESPONSE:
Thank you for your forward-looking SPR.
Various system services, such as SYS$ASCTIM assume that the year 2000 will be a leap year. Although one can never be sure of what will happen at some future time, there is strong historical precedent for presuming that the present Gregorian calendar will still be in affect by the year 2000. Since we also hope that VMS will still be around by then, we have chosen to adhere to these precedents.
The purpose of a calendar is to reckon time in advance, to show how many days have to elapse until a certain event takes place in the future, such as the harvest or the release of VMS V4. The earliest calendars, naturally, were crude and tended to be based upon the seasons or the lunar cycle.
The calendar of the Assyrians, for example, was based upon the phases of the moon. They knew that a lunation (the time from one full moon to the next) was 29 1/2 days long, so their lunar year had a duration of 364 days. This fell short of the solar year by about 11 days. (The exact time for the solar year is approximately 365 days, 5 hours, 48 minutes, and 46 seconds.) After 3 years, such a lunar calendar would be off by a whole month, so the Assyrians added an extra month from time to time to keep their calendar in synchronization with the seasons.
The best approximation that was possible in antiquity was a 19-year period, with 7 of these 19 years having 13 months (leap months). This scheme was adopted as the basis for the religious calendar used by the Jews. (The Arabs also used this calendar until Mohammed forbade shifting from 12 months to 13 months.)
When Rome emerged as a world power, the difficulties of making a calendar were well known, but the Romans complicated their lives because of their superstition that even numbers were unlucky. Hence their months were 29 or 31 days long, with the exception of February, which had 28 days. Every second year, the Roman calendar included an extra month called Mercedonius of 22 or 23 days to keep up with the solar year.
Even this algorithm was very poor, so that in 45 BC, Caesar, advised by the astronomer Sosigenes, ordered a sweeping reform. By imperial decree, one year was made 445 days long to bring the calendar back in step with the seasons. The new calendar, similar to the one we now use was called the Julian calendar (named after Julius Caesar). It's months were 30 or 31 days in length and every fourth year was made a leap year (having 366 days). Caesar also decreed that the year would start with the first of January, not the vernal equinox in late March.
Caesar's year was 11 1/2 minutes short of the calculations recommended by Sosigenes and eventually the date of the vernal equinox began to drift. Roger Bacon became alarmed and sent a note to Pope Clement IV, who apparently was not impressed. Pope Sixtus IV later became convinced that another reform was neede
For those that feel a little like cursing, I did a quick search for heck, and replaced them with HELL
I particularly enjoy this for cHELL.
Well, I sure hope you never work on anything serious.
The database's function is to provide a RELIABLE storage for your data. Part of the whole reliability thing is making sure crap can't get in, because once it's there everything goes to HELL.
For instance, let's take a shopping cart. Can an order be for a negative quantity? If your app doesn't work that way (it could, using a negative amount for returns for example), and you still allow it in the DB, then all your reporting goes to HELL, as SELECT SUM... now returns the wrong thing.
A proper database is set up in such a way that every piece of data in it makese sense. This means for instance not having things like orders hanging around without in the void without being linked to some client. This is something easily ensured by foreign keys. Otherwise you have an utter mess - the total of the orders in the database doesn't match the sum of the orders of all clients!
If you put your cHELLs in the database, you have a guarantee that when somebody else codes another frontend to it (say, you had a website and now are making a special version for PDAs), if the application does the wrong thing, the database simply won't let it happen. This may cost a bit of speed, but I assure you that peace, your sanity and your ASS (if you have a boss and he's got any sense, he's not going to like it at ALL if it turns out that reports don't match reality, and that reality can't be even easily extracted) is far, far more valuable.
I guarantee you the oldtimers that stick it out here, are not getting laid.
Now, some breeder out there will probably chime in with a "I got laid, and the kids to prove it" type remark.
But, most readers will just nod their heads sadly, and lash out at the next poster that says Dan Brown writes good fiction, or the guy that says he just didn't get Serenity.
And, by tending pigs, he means the women would be sold into the sex trade, ultimately to have sex with fat Americans, all for the privilege of being starved and beaten by their new owners.
Commercially, I am almost exclusively a Windows Client / Server developer. Running VMWare under Fedora Core, on my ThinkPad laptop has probably doubled or tripled my productivity.
For each of my active projects, I clone a new virtual machine (or machines in the case of servcer projects). I never have to worry about one customer's configuration or third party tools corrupting the environment of another. I keep all my business critical applications running on linux (e-mail, web, IM, Word Processing, Spreadsheet).
And, when my development environment crashes Windows, I just restart the VMWare session. When, updates are suddenly required that need a reboot, I reboot the session. If some really long process has to run (like Windows Update or a software install), I start a new session with a different project and use my spare time effectively.
But, by far the most amazing use of that environment is the ability to start a windows server in one session, and clients in a few other sessions. And, test all the interactions without having sever computers set up. In fact, I was able to do some stress testing of my server, with 4 mixed operating system clients, while on the airplane!
Slashdot Mirror
Somalia is designing software to pirate a drone cargo ship.
I want to second many of the above. I worked doing Industrial Control Systems for years, and I cannot emphasize enough the need for workrooms, conduit and isolating equipment.
Isolating Equipment
Since your space is fairly small, try to wire everything hub and spoke and hub and spoke.
For office equipment, run it all hub and spoke (run each outlet back to the central switching room).
For industrial equipment, especially if they have low data volume (i.e. CNC, CMM), I strongly recommend putting them in local clusters (hence hub / spoke / hub/ spoke) with a dedicated fiber to a local switch for each cluster, and shielded cable from the local switch. All of the heavy, high-wattage equipment is necessarily very EM noisy. Giving them an extra switch isolated with fiber and short shielded cable runs, reduces the noise that you broadcast into the rest of your network.
Also, (and perhaps obviously) all your networking equipment should be on an isolated power circuit from your industrial equipment. The voltage drop at startup is enough to brown out switches, and the reactive power is enough to fry them. I also recommend having backups on the shelf for all of the field devices, so that when a big breaker throws, or somebody accidently arc welds your equipment cabinet you can get them up and going in short order.
Conduit
Conduit is key for maintenance and organization. So, go with 3x more conduit than necessary today; you will always need to pull new media. In the machine shop, use metal conduit to reduce noise from your machining environment. Put extra junction boxes in the conduit than needed. It makes pulling cable more difficult, but it make reconfiguration much simpler. Always leave behind a pull line for each length of conduit.
Along the same lines, is raised (access) flooring in your server rooms. This is a lifesaver for running cable (and looks a lot tidier than the rats nest in the rack), and makes re-configuring the room a piece of cake. Also, with perforated tiles you can configure the HVAC for laminar air-flow (in from the top of the room and out the under the floor) which encourages the swarf in the air and on your clothes to stay out of your equipment and under the floor and in the filters like it belongs. Also, raised floors could save you from a pipe break or small flood.
On a final conduit and cabling note, invest in a thermal labeling system, heat shrink cable labels and a barcode label and conduit database. Be sure to label the conduit end points, and the pull line ends. The heat shrink labels attach tight enough, that that can be pulled through conduit on the cable without snagging or coming off. So, you can label one end before you pull it, and label the other end after you cut it (so you only need one label printer and person labeling). The barcode lets you scan directly to your termination database which reduces transcription errors. You can purchase pre-printed barcode label pairs, but don't. Inevitably, one end of the cable won't install correctly, or you'll have to cut the cable, and the pre-printed cables require you to relabel both ends.
Workspace
IT needs separate server rooms from power and telecom. The security requirements, access controls, typical tasks, and skillsets are different for the three disciplines. If you are in a warehouse type environment, the server room should have its own roofing and weather proof enclosure. This will save your equipment from a leaky warehouse roof, and fire sprinklers from the shop floor.
Workrooms on the shop floor, provide a clean (isolation from swarf), quiet area for tackling shop floor related issues. Preferably, it would have windows onto or over the floor.
Does the acronym IANAL bug anybody else?
Because, while not a lawyer, I definitely not ANAL.
Actually, that would be great!
He is a finite resource here on Earth. This would make the He industry sustainable.
Somebody call Al Gore.
Oh no. Erica Baidu's gonna be pissed at being called a pirate.
Just ask slashdot.
They way I understand it, it's the relationship between the intensity of gravity and the size of the sphere described by the orbit or the planet's surface. I don't think the relationship is linear as described below, but I don't have the math handy to explain. Essentially, given the intensity of the Moon's gravity well, and the surface area at the bottom of the well. A meteor strike per sqare meter on the moon is more likely than a meteor strike per square meter at LEO. Even before you take into account the collateral danger aspects, I believe the Moon is a riskier surface. I think it would be more fun though test it. We should roll out a square kilometer sheet of aluminum foil at LEO and another on the Moon. Leave them for a year. Then measure the difference in surface area between the two. GLEO 9.10E+000 m/s^2 GMoon 1.62E+000 m/s^2 17.83% ALEO 5.51E+014 m^2 AMoon 3.79E+013 m^2 6.88%
You can't compare a database to a browser, silly.
Remember this is 2005!
If you can't do it with 'SELECT *', or 'UPDATE *' or 'DELETE *' I don't want it.
It's all or nothing for me, baby!
I only wish I could 'INSERT *' that would make the data entry work so much easier.
Very few (except special purpose) databases do ancient dates correctly.
AD alone is highly revised. BC is all over the map,
This bug report for DEC VMS is amazing in its analysis:
D I G I T A L
SPR ANSWER FORM
SPR NO. 11-60903
SYSTEM VERSION PRODUCT VERSION COMPONENT
SOFTWARE: VAX/VMS V3.2 VAX/VMS V3.2 Run-Time Library
PROBLEM:
The LIB$DAY Run-Time Library service "incorrectly" assumes the year
2000 is a leap year.
RESPONSE:
Thank you for your forward-looking SPR.
Various system services, such as SYS$ASCTIM assume that the year 2000
will be a leap year. Although one can never be sure of what will
happen at some future time, there is strong historical precedent for
presuming that the present Gregorian calendar will still be in affect
by the year 2000. Since we also hope that VMS will still be around by
then, we have chosen to adhere to these precedents.
The purpose of a calendar is to reckon time in advance, to show how
many days have to elapse until a certain event takes place in the
future, such as the harvest or the release of VMS V4. The earliest
calendars, naturally, were crude and tended to be based upon the
seasons or the lunar cycle.
The calendar of the Assyrians, for example, was based upon the phases
of the moon. They knew that a lunation (the time from one full moon
to the next) was 29 1/2 days long, so their lunar year had a duration
of 364 days. This fell short of the solar year by about 11 days.
(The exact time for the solar year is approximately 365 days, 5 hours,
48 minutes, and 46 seconds.) After 3 years, such a lunar calendar
would be off by a whole month, so the Assyrians added an extra month
from time to time to keep their calendar in synchronization with the
seasons.
The best approximation that was possible in antiquity was a 19-year
period, with 7 of these 19 years having 13 months (leap months). This
scheme was adopted as the basis for the religious calendar used by the
Jews. (The Arabs also used this calendar until Mohammed forbade
shifting from 12 months to 13 months.)
When Rome emerged as a world power, the difficulties of making a
calendar were well known, but the Romans complicated their lives
because of their superstition that even numbers were unlucky. Hence
their months were 29 or 31 days long, with the exception of February,
which had 28 days. Every second year, the Roman calendar included an
extra month called Mercedonius of 22 or 23 days to keep up with the
solar year.
Even this algorithm was very poor, so that in 45 BC, Caesar, advised
by the astronomer Sosigenes, ordered a sweeping reform. By imperial
decree, one year was made 445 days long to bring the calendar back in
step with the seasons. The new calendar, similar to the one we now
use was called the Julian calendar (named after Julius Caesar). It's
months were 30 or 31 days in length and every fourth year was made a
leap year (having 366 days). Caesar also decreed that the year would
start with the first of January, not the vernal equinox in late March.
Caesar's year was 11 1/2 minutes short of the calculations recommended
by Sosigenes and eventually the date of the vernal equinox began to
drift. Roger Bacon became alarmed and sent a note to Pope Clement IV,
who apparently was not impressed. Pope Sixtus IV later became
convinced that another reform was neede
It is a little sad: digg, fark, slashdot, boing. All circle and jerk, no climax.
I particularly enjoy this for cHELL. Well, I sure hope you never work on anything serious.
The database's function is to provide a RELIABLE storage for your data. Part of the whole reliability thing is making sure crap can't get in, because once it's there everything goes to HELL.
For instance, let's take a shopping cart. Can an order be for a negative quantity? If your app doesn't work that way (it could, using a negative amount for returns for example), and you still allow it in the DB, then all your reporting goes to HELL, as SELECT SUM... now returns the wrong thing.
A proper database is set up in such a way that every piece of data in it makese sense. This means for instance not having things like orders hanging around without in the void without being linked to some client. This is something easily ensured by foreign keys. Otherwise you have an utter mess - the total of the orders in the database doesn't match the sum of the orders of all clients!
If you put your cHELLs in the database, you have a guarantee that when somebody else codes another frontend to it (say, you had a website and now are making a special version for PDAs), if the application does the wrong thing, the database simply won't let it happen. This may cost a bit of speed, but I assure you that peace, your sanity and your ASS (if you have a boss and he's got any sense, he's not going to like it at ALL if it turns out that reports don't match reality, and that reality can't be even easily extracted) is far, far more valuable.
Actually, on the moon the micrometeor problem gets worse not better.
We don't have a good plan for handling a micrometeor strike in orbit, because the odds are 'astronomically' low.
But, on the moon we put ourselves at the bottom of a gravity well with no atmosphere to protect us.
I bet the risk of meteor strike from just the exposed 180 degrees goes up by several order of magnitudes.
> All this is perfectly fine. Just don't make the mistake the quoted poster made . . .
I didn't see the poster. I know the poster on my wall made a big mistake by putting too much fabric over the boobies.
And, now having read the Da Vinci code, you still know nothing about the christian church.
That book was the most poorly contriived piece of drivel since the King James Bible.
Only the people new here are not virgins.
I guarantee you the oldtimers that stick it out here, are not getting laid.
Now, some breeder out there will probably chime in with a "I got laid, and the kids to prove it" type remark.
But, most readers will just nod their heads sadly, and lash out at the next poster that says Dan Brown writes good fiction, or the guy that says he just didn't get Serenity.
It should be tattoed onto our corneas.
Yeah, those pieces of crap don't even hold up in a strong wind.
Colorado and Texas have so-called "road-hog" laws allowing police to ticket for failing to yield to faster traffic.
It's just not enforced very often.
Oh that's complete BS too.
Most of the bureaucrats and politicians running the US labor movement are commie liberal Volvo drivers too.
They are as distant from the US laborer, as the US laborer is from a slave laborer.
US politics are all about who controls what. It hasn't been about the common man for a long time.
Communism is where a group of people steals the wealth of another group of people. Capitalism is the other way around.
And, by tending pigs, he means the women would be sold into the sex trade, ultimately to have sex with fat Americans, all for the privilege of being starved and beaten by their new owners.
Actually, sweatshop labor didn't slow down in the US until the press and other writers publicized it. Think Upton Sinclair, et al.
The resulting outrage closed factories, and enacted laws.
With the laws in place it became much harder to pull off.
But, it still happens, especially in the textile industry with fresh immigrants.
If the market will bear it, and the press ignores it, it will happen. Laws or no laws.
Ironic that the commie unions can't organize in commie countries.
Put that in your communal pipe and smoke it.
For each of my active projects, I clone a new virtual machine (or machines in the case of servcer projects). I never have to worry about one customer's configuration or third party tools corrupting the environment of another. I keep all my business critical applications running on linux (e-mail, web, IM, Word Processing, Spreadsheet).
And, when my development environment crashes Windows, I just restart the VMWare session. When, updates are suddenly required that need a reboot, I reboot the session. If some really long process has to run (like Windows Update or a software install), I start a new session with a different project and use my spare time effectively.
But, by far the most amazing use of that environment is the ability to start a windows server in one session, and clients in a few other sessions. And, test all the interactions without having sever computers set up. In fact, I was able to do some stress testing of my server, with 4 mixed operating system clients, while on the airplane!
D.