Unless your client and server support IMAP IDLE, in which case you maintain a persistent connection. There's a tiny bit of heartbeat traffic once in a while, but you get notified of new email as soon as it appears in your box.
It really depends on the company and the user base. I've worked in a lot of different environments with a lot of different layouts.
I interned as a developer at a 35 person company in Japan that had 0 IT staff. It was full of developers with a few marketing and business people, and everyone was responsible for managing their own workstation. There were a few knowledgeable employees who helped others with computer problems, but no full-time staffers. E-mail / groupware was outsourced to a third party provider. There was no central authentication or anything of the sort. Surprisingly, the system worked pretty well, although some of the development practices were a bit outdated -- but that's really an orthogonal issue.
I worked at another company here in Vancouver with a similar setup. They had a totally heterogeneous computing environment, users generally manage their own machines (though the IT department provided a base software layout). They did however have a full time IT staff of 4 for 250 employees, and there was some degree of central auth, as well as stuff like databases and our own mail server. There was also a fairly large group of non-technical users, whose machines were completely handled by one of the IT staffers.
Another example, I worked as a contractor at another company here in Vancouver approximately 1200 employees in size. At one point we had 10 satellite offices, and 8 remote IT people, with another 15 full time at the main office here. Everything was large scale.. lots of Oracle databases, racks and racks of NetApps, tons of servers, Unix workstations, a full parallel Windows environment. Huge and complicated.
Currently I'm at a small company of just over 20 employees. However, we have 3 people who are full time "IT". This is to support our highly technical user base of scientists and in-house software developers, and we also have an 80-node compute cluster to run, as well a surprisingly elaborate array of services for the users. However, the need to have 3 staff is mostly because of the different roles to fill. One of us takes care of most of the desktop and user-facing things such as VPN, email, etc. The other two take care of running the simulation systems, maintaining the Unix environment, and working with the developers to develop the software for the cluster and vice-versa.
So as you can see, just in my experience, I can provide four vastly different examples. Every business is different. There's no one formula that can fit all environments. It really depends on your user base and business need.
1. Does not verify your identity in any way whatsoever. Anyone could spoof your site, distribute their own CA root certificate, and use it to sign the SSL certificate their spoofed HTTPS server uses.
2. Is actually not much better. While in theory GoDaddy will verify your identity before issuing a certificate, in reality their process is not very rigorous and I don't doubt that someone could get a spoof certificate from them.
Personally, for anything important, I wouldn't trust a site that does either option.
Because if they actually send the spam, then the people selling the Viagra might get some hits. And even if they don't make a profit, the fact that they get hits may entice them to try again, providing a potentially larger source of revenue for the people sending the spam.
It doesn't really matter what you name the machines, so long as they are unique names. At my company we use the names of sugars for all our Linux machines, and alcohols for all our macs.
Now, the important part is just to use aliases for all services. So for example, if SMTP runs on a machine called dextrose, then create a DNS alias smtp.department.company.com that points to that server. If there is more than one server providing the service, you can either use round-robin DNS (if it doesn't matter which one is used), or just provide a numerical suffix to the alias.
If you have a compute cluster, I strongly recommend numbering the machines sequentially, then you can use a tool like PDSH or bash {} expansion to address groups of machines.
Maybe so, but I do know for a fact that there exist stores in Tokyo that buy uses schoolgirl uniforms for a decent amount of money and sell them for a hefty sum. By that standard, it's not too far fetched to image the same might be possible for the used panty machines also.
You're right that you can't call yourself a "Professional Engineer" but you can call yourself pretty much anything else with the work "Engineer" in it. See point 2 in the very article you linked to.
Also, good look getting a P.Eng designation doing anything network or software related. You have to work under another P.Eng for a number of years, and finding one in those fields is pretty much impossible.
In theory yes. However, it seems that this is rarely enforced in the high tech industry. In fact, as far as I can tell, it's nearly impossible to get a "Professional Engineer" designation in many fields, particularly software related. I have a degree in Computer Engineering, my iron ring, and now do primarily software and systems level work. I've not yet come across anyone at the companies I've worked at who does work similar to mine and has their "P. Eng" designation. Therefore it's pretty much impossible for me (or most people who graduate from a program similar to mine, for that matter) to ever achieve Professional Engineer status.
Having lived and worked as a programmer in Japan for around a year (now back in Canada) I have to agree with your evaluation 100%. I met a lot of young people, either still in University, or having just entered the workforce, and most of them were not interested in spending their live living the salaryman lifestyle. In fact, my company was having a lot of problems with people leaving their jobs to either start their own web-based company, or go overseas. They preferred it to the 14-16 hour days typical at our little programming shop. It was mostly the old hawks who were persisting in this style, and of course, since it's frowned upon to leave before your supervisor, everyone else would follow suit.
Anyway, I love Japan as a country, and would love to go back there some day. However, I would never work there, at least not in a traditional workplace, since I don't want to waste away chained to my desk.
Not sure what you mean by that. We're an enterprise, we use macs pretty much exclusively. I know of at least a few other companies in the area that do the same thing. I guess I am imagining things then?
I was being sarcastic. My point is that you can't (easily) do that with the DNS server on OS X. Nor can you (easily) create a secondary reverse zone. Major oversights in the UI. I'm not even going to get in to the numerous other problems with regards to managing DNS on OS X...
Believe me, if it was possible to do managed OS X clients with a Linux server, I'd be there in a snap. And as another poster mentioned, you'd be hard pressed to find a complete directory service implementation (LDAP, Kerberos, etc) that matches what Open Directory gives you.
Now if only Apple would get their shit together when it comes to their server products. Anyone who has had to administer OS X 10.5 Leopard Server knows that the entire release was a complete gong show. From crashing AFP and directory services, to a half-implemented calendaring solution, a laughably broken server administration GUI (I mean, who would want to mark reverse zones as transferable _anyway_), and countless other problems... Microsoft , Red Hat, SuSE and Ubuntu are just walking all over them when it comes to the server offering.
Sure the Apple stuff is integrated and works for the basic case. However, if you try to move past what is written in the sparse user manual, you not only lose support for your basic "AppleCare" but also have to spend time figuring out how Apple has mangled the pieces of the open source offerings that hold their stuff together.
That all being said, I think with some work and polish the server side of things could really become a viable solution. It's just not quite there yet. This is coming from someone who administers these things for a living...
I think more likely the overclockers actually have no idea what the heck they are doing 80% of the time and tweak settings in their BIOS till the computer can stay up long enough to play whatever game benchmark they want.
I would say I'm fairly new to Postgres, at least from an administration standpoint. I was just going through their online documentation the other day (which, by the way, is excellent!) and they explained the authentication mechanisms quite well.
Slashdot Mirror
Another common pattern to use for this, as well as for libraries, is the following:
try:
import one_way_to_do_it
except:
import more_common_way_to_do_it
It's not blurred, it's just a new style of impressionist architecture.
Unless your client and server support IMAP IDLE, in which case you maintain a persistent connection. There's a tiny bit of heartbeat traffic once in a while, but you get notified of new email as soon as it appears in your box.
It really depends on the company and the user base. I've worked in a lot of different environments with a lot of different layouts.
I interned as a developer at a 35 person company in Japan that had 0 IT staff. It was full of developers with a few marketing and business people, and everyone was responsible for managing their own workstation. There were a few knowledgeable employees who helped others with computer problems, but no full-time staffers. E-mail / groupware was outsourced to a third party provider. There was no central authentication or anything of the sort. Surprisingly, the system worked pretty well, although some of the development practices were a bit outdated -- but that's really an orthogonal issue.
I worked at another company here in Vancouver with a similar setup. They had a totally heterogeneous computing environment, users generally manage their own machines (though the IT department provided a base software layout). They did however have a full time IT staff of 4 for 250 employees, and there was some degree of central auth, as well as stuff like databases and our own mail server. There was also a fairly large group of non-technical users, whose machines were completely handled by one of the IT staffers.
Another example, I worked as a contractor at another company here in Vancouver approximately 1200 employees in size. At one point we had 10 satellite offices, and 8 remote IT people, with another 15 full time at the main office here. Everything was large scale.. lots of Oracle databases, racks and racks of NetApps, tons of servers, Unix workstations, a full parallel Windows environment. Huge and complicated.
Currently I'm at a small company of just over 20 employees. However, we have 3 people who are full time "IT". This is to support our highly technical user base of scientists and in-house software developers, and we also have an 80-node compute cluster to run, as well a surprisingly elaborate array of services for the users. However, the need to have 3 staff is mostly because of the different roles to fill. One of us takes care of most of the desktop and user-facing things such as VPN, email, etc. The other two take care of running the simulation systems, maintaining the Unix environment, and working with the developers to develop the software for the cluster and vice-versa.
So as you can see, just in my experience, I can provide four vastly different examples. Every business is different. There's no one formula that can fit all environments. It really depends on your user base and business need.
1. Does not verify your identity in any way whatsoever. Anyone could spoof your site, distribute their own CA root certificate, and use it to sign the SSL certificate their spoofed HTTPS server uses.
2. Is actually not much better. While in theory GoDaddy will verify your identity before issuing a certificate, in reality their process is not very rigorous and I don't doubt that someone could get a spoof certificate from them.
Personally, for anything important, I wouldn't trust a site that does either option.
Or if you ignore the subsequent warning when it changes. That's the likely case for most users who don't know any better.
Apple? Doing thorough testing? You must live in some kind of alternate universe where Apple products don't break with every update...
- Frustrated user of Apple server products.
Because if they actually send the spam, then the people selling the Viagra might get some hits. And even if they don't make a profit, the fact that they get hits may entice them to try again, providing a potentially larger source of revenue for the people sending the spam.
It doesn't really matter what you name the machines, so long as they are unique names. At my company we use the names of sugars for all our Linux machines, and alcohols for all our macs.
Now, the important part is just to use aliases for all services. So for example, if SMTP runs on a machine called dextrose, then create a DNS alias smtp.department.company.com that points to that server. If there is more than one server providing the service, you can either use round-robin DNS (if it doesn't matter which one is used), or just provide a numerical suffix to the alias.
If you have a compute cluster, I strongly recommend numbering the machines sequentially, then you can use a tool like PDSH or bash {} expansion to address groups of machines.
I hate to be pedantic, but 1.0 mW is not higher than 1.1 mW ...
Maybe so, but I do know for a fact that there exist stores in Tokyo that buy uses schoolgirl uniforms for a decent amount of money and sell them for a hefty sum. By that standard, it's not too far fetched to image the same might be possible for the used panty machines also.
You're right that you can't call yourself a "Professional Engineer" but you can call yourself pretty much anything else with the work "Engineer" in it. See point 2 in the very article you linked to.
Also, good look getting a P.Eng designation doing anything network or software related. You have to work under another P.Eng for a number of years, and finding one in those fields is pretty much impossible.
If you thought the Vancouver winter was bad, be glad you didn't move... well.. pretty much anywhere else in Canada.
In theory yes. However, it seems that this is rarely enforced in the high tech industry. In fact, as far as I can tell, it's nearly impossible to get a "Professional Engineer" designation in many fields, particularly software related. I have a degree in Computer Engineering, my iron ring, and now do primarily software and systems level work. I've not yet come across anyone at the companies I've worked at who does work similar to mine and has their "P. Eng" designation. Therefore it's pretty much impossible for me (or most people who graduate from a program similar to mine, for that matter) to ever achieve Professional Engineer status.
We ran in to the same problem. We had to roll back our file server to 10.4
Apparently not so well.
Having lived and worked as a programmer in Japan for around a year (now back in Canada) I have to agree with your evaluation 100%. I met a lot of young people, either still in University, or having just entered the workforce, and most of them were not interested in spending their live living the salaryman lifestyle. In fact, my company was having a lot of problems with people leaving their jobs to either start their own web-based company, or go overseas. They preferred it to the 14-16 hour days typical at our little programming shop. It was mostly the old hawks who were persisting in this style, and of course, since it's frowned upon to leave before your supervisor, everyone else would follow suit.
Anyway, I love Japan as a country, and would love to go back there some day. However, I would never work there, at least not in a traditional workplace, since I don't want to waste away chained to my desk.
I couldn't agree more.
Not sure what you mean by that. We're an enterprise, we use macs pretty much exclusively. I know of at least a few other companies in the area that do the same thing. I guess I am imagining things then?
I was being sarcastic. My point is that you can't (easily) do that with the DNS server on OS X. Nor can you (easily) create a secondary reverse zone. Major oversights in the UI. I'm not even going to get in to the numerous other problems with regards to managing DNS on OS X...
Believe me, if it was possible to do managed OS X clients with a Linux server, I'd be there in a snap. And as another poster mentioned, you'd be hard pressed to find a complete directory service implementation (LDAP, Kerberos, etc) that matches what Open Directory gives you.
The newer XServe hardware is thankfully much better, although I'm still pissed that Apple only supports FC SANs for XSan.
Now if only Apple would get their shit together when it comes to their server products. Anyone who has had to administer OS X 10.5 Leopard Server knows that the entire release was a complete gong show. From crashing AFP and directory services, to a half-implemented calendaring solution, a laughably broken server administration GUI (I mean, who would want to mark reverse zones as transferable _anyway_), and countless other problems... Microsoft , Red Hat, SuSE and Ubuntu are just walking all over them when it comes to the server offering.
Sure the Apple stuff is integrated and works for the basic case. However, if you try to move past what is written in the sparse user manual, you not only lose support for your basic "AppleCare" but also have to spend time figuring out how Apple has mangled the pieces of the open source offerings that hold their stuff together.
That all being said, I think with some work and polish the server side of things could really become a viable solution. It's just not quite there yet. This is coming from someone who administers these things for a living...
I think more likely the overclockers actually have no idea what the heck they are doing 80% of the time and tweak settings in their BIOS till the computer can stay up long enough to play whatever game benchmark they want.
I would say I'm fairly new to Postgres, at least from an administration standpoint. I was just going through their online documentation the other day (which, by the way, is excellent!) and they explained the authentication mechanisms quite well.