you dont need to evacuate the air and maintain that. If you put a large fan that can remove air at the rate of the tunnels circumference vs distance the tran would travel in a minute then you would get the same effect. You would also want to push air behind the train at the same rate. something like a delivery tube at a bank. This would be much cheaper than evacuating the air and because the air would be moving at the same rate as the train, the train would not need to be aerodynamic.
I dont think its about 'quality' so much as target. Desktop drives and server drives are different things and wear leveling between the two could be significantly different. Right now, I think that everything has been targeting desktops and notebooks and those products are adapted to the server space rather than being developed from the ground up for servers.
Also, what indication do you have that 20-30 people are experts in wear leveling? I would expect that many engineers as EACH flash memory vendor and likely a few hundred at Intel.
how about opensolaris with ZFS. you get a high performance iSCSI target and a filesystem with re-ordered writes that improves IO performance by reducing seeks plus optional deduplication and compression.
Additional gains can be had from seperate log and cache disks and with 8+ core platforms already available you can blow a traditional RAID card out of the water.
One nice thing about software raid is it is completely agnostic to controller failure. If you need to recover a raid after a controller failure, you can even do it with SATA->USB adapters if you used SATA or you can use ANY other SAS/SATA controller that supports your disks.
But that isnt indicative of enterprise loads. Enterprise loads such as databases do many many seeks and tend to have long queues as many clients request the data. Size and throughput are less important for these loads than seek time (though still critical).
A desktop system can only(realistically) have a similar load in synthetic benchmarks.
The server vs desktop loads on disks are so different that they cant be directly compared. A great desktop drive can be a terrible server drive and vice versa.
I dont think I missed the point. I am just a little more patient than most I guess. I don't think SSDs are ready from a cost/performance standpoint vs enterprise SAS 15k drives due to the market's focus.
The OP may not have listed the hardware and disks but each controller has info published on max throughput.
This is very comparable to running U320 SCSI disks on a U160 card. The performance bottleneck is often NOT the U160 interface but rather that the controller was not over engineered for its time. The difference is that the interface bandwidth today is fast enough for the throughput of SSD drives but the controllers arent fast enough to take advantage of the very low access tims especially when many drives are used.
I suspect that the next generation of RAID controllers will be capable of handling a larger array of SSD drives. Until then, you can run MORE raid controllers and smaller arrays but that will increase costs significantly.
SSD drives are a disruptive technology so the infrastructure needs a disruptive adaptation in controller design and/or CPU speed.
You missed half the point. SSD use wear leveling and other techniques that are very effective on the desktop but in a high IO environment, the current wear leveling techniques reduce SSD performance to well below what you get on the desktop.
I really think that this is just a result of the current trend to put high performance SSD on the desktop. When the market re-focuses these problems will disolve.
This also goes for RAID controllers. If you have 8 ports and SAS 3Gb links, then you need to process 24Gb and a IO/s of current 15k SAS drives. Lets just assume for easy math that this requires a 500Mhz RAID Processor. What would be the point of putting in a 2Ghz Processor? What if you increase the IO/s by 100x and double the bandwidth? now you need to handle 48Gb/s throughput and 100x the IO and that requires 2x 3Ghz Processors.
Its just takes time for the market players to react to each technology increase. New raid controllers will come out that can handle these things. maybe the current raid cpus have been using a commodity chip (powerpc often enough) because it was fast enough to handle these things and the new technologies are going to require more specific processors. Maybe you need to get cell chips or nvidia GPUs in there, whatever it takes.
I admit it would be pretty interesting to see the new Dell/LSI 100Gb SAS powered by Nvidia logo in Gen12 Dell servers.
I might add that you are going to be stuck with 4 channels ( 1,4,7,10 ) which means that 500 people will be hard to support without highly directional antennas. Maybe try to split the space into 4 with directionals.
consider running a small pfsense box with a number of wifi adapters. You could pick up some cheap directional antennas to help limit connections to any one radio somewhat. Alternatively you could just run 4 sids and do a script to hide a sid when the user count got so high so the next users would only see the less loaded ones.
I honestly cant wait for them to attempt to enforce this. Is the ACLU aware of this?
Seriously, we have the right to assemble, the right to express our political views, and the right to privacy. We cannot be required to register to exercise a right! Our conversations behind closed doors is expressly allowed by the constitution with very small exception for speech that conspires to break a law.
Having 6+ cores is a complex issue for the desktop. In the 'olden' days it way easy to do the math that per Mhz, the less cores the faster ( a pair of 1Ghz chips is slower than a 2Ghz CPU if all all other things are equal)
But now, each CPU can have a dedicated memory bus. That means that 2 cores can be FASTER than a single core because 2 cores can have twice the memory bandwidth. Its not necessarily about clock cycles but bandwidth.
More cores also can improve the desktop experience. because flash is currently stuck on a single CPU, your system cant get totally rocked by flash. If you have a really intense process, you could set the CPU affinity to 5 of the 6 cores to make sure you had one left over. The process scheduler should try to do this on its own but its not always successfull.
I run some VM hosts on dual quad cores and processor affinity for virtual machines is very important. On one box I have CPUs that are 2 dual cores on a single CPU and then 2 sockets. A VM on CPU1&2 (numerically 1-8, not 0-7) is ideal. A VM on 2&3 is slow and a VM on 4&5 is rediculously slow because you go from a signle chip, to two chips, then to a core on seperate sockets. This is an extreme case but it is true on the desktop as much as it is anywhere else.
Any high transaction count server that runs multiple processes or threads will make very good use of 6 cores as these process tend to not jump between cores ( or shouldnt if the programmers are concerned about performance)
If you considered this an open-air fiber optic cable (minus the fiber and the cable) then there may be a cost benefit over cables. Each cable requires infrastruction from jacks, in-wall cables, switch ports, etc while a whole room optical wireless could use a single switch port. Also consider that the price of these components could be very low. Diodes are typically not very expensive and a diode->serial USB could be made very cheaply though would not be gigabit speeds.
I think that for basic connectivity wireless is 'good enough' but this optical setup would certainly be more secure considering. Also consider that optical transmissions dont follow the same rules as microwave transmissions you could use as much of the band as you like to increase speeds even more.
I am assuming that you will be doing a tree style network with a central location providing you bandwidth on a fiber link or T1/T3 etc.
Get a PAIR(at least, add more as necessary) of nice, quad core Dell Poweredge or HP DL series servers. FreeBSD+CARP them giving you as seamless load balancing/fail over as you can realistically get. at each hub consider either buying commercial wireless routers or build your own. If you build just keep everything fanless as that is where your equipment will fail you. Use OSPF on branches while being aware of scaling issues and where OSPF isnt ideal, kick in the BGP and you can link your OSPF clusters together giving an extra level on branch redundancy because traffic can hop to another branch if necessary.
OLSR in mesh cells, OSPF on the cells backhaul router linking these cells and providing multiple route options for redundancy, and BGP between groups of cells and between you and other ISPs etc etc.
You dont need to take the Mesh down to the client, only to the neighborhood AP level. The idea of mesh per client creates too many hopps and clients have too much latency. Ideally, you are no more that a 2-4 hops from the backbone, any more and you are going to be adding too much latency from the hops. When a backhaul link goes down and the OSPF saves your butt by routing traffic through a neighboring cell, you are already going to add latency and you dont need that complicated by 6 hops in the neighborhood and 5 more to the backbone (11 hops over wireless is just too many for broadband).
this may sound strange, but 'some' viewers will actually find 1080i video of sports better on low end 1080p plasma TVs. 1080i in this circumstance actually reduces the perception of motion blur because it provides twice as many images for the brain to process. The image will break down under close scrutiny but from the couch at 10' away the NFL looks better at 1080i on a crappy plasma TV.
I archive videos digitally and am a big fan of 720p. looks great on 42" sets and takes up much less space in h.264. For my 52" samsung I do like some 1080p action though.
1080i is very noticeably different for the majority of the population. The 'WIN' that 1080i got was that is looks much better than standard broadcast. 1080i is only half the resolution and uses a perception trick to emulate 1080p. Most people, after watching a 1080p set for a couple of days, would see a drastic loss in fidelity moving to a 1080i set.
720p on the other hand looks outstanding. Though the perceived resolution is lower than 1080p(or "i"), the framerates are still excellent and in some cases the decrease in resolution allows a small bump in bitrate and a cleaner image.
You might make the argument that people will notice the resolution difference but I suggest you test that theory at 10' not at 10". Smooth framerate and less blocking are more important than raw resolution.
'No it's not! said Constable Visit. 'Atheism is a denial of a god.'
'Therefore It Is A Religious Position,' said Dorfl. 'Indeed, A True Atheist Thinks Of The Gods Constantly, Albeit In Terms of Denial. Therefore, Atheism Is A Form Of Belief. If The Atheist Truly Did Not Believe, He Or She Would Not Bother To Deny.'
Amen brother!.....can I say amen? I mean its just hebrew name for 'It truly is' or 'so it truly be'. Sure its used in Christianity and Judaism a lot but Atheists can use it to right?
Lack of a belief is a 'disbelief' by definition. If I say, "I do not believe in hell" and a priest states that I will go to hell, then his statements are directly against my belief that there is no hell, and instructing me that I will go there is blasphemous because it is against my religious beliefs.
what a stupid law. seriously. thats thinking with the rock thrower/spear chucker/leaves for undies/bugs in your hair part of your brain. welcome back to year 1!
I see a lot of sh script written with people using 'for' + 'ls' + 'grep' to find files, filter the output, and perform some action in a loop. This creates extra lines of code when some 'clever' one liner could do this better.
in bash for example , declare everything you can so that your program doesnt have to wait on a $PATH return and search for your program. Learn each functions options so you dont stack things together for no good reason.
I believe that some comments are good but overcommenting is messy. I prefer to do my commenting in blocks as small descriptions of what the code is indended to do.
I like to organize my subroutines and objects etc by their type. This way I can search my code for 'OBJECTS' and fine the section that describes objects or 'SUBROUTINES' and I will have made sub sections via comments 'SUBROUTINES_SEARCH' etc etc. I like few, simple, concise comments. I do a lot of work in bash for administering servers but bash scripts should be clean and properly commented just like C or PHP etc.
#!/bin/BASH #Code specific to bash or bash compatible shells. author *ME*
# INCLUDES include/etc/script.conf include/usr/share/script/functions/*
#this is item1. i like to put long comments that are as big as the code. #i dont consider the fact that anyone reading these scripts in the future only #needs to know why I did this and what it is supposed to do, not how it does it. if you dont know how it does it then you are in the wrong job [item1] function1;function2;function3;end;
#this is item2. it is almost like item1 above. #I know I shouldn't reference physical locations in a file because they might move for organization but #I thought id put a note in here that item2 references item3 with is at line 652 and item3 references item1 which is right above this on line 601. [item2] function1;function2;function3;end;
I think an important definition to point out is that 'comment' is not the same as 'document'. Put comments in to assist you in the future, to find code, to give a quick hint at the functions intended use so you can use that code better. Dont describe how to do a if/fi statement or how to use a function.
At first they did. They didnt understand what they should have to send an email to helpdesk and not make all those phone calls, or send email to individual emails. It took about 1 month then they say that their issues are handled promptly because the process was more efficient.
The truth is that there is no benchmark for this. I am a consultant and tend to take a sysadmin role for clients.
If you use Active Directory and store user files on the network then you can do stock images for each model of machine and a broken unit is a 20minute re-image (or swap fresh machine in from the pool) and your up and going, documents and all. This is where a directory services' up-front costs become justified.
With Active Directory I can manage machines and users very efficiently, keep user's files safe with shadow copies, backups, etc, and deploy software and printers to users easily. For linux to Active directory look at likeise-open or centrify for single sign on with the latery able to do group policy on linux machines.
I have 4 techs and myself. between the 5 of us we handle about 2500 or so users across our clients. Our clients that have been with us for a year or two are all have some sort of AD setup and have a much lower computer expense than before. oddly enough, newer clients account for larger expenses because they havent standardized their computers ad require more trips to their site and more billable hours.
I would imagine that if I had only established users, with computers on AD then my crew could handle 3000-3500 users without much overtime. If we did no managed computers then I think that 250 users per tech would be pushing it.
If you just compare those numbers, 600 vs 250 you can pretty easily see the cost savings for a managed network, either through AD, network, or other LDAP. a 1200 user network could be reasonably run by 2 IT guys vs really needing 4 or 5 to do the same job otherwise. let be conservative and say 4 guys at $40,000 each vs 2 guys at $50,000 (higher skills for 2 techs vs 4) and you see a $60,000 gap, which is much more than the CALS and servers needed for 1200 users. 1200 users is still in the 2 ADDS servers arena. lets say $3500 per licensed server and $35 per CAL and you save money on year 1, next 4 years are free!.
Right now it is kind of handy because my guys work their ~40 hours doing stuff on managed networks and pull 'overtime' going to customers sites or doing old computer triage and repair and get paid part of the service fee.
If you are at 600+ users per tech, then you really should be on some sort of directory service like AD. If you are not, I suspect you are spending a lot of your labor dollars spinning tires and not helping clients/users very well. That equals more compaints, less praise, and likely a lack of raise or bonus.
spending that cash on a yearly subscription to playboy certainly would have netted the world a new open source porn system providing free as in beer porn to the world!
I think you are missing the point on thin clients. A PC for a basic client has a pretty limited lifespan and tends to require in-the-field support. It also requires antivirus software, some level of routine maintenance, and has a substantial failure rate in either software or hardware. A thin client lasts a very long time and needs basically zero in-the-field support, no antivirus(server side A/V instead), etc etc.
When you licenses office or terminal services use, you tend to get better pricing than standalone versions and with software assurance you can stay with the most up-to-date versions for a reasonable price.
The Thin client costs as much as a PC up front but will last 2-3 times as long, which in a big picture thought process means they cost 1/2-1/3. Less IT guys in the field saves money in wages.
Thin clients typically burn 20-30W where a PC will typically burn 180-220W. A single PC can cost $160-200 per year in electricity and a thin client just $13-15. if you have 200 stations thats a difference of $32,000 vs $2600. If you design to have servers run desktops and separate server run apps then you can likely get 200 users into maybe 4 servers (An RDP server and 3 Application servers) and have a nice thin-client system with web and office.
Other benefits are that every user runs the same version of software. Every user has access to the same storage for documents. much more confidence in security settings being applied as there is no local PC to hack on. Have a user with special software needs? You can assign a user to a Hyper-V instance running the OS and software they need. Need to help a user to do something? RDP allows you to share there desktop easily without another package and at reasonable performance.
seriously, buy a new router to replace a 'broken' one from a location and then somehow fix the broken one for your lab/office.
The truth is that sometimes you not only lack the equipment for lab testing, but also the real world usage scenario. I am often stuck in a situation where I must backup a config and then experiment with production equipment and so am forced to do this outside of business hours. I usually get a chance to do some functional testing offline but cant really put new systems through there paces very well in a lab.
The real key to success here? know what you are doing. You may have to work in less that ideal circumstances but you must be knowledgeable enough to fix a mistake in a reasonable amount of time.
Also consider getting your hands on a rig to do some virtualization. You can virtualize routers and server with something like Xenserver, vmware, or virtualbox. I have done an entire mock deployment of a cisco firewall + windows server 2008 r2 system for remote client access(Windows) and site-to-site vpns(cisco) on a single Xenserver because I can virtualize the cisco router (its slow), windows servers, and even create seperate networks to simulate seperate switches, sites, network segments etc. Q6600+8GB can be had for less than a grand at dell in whitebox.
Slashdot Mirror
you dont need to evacuate the air and maintain that. If you put a large fan that can remove air at the rate of the tunnels circumference vs distance the tran would travel in a minute then you would get the same effect. You would also want to push air behind the train at the same rate. something like a delivery tube at a bank. This would be much cheaper than evacuating the air and because the air would be moving at the same rate as the train, the train would not need to be aerodynamic.
I dont think its about 'quality' so much as target. Desktop drives and server drives are different things and wear leveling between the two could be significantly different. Right now, I think that everything has been targeting desktops and notebooks and those products are adapted to the server space rather than being developed from the ground up for servers.
Also, what indication do you have that 20-30 people are experts in wear leveling? I would expect that many engineers as EACH flash memory vendor and likely a few hundred at Intel.
how about opensolaris with ZFS. you get a high performance iSCSI target and a filesystem with re-ordered writes that improves IO performance by reducing seeks plus optional deduplication and compression.
Additional gains can be had from seperate log and cache disks and with 8+ core platforms already available you can blow a traditional RAID card out of the water.
One nice thing about software raid is it is completely agnostic to controller failure. If you need to recover a raid after a controller failure, you can even do it with SATA->USB adapters if you used SATA or you can use ANY other SAS/SATA controller that supports your disks.
But that isnt indicative of enterprise loads. Enterprise loads such as databases do many many seeks and tend to have long queues as many clients request the data. Size and throughput are less important for these loads than seek time (though still critical).
A desktop system can only(realistically) have a similar load in synthetic benchmarks.
The server vs desktop loads on disks are so different that they cant be directly compared. A great desktop drive can be a terrible server drive and vice versa.
I dont think I missed the point. I am just a little more patient than most I guess. I don't think SSDs are ready from a cost/performance standpoint vs enterprise SAS 15k drives due to the market's focus.
The OP may not have listed the hardware and disks but each controller has info published on max throughput.
This is very comparable to running U320 SCSI disks on a U160 card. The performance bottleneck is often NOT the U160 interface but rather that the controller was not over engineered for its time. The difference is that the interface bandwidth today is fast enough for the throughput of SSD drives but the controllers arent fast enough to take advantage of the very low access tims especially when many drives are used.
I suspect that the next generation of RAID controllers will be capable of handling a larger array of SSD drives. Until then, you can run MORE raid controllers and smaller arrays but that will increase costs significantly.
SSD drives are a disruptive technology so the infrastructure needs a disruptive adaptation in controller design and/or CPU speed.
You missed half the point. SSD use wear leveling and other techniques that are very effective on the desktop but in a high IO environment, the current wear leveling techniques reduce SSD performance to well below what you get on the desktop.
I really think that this is just a result of the current trend to put high performance SSD on the desktop. When the market re-focuses these problems will disolve.
This also goes for RAID controllers. If you have 8 ports and SAS 3Gb links, then you need to process 24Gb and a IO/s of current 15k SAS drives. Lets just assume for easy math that this requires a 500Mhz RAID Processor. What would be the point of putting in a 2Ghz Processor? What if you increase the IO/s by 100x and double the bandwidth? now you need to handle 48Gb/s throughput and 100x the IO and that requires 2x 3Ghz Processors.
Its just takes time for the market players to react to each technology increase. New raid controllers will come out that can handle these things. maybe the current raid cpus have been using a commodity chip (powerpc often enough) because it was fast enough to handle these things and the new technologies are going to require more specific processors. Maybe you need to get cell chips or nvidia GPUs in there, whatever it takes.
I admit it would be pretty interesting to see the new Dell/LSI 100Gb SAS powered by Nvidia logo in Gen12 Dell servers.
I might add that you are going to be stuck with 4 channels ( 1,4,7,10 ) which means that 500 people will be hard to support without highly directional antennas. Maybe try to split the space into 4 with directionals.
consider running a small pfsense box with a number of wifi adapters. You could pick up some cheap directional antennas to help limit connections to any one radio somewhat. Alternatively you could just run 4 sids and do a script to hide a sid when the user count got so high so the next users would only see the less loaded ones.
I honestly cant wait for them to attempt to enforce this. Is the ACLU aware of this?
Seriously, we have the right to assemble, the right to express our political views, and the right to privacy. We cannot be required to register to exercise a right! Our conversations behind closed doors is expressly allowed by the constitution with very small exception for speech that conspires to break a law.
Ebay has given paypal a monopoly payments for their auctions. this is anti competitive and should be stopped.
Having 6+ cores is a complex issue for the desktop. In the 'olden' days it way easy to do the math that per Mhz, the less cores the faster ( a pair of 1Ghz chips is slower than a 2Ghz CPU if all all other things are equal)
But now, each CPU can have a dedicated memory bus. That means that 2 cores can be FASTER than a single core because 2 cores can have twice the memory bandwidth. Its not necessarily about clock cycles but bandwidth.
More cores also can improve the desktop experience. because flash is currently stuck on a single CPU, your system cant get totally rocked by flash. If you have a really intense process, you could set the CPU affinity to 5 of the 6 cores to make sure you had one left over. The process scheduler should try to do this on its own but its not always successfull.
I run some VM hosts on dual quad cores and processor affinity for virtual machines is very important. On one box I have CPUs that are 2 dual cores on a single CPU and then 2 sockets. A VM on CPU1&2 (numerically 1-8, not 0-7) is ideal. A VM on 2&3 is slow and a VM on 4&5 is rediculously slow because you go from a signle chip, to two chips, then to a core on seperate sockets. This is an extreme case but it is true on the desktop as much as it is anywhere else.
Any high transaction count server that runs multiple processes or threads will make very good use of 6 cores as these process tend to not jump between cores ( or shouldnt if the programmers are concerned about performance)
or seizure generator!
If you considered this an open-air fiber optic cable (minus the fiber and the cable) then there may be a cost benefit over cables. Each cable requires infrastruction from jacks, in-wall cables, switch ports, etc while a whole room optical wireless could use a single switch port. Also consider that the price of these components could be very low. Diodes are typically not very expensive and a diode->serial USB could be made very cheaply though would not be gigabit speeds.
I think that for basic connectivity wireless is 'good enough' but this optical setup would certainly be more secure considering. Also consider that optical transmissions dont follow the same rules as microwave transmissions you could use as much of the band as you like to increase speeds even more.
Seriously, learn to love FreeBSD.
I am assuming that you will be doing a tree style network with a central location providing you bandwidth on a fiber link or T1/T3 etc.
Get a PAIR(at least, add more as necessary) of nice, quad core Dell Poweredge or HP DL series servers. FreeBSD+CARP them giving you as seamless load balancing/fail over as you can realistically get.
at each hub consider either buying commercial wireless routers or build your own. If you build just keep everything fanless as that is where your equipment will fail you.
Use OSPF on branches while being aware of scaling issues and where OSPF isnt ideal, kick in the BGP and you can link your OSPF clusters together giving an extra level on branch redundancy because traffic can hop to another branch if necessary.
OLSR in mesh cells, OSPF on the cells backhaul router linking these cells and providing multiple route options for redundancy, and BGP between groups of cells and between you and other ISPs etc etc.
You dont need to take the Mesh down to the client, only to the neighborhood AP level. The idea of mesh per client creates too many hopps and clients have too much latency. Ideally, you are no more that a 2-4 hops from the backbone, any more and you are going to be adding too much latency from the hops. When a backhaul link goes down and the OSPF saves your butt by routing traffic through a neighboring cell, you are already going to add latency and you dont need that complicated by 6 hops in the neighborhood and 5 more to the backbone (11 hops over wireless is just too many for broadband).
1080i 1080p
1080i = 1920x540
1080p = 1920x1080
typically 1080i has twice the framerate of 1080p.
this may sound strange, but 'some' viewers will actually find 1080i video of sports better on low end 1080p plasma TVs. 1080i in this circumstance actually reduces the perception of motion blur because it provides twice as many images for the brain to process. The image will break down under close scrutiny but from the couch at 10' away the NFL looks better at 1080i on a crappy plasma TV.
I archive videos digitally and am a big fan of 720p. looks great on 42" sets and takes up much less space in h.264. For my 52" samsung I do like some 1080p action though.
This is not true.
1080i is very noticeably different for the majority of the population. The 'WIN' that 1080i got was that is looks much better than standard broadcast. 1080i is only half the resolution and uses a perception trick to emulate 1080p. Most people, after watching a 1080p set for a couple of days, would see a drastic loss in fidelity moving to a 1080i set.
720p on the other hand looks outstanding. Though the perceived resolution is lower than 1080p(or "i"), the framerates are still excellent and in some cases the decrease in resolution allows a small bump in bitrate and a cleaner image.
You might make the argument that people will notice the resolution difference but I suggest you test that theory at 10' not at 10". Smooth framerate and less blocking are more important than raw resolution.
Amen brother! .....can I say amen? I mean its just hebrew name for 'It truly is' or 'so it truly be'. Sure its used in Christianity and Judaism a lot but Atheists can use it to right?
Lack of a belief is a 'disbelief' by definition. If I say, "I do not believe in hell" and a priest states that I will go to hell, then his statements are directly against my belief that there is no hell, and instructing me that I will go there is blasphemous because it is against my religious beliefs.
what a stupid law. seriously. thats thinking with the rock thrower/spear chucker/leaves for undies/bugs in your hair part of your brain. welcome back to year 1!
efficient code should be to goal.
I see a lot of sh script written with people using 'for' + 'ls' + 'grep' to find files, filter the output, and perform some action in a loop. This creates extra lines of code when some 'clever' one liner could do this better.
in bash for example , declare everything you can so that your program doesnt have to wait on a $PATH return and search for your program. Learn each functions options so you dont stack things together for no good reason.
this:
FINDPATH=/here;
PROGRAM=/usr/bin/touch;
FINDFLAGS="-this -than -theother";
find $FINDPATH $FINDFLAGS -name regex -exec $PROGRAM {} \;
is about 1000 times faster than this:
for x in `find / | grep -e regex`ldo program $x;done
I believe that some comments are good but overcommenting is messy. I prefer to do my commenting in blocks as small descriptions of what the code is indended to do.
I like to organize my subroutines and objects etc by their type. This way I can search my code for 'OBJECTS' and fine the section that describes objects or 'SUBROUTINES' and I will have made sub sections via comments 'SUBROUTINES_SEARCH' etc etc. I like few, simple, concise comments. I do a lot of work in bash for administering servers but bash scripts should be clean and properly commented just like C or PHP etc.
#!/bin/BASH
#Code specific to bash or bash compatible shells. author *ME*
# INCLUDES /etc/script.conf /usr/share/script/functions/*
include
include
# SUBROUTINES
[item1]
#workorder5678 custom;
function1;function2;#end wo5678 1/1/2007, edit 3/18/2007;
function3;end;
[item2]
function1;function2;function3;end;
#end
NOT
#this is item1. i like to put long comments that are as big as the code.
#i dont consider the fact that anyone reading these scripts in the future only
#needs to know why I did this and what it is supposed to do, not how it does it. if you dont know how it does it then you are in the wrong job
[item1]
function1;function2;function3;end;
#this is item2. it is almost like item1 above.
#I know I shouldn't reference physical locations in a file because they might move for organization but
#I thought id put a note in here that item2 references item3 with is at line 652 and item3 references item1 which is right above this on line 601.
[item2]
function1;function2;function3;end;
I think an important definition to point out is that 'comment' is not the same as 'document'. Put comments in to assist you in the future, to find code, to give a quick hint at the functions intended use so you can use that code better. Dont describe how to do a if/fi statement or how to use a function.
At first they did. They didnt understand what they should have to send an email to helpdesk and not make all those phone calls, or send email to individual emails. It took about 1 month then they say that their issues are handled promptly because the process was more efficient.
The truth is that there is no benchmark for this. I am a consultant and tend to take a sysadmin role for clients.
If you use Active Directory and store user files on the network then you can do stock images for each model of machine and a broken unit is a 20minute re-image (or swap fresh machine in from the pool) and your up and going, documents and all. This is where a directory services' up-front costs become justified.
With Active Directory I can manage machines and users very efficiently, keep user's files safe with shadow copies, backups, etc, and deploy software and printers to users easily. For linux to Active directory look at likeise-open or centrify for single sign on with the latery able to do group policy on linux machines.
I have 4 techs and myself. between the 5 of us we handle about 2500 or so users across our clients. Our clients that have been with us for a year or two are all have some sort of AD setup and have a much lower computer expense than before. oddly enough, newer clients account for larger expenses because they havent standardized their computers ad require more trips to their site and more billable hours.
I would imagine that if I had only established users, with computers on AD then my crew could handle 3000-3500 users without much overtime. If we did no managed computers then I think that 250 users per tech would be pushing it.
If you just compare those numbers, 600 vs 250 you can pretty easily see the cost savings for a managed network, either through AD, network, or other LDAP. a 1200 user network could be reasonably run by 2 IT guys vs really needing 4 or 5 to do the same job otherwise. let be conservative and say 4 guys at $40,000 each vs 2 guys at $50,000 (higher skills for 2 techs vs 4) and you see a $60,000 gap, which is much more than the CALS and servers needed for 1200 users. 1200 users is still in the 2 ADDS servers arena. lets say $3500 per licensed server and $35 per CAL and you save money on year 1, next 4 years are free!.
Right now it is kind of handy because my guys work their ~40 hours doing stuff on managed networks and pull 'overtime' going to customers sites or doing old computer triage and repair and get paid part of the service fee.
If you are at 600+ users per tech, then you really should be on some sort of directory service like AD. If you are not, I suspect you are spending a lot of your labor dollars spinning tires and not helping clients/users very well. That equals more compaints, less praise, and likely a lack of raise or bonus.
spending that cash on a yearly subscription to playboy certainly would have netted the world a new open source porn system providing free as in beer porn to the world!
I think you are missing the point on thin clients. A PC for a basic client has a pretty limited lifespan and tends to require in-the-field support. It also requires antivirus software, some level of routine maintenance, and has a substantial failure rate in either software or hardware. A thin client lasts a very long time and needs basically zero in-the-field support, no antivirus(server side A/V instead), etc etc.
When you licenses office or terminal services use, you tend to get better pricing than standalone versions and with software assurance you can stay with the most up-to-date versions for a reasonable price.
The Thin client costs as much as a PC up front but will last 2-3 times as long, which in a big picture thought process means they cost 1/2-1/3. Less IT guys in the field saves money in wages.
Thin clients typically burn 20-30W where a PC will typically burn 180-220W. A single PC can cost $160-200 per year in electricity and a thin client just $13-15. if you have 200 stations thats a difference of $32,000 vs $2600. If you design to have servers run desktops and separate server run apps then you can likely get 200 users into maybe 4 servers (An RDP server and 3 Application servers) and have a nice thin-client system with web and office.
Other benefits are that every user runs the same version of software. Every user has access to the same storage for documents. much more confidence in security settings being applied as there is no local PC to hack on. Have a user with special software needs? You can assign a user to a Hyper-V instance running the OS and software they need. Need to help a user to do something? RDP allows you to share there desktop easily without another package and at reasonable performance.
seriously, buy a new router to replace a 'broken' one from a location and then somehow fix the broken one for your lab/office.
The truth is that sometimes you not only lack the equipment for lab testing, but also the real world usage scenario. I am often stuck in a situation where I must backup a config and then experiment with production equipment and so am forced to do this outside of business hours. I usually get a chance to do some functional testing offline but cant really put new systems through there paces very well in a lab.
The real key to success here? know what you are doing. You may have to work in less that ideal circumstances but you must be knowledgeable enough to fix a mistake in a reasonable amount of time.
Also consider getting your hands on a rig to do some virtualization. You can virtualize routers and server with something like Xenserver, vmware, or virtualbox. I have done an entire mock deployment of a cisco firewall + windows server 2008 r2 system for remote client access(Windows) and site-to-site vpns(cisco) on a single Xenserver because I can virtualize the cisco router (its slow), windows servers, and even create seperate networks to simulate seperate switches, sites, network segments etc. Q6600+8GB can be had for less than a grand at dell in whitebox.