It takes a programmer to understand how impressive an elegant solution is. Instead, try and convey the joy you found in hitting upon that solution, and the satisfaction of implementing it.
Forget trying to impress people. Elon Musk isn't impressive because of what he says, he's impressive because he makes giant visions happen.
With servers being generally virtual these days, and the underlying physical hardware a highly replaceable substrate, there's no reason for an enterprise to have serves which do more than one thing. If a server does only one thing, it ought to be named for that one thing.
mailserver-eastcoast.example.com
Where is that machine? Somewhere in the blade cage. If I yank the blade, it'll appear in a few seconds on another blade. Where is the data? On the giant fiber RAID, which is replicated in the west coast office, and two secret locations.
Compute is a cloud, storage is a cloud, services come from that cloud, the clouds made of physical devices in as many locations as make sense.
The old physical network topology is finally just the nerves and pumps, and no longer the focus.
The focus is the data. The data is what we produce to make value, to drive the business process. Servers aren't special anymore, they're like hammers. You don't name hammers, typically. But you might have more than w=one, and you definitely want to know two things: where is it, and what is it for.
If someone wants to steal something, and you are trying to prevent it, short of a body cavity search everyday, you've already lost the game. You can steal a code base and drawings for virtually any product by simply copying it onto a USB flash drive, and walking out. Often your cell phone will suffice.
If you are trying to prevent viruses and stuff, the same techniques apply for company owned laptops versus employee owned. If they can take it home, it can get infected. You might ameliorate things by having a forced virus checker installation, but a voluntary one will generally work just as well.
In the end, the only thing you are can't do is take the machine away, but this is such a rare event that it's almost not worth considering.
Process isn't a substitute for thinking, process is a substitute for forgetting. A well designed process is simply the thing you'd do if you could keep every *actually* important detail in your head at all times.
You should certainly file bugs against a process (in the same way you would against any work product) if you perceive that a step or steps is useless or wrong.
You *are* following a process, it's just ad hoc, and maybe made up on the spot. Formalizing that process is a way to make it repeatable, and debuggable.
That said, and to reiterate, you must fight against the bad process. Bad process isn't clear. It's a bad program. Debug it.
So, thinking like a would be cracker, the list of basic places to try first:
Persons front door. One of their windows. A bank near their house. Their car, if visible.
Etc. Given the usual kind of passwords people choose for themselves, I expect this will be similar.
Of course, this assumes the cracker can figure out the person's address, but we know how easy that can be.
I have been teaching people to use a complicated random password, but to go ahead and write it down. Then the basic security problem is getting them to control that piece of paper (keep it in your wallet, please), and makes over-the-net cracking much harder. Most of my users never had a problem with this.
People are dumb. Millions of people would select something like the entrance for Fort Knox, or Norad, or a local bank. You have a training problem just as large as the one you have now.
It's a bit like getting a certificate that you have no apples. The certificate accomplishes nothing except to fill a space that does not need to be filled.
Except that the space is never not filled. 0 is a valid address. The certificate means we haven't figure out how many apples you have yet.
1. Do not belittle or otherwise blow off the customer's fear. In fact, hear it, and agree that it's something to think about.
Them: "I'm worried about this Linux stuff. A guy was telling me that anyone could see the code, and just know how to hack it!"
You: "I can understand how that could be a concern. It is a little like having a map of the valuables in your house taped to your front door."
2. Explain why openness is helpful
Them: "Yeah, so what should we do?"
You: "To be honest, sir, the reason why we like that anyone can see the code is because that means anyone can fix those problems. And lots of people do, for the very same reason you are worried about it. They need something that's secure, and isn't going to surprise them."
3. Mention that serious people have a big stake in making this work.
You: "I should mention that a few companies have bet a lot of money on open source, and wouldn't be happy to see it easily broken. IBM, Novell, and Oracle, to name a few, have very large investments in Linux, and have donated many patches to make sure the code is secure. And for that matter, so has the NSA. They have actually extended the security quite a bit, with their Security Enhanced Linux."
4. Reassure them that people are thinking hard about this.
Them: "Yeah, but if anyone can see it..."
You: "...then you have to be extra careful. See, the strategy that Open Source follows, and everyone should, is to assume that everyone *can* see the code, so you better design it so that the real keys to the kingdom aren't in the code at all. You make sure the keys are completely in the hands of the owners of the system, so it doesn't matter if you can see how the lock works, you still don't have the keys."
5. Point out the obvious.
Them: "But what happens if someone tries to slip something in, and is really good at it?"
You: "Once in a while, someone tries. But when a thousand people might look at the files you are trying to sneak in, someone's going to notice. And then a hundred thousand geeks will make fun of you. In public, all over the internet."
There is that, but let's give the waitstaff their due: Trying to do refigure a split check in the middle of a busy dinner is like trying to do your taxes while being pelted with gobbits of cream cheese by taunting girls scouts carrying yappy dogs barking Jingle Bells.
Cut them a break, and let a pocket calculator help.
Making a wry comment based on someone else's poor interpretation of an article: $0.02.
Making a joke in a cliched format you didn't invent: $0.00
Reading the damned source article all the way before you make a fool out of yourself in public: Well, I wouldn't call it priceless, but something like that.
The patent describes a device for accepting credit card payments at the table of the patron, allowing them to pick their amounts paid, and therefore saving the patrons and the waitrons from the hassle of communicating all this back and forth and dealing with the subsequent mistakes.
I think the question to ask is what would bring her the most joy, which might be the thing that challenges her. She should try a little of everything, and find the thing that engages her, makes her feel alive and driven.
I'd suggest looking into Howard Gardeners Multiple Intelligences writing to get an idea of the scope of the situation.
I don't know that it applies to this situation, but one of the problems of letting random people in a company produce their own queries and the reports thereafter is that one can write a query which looks okay, but actually skews the data to make the report writer (often a mid-level manager) look good.
So, one reason to refuse direct access is reporting integrity.
I'd suggest the folders can be okay if you have a filing system.
My suggestion is that the filing system consist of a folder for each project you are working on, and an archive for folders from past projects.
Don't let yourself have a "miscellaneous" folder, that'll just become a dumping ground for things no-one wants to deal with.
Don't forget to make a few folders for things you might not consider a project, like suggestions for future projects.
So, imagining that you are a kite-flying organization, some example folders:
March-fly-in-2009: Club sponsored flying event to be held on campus Kite-surfing-class: club arranged class with kite surfing expert Box-kite-workshop: lets' teach the local elementary students to make and fly box kites Complaints: Messages we have received that we must address with some useful action. suppliesApril08: a discussion of needed supplies for the office and the regular kite-making meeting budget09: talk regarding the budget we have to submit to Student government to get our allowance archive: Old projects, budghets and supplies discussions
The key to these things is to be brutal about taking care of the mail. Don't keep old projects in the main area, don't lump all projects together, and don't let random crap pile up. If it does move the goals of the organization forward, delete it. Only save old projects so you can see the history of the why's behind your decisions and actions. Don't save the jokes, asides, and complaints about the thread getting offtopic, kill them right away.
Tagging won't help unless you have a plan that sayswhy you are tagging. Having both can be good, because you can use them to set the state of a piece of mail.
Consider this tag set:
Suggestion-to-be-reviewed Supplies-Committee-todo classes-committee-todo Agreements Actions-done Information
You could probably come up with others that more fit your situation. The point is to use the tag to indicate what needs to be done with the email. An email containing the final list for the next supply run could be marked with the supplies-todo tag, and when the supplies are acquired, marked with the Actions-done tag.
The goal in this is to have a process by which each email is dealt with as rapidly as possible, by providing the right place for it to be, and maybe some markers to help people find it again if needed. Most importantly, you must make real decisions about what "needed" means. Don't fall into the 12,000 emails trap. Even with a good search function, there are too many things that will be similar, and you'll have to look at 2000 emails to find that one you remember from 2 years ago.
Well, I'm no deep OS guy, but I'm dubious about a few things with respect to this. One is the use of garbage collection in the kernel. The other is microkernel design. Maybe they've figured out the overhead problems with message passing. I'd have to wait and see.
I'm also dubious about the insistence on type safe languages. These often come with an execution penalty, which can limit speed. And despite recent advances in hardware design, speed is still important.
So all in all, it looks interesting, but I'll remain dubious until it is well tested.
You still haven't convinced me this isn't the same as closed source. Closed source projects are occasionally run by brilliant people, but for the most part the coders are also average folks. Worse yet, their parameters are being set by marketing folks or customers, not experts in the field.
So, with Open source, you get a random set of coders contributing whatever they want, when they want, and hopefully a central person or team that vets the contributions. Then they "release" a beta, and a bunch of people check it, and bugs get noted and fixed. Then they ship it!
In a close shop, you get a "hand picked" (from the available pool) {read "random"} set of coders, contributing what some person wants (which might mean they do a less than stellar job, because they hate the assignment, or they're over their head). This code is peer reviewed (maybe) and sent to testing, which may be mature, or maybe clueless. Then they ship it! Except sometimes they ship it before the testers have had enough time, becuase they really need to hit the store before Christmas, or the next CES or whatever.
The main difference between Open Source, and Closed source is that OSS tends to be effectively peer reviewed by a lot more people, and ClSS tends to pay closer attention to the desires of the customer. All the other factors are darned close to random, and seem to mostly cancel each other out.
Attaching open source to these statements clouds the issue. Serious innovation isn't being supported anywhere, except perhaps in Universities. Even there it's hard because the interesting stuff is at the fringes. Businesses aren't interested in it because that won't make them money any time soon.
OS creation isn't that interesting to most people, because once you know enough about it, you realize that while the Unix paradigm may not be perfect, getting to a current Unix's level of capability and stability would take decades.
I can imagine the "unscrupulous person" scenario. However, my company use Dells, and has a support contract, and they have never replaced anything that they didn't essentially make our tech prove was broken first.
It's more likely that Dell is taking the drive so that they can get some money back from the manufacturer when the drive is under warranty. They are, after all, a business and if it wasn't their fault the drive failed early, they shouldn't have to suck up the cost.
Sure, that's cool and stuff, and I'm sure we'll eventually overcome the other technological problems, but the energy is a gigantic factor in this. How much would the fuel cost jump to have a two hour flight from NYC to Tokyo? Would it be worth it? Remember that ten times faster might mean 1000 times more costly!
Flexibility is defined by Young's Modulus, "E". Carbon fiber has a much higher ratio of Young's Modulus to weight, and a higher outright value of Young's Modulus, than aluminum. How is this statement different from the statement it was a response to, save that it's longer and contains more obscure terms?
Actually, yes, it is. Carbon monoxide and cyanide gas in smoke is the biggest killer in fires, including aircraft fires. Excellent point. It makes it harder to get out of a fire if beyond merely being burnt and asphyxiated, you are also being poisoned.
I won't speak to the accuracy of the studies that you might be citing, I haven't read them. But remember that anecdotes collected on the internet, or anywhere else, are almost useless since they are self-selecting participants in an ill designed casual survey. You don't have a real survey, you have the rantings of perhaps ill treated people.
I'm also worried about the silly statement about security vulnerabilities. "It's Linux, no worries" is one of those stupidly optimistic statements that make me cringe.
If you pay attention to the security announcements, you know that Linux is anything but secure. Better than Windows might be a reasonable statement. His "no worries" makes me wonder how many of his boxes are running irc and spam bots.
Slashdot Mirror
It takes a programmer to understand how impressive an elegant solution is. Instead, try and convey the joy you found in hitting upon that solution, and the satisfaction of implementing it.
Forget trying to impress people. Elon Musk isn't impressive because of what he says, he's impressive because he makes giant visions happen.
Nailed it.
With servers being generally virtual these days, and the underlying physical hardware a highly replaceable substrate, there's no reason for an enterprise to have serves which do more than one thing. If a server does only one thing, it ought to be named for that one thing.
mailserver-eastcoast.example.com
Where is that machine? Somewhere in the blade cage. If I yank the blade, it'll appear in a few seconds on another blade. Where is the data? On the giant fiber RAID, which is replicated in the west coast office, and two secret locations.
Compute is a cloud, storage is a cloud, services come from that cloud, the clouds made of physical devices in as many locations as make sense.
The old physical network topology is finally just the nerves and pumps, and no longer the focus.
The focus is the data. The data is what we produce to make value, to drive the business process. Servers aren't special anymore, they're like hammers. You don't name hammers, typically. But you might have more than w=one, and you definitely want to know two things: where is it, and what is it for.
If someone wants to steal something, and you are trying to prevent it, short of a body cavity search everyday, you've already lost the game. You can steal a code base and drawings for virtually any product by simply copying it onto a USB flash drive, and walking out. Often your cell phone will suffice.
If you are trying to prevent viruses and stuff, the same techniques apply for company owned laptops versus employee owned. If they can take it home, it can get infected. You might ameliorate things by having a forced virus checker installation, but a voluntary one will generally work just as well.
In the end, the only thing you are can't do is take the machine away, but this is such a rare event that it's almost not worth considering.
Process isn't a substitute for thinking, process is a substitute for forgetting. A well designed process is simply the thing you'd do if you could keep every *actually* important detail in your head at all times.
You should certainly file bugs against a process (in the same way you would against any work product) if you perceive that a step or steps is useless or wrong.
You *are* following a process, it's just ad hoc, and maybe made up on the spot. Formalizing that process is a way to make it repeatable, and debuggable.
That said, and to reiterate, you must fight against the bad process. Bad process isn't clear. It's a bad program. Debug it.
So, thinking like a would be cracker, the list of basic places to try first:
Persons front door.
One of their windows.
A bank near their house.
Their car, if visible.
Etc. Given the usual kind of passwords people choose for themselves, I expect this will be similar.
Of course, this assumes the cracker can figure out the person's address, but we know how easy that can be.
I have been teaching people to use a complicated random password, but to go ahead and write it down. Then the basic security problem is getting them to control that piece of paper (keep it in your wallet, please), and makes over-the-net cracking much harder. Most of my users never had a problem with this.
People are dumb. Millions of people would select something like the entrance for Fort Knox, or Norad, or a local bank. You have a training problem just as large as the one you have now.
It's a bit like getting a certificate that you have no apples. The certificate accomplishes nothing except to fill a space that does not need to be filled.
Except that the space is never not filled. 0 is a valid address. The certificate means we haven't figure out how many apples you have yet.
1. Do not belittle or otherwise blow off the customer's fear. In fact, hear it, and agree that it's something to think about.
Them: "I'm worried about this Linux stuff. A guy was telling me that anyone could see the code, and just know how to hack it!"
You: "I can understand how that could be a concern. It is a little like having a map of the valuables in your house taped to your front door."
2. Explain why openness is helpful
Them: "Yeah, so what should we do?"
You: "To be honest, sir, the reason why we like that anyone can see the code is because that means anyone can fix those problems. And lots of people do, for the very same reason you are worried about it. They need something that's secure, and isn't going to surprise them."
3. Mention that serious people have a big stake in making this work.
You: "I should mention that a few companies have bet a lot of money on open source, and wouldn't be happy to see it easily broken. IBM, Novell, and Oracle, to name a few, have very large investments in Linux, and have donated many patches to make sure the code is secure. And for that matter, so has the NSA. They have actually extended the security quite a bit, with their Security Enhanced Linux."
4. Reassure them that people are thinking hard about this.
Them: "Yeah, but if anyone can see it..."
You: "...then you have to be extra careful. See, the strategy that Open Source follows, and everyone should, is to assume that everyone *can* see the code, so you better design it so that the real keys to the kingdom aren't in the code at all. You make sure the keys are completely in the hands of the owners of the system, so it doesn't matter if you can see how the lock works, you still don't have the keys."
5. Point out the obvious.
Them: "But what happens if someone tries to slip something in, and is really good at it?"
You: "Once in a while, someone tries. But when a thousand people might look at the files you are trying to sneak in, someone's going to notice. And then a hundred thousand geeks will make fun of you. In public, all over the internet."
There is that, but let's give the waitstaff their due: Trying to do refigure a split check in the middle of a busy dinner is like trying to do your taxes while being pelted with gobbits of cream cheese by taunting girls scouts carrying yappy dogs barking Jingle Bells.
Cut them a break, and let a pocket calculator help.
Making a wry comment based on someone else's poor interpretation of an article: $0.02.
Making a joke in a cliched format you didn't invent: $0.00
Reading the damned source article all the way before you make a fool out of yourself in public: Well, I wouldn't call it priceless, but something like that.
The patent describes a device for accepting credit card payments at the table of the patron, allowing them to pick their amounts paid, and therefore saving the patrons and the waitrons from the hassle of communicating all this back and forth and dealing with the subsequent mistakes.
I think the question to ask is what would bring her the most joy, which might be the thing that challenges her. She should try a little of everything, and find the thing that engages her, makes her feel alive and driven.
I'd suggest looking into Howard Gardeners Multiple Intelligences writing to get an idea of the scope of the situation.
Upgrades are hard and require smarts and planning. Congratulations, I wish you good ROI.
I don't know that it applies to this situation, but one of the problems of letting random people in a company produce their own queries and the reports thereafter is that one can write a query which looks okay, but actually skews the data to make the report writer (often a mid-level manager) look good.
So, one reason to refuse direct access is reporting integrity.
I'd suggest the folders can be okay if you have a filing system.
My suggestion is that the filing system consist of a folder for each project you are working on, and an archive for folders from past projects.
Don't let yourself have a "miscellaneous" folder, that'll just become a dumping ground for things no-one wants to deal with.
Don't forget to make a few folders for things you might not consider a project, like suggestions for future projects.
So, imagining that you are a kite-flying organization, some example folders:
March-fly-in-2009: Club sponsored flying event to be held on campus
Kite-surfing-class: club arranged class with kite surfing expert
Box-kite-workshop: lets' teach the local elementary students to make and fly box kites
Complaints: Messages we have received that we must address with some useful action.
suppliesApril08: a discussion of needed supplies for the office and the regular kite-making meeting
budget09: talk regarding the budget we have to submit to Student government to get our allowance
archive: Old projects, budghets and supplies discussions
The key to these things is to be brutal about taking care of the mail. Don't keep old projects in the main area, don't lump all projects together, and don't let random crap pile up. If it does move the goals of the organization forward, delete it. Only save old projects so you can see the history of the why's behind your decisions and actions. Don't save the jokes, asides, and complaints about the thread getting offtopic, kill them right away.
Tagging won't help unless you have a plan that sayswhy you are tagging. Having both can be good, because you can use them to set the state of a piece of mail.
Consider this tag set:
Suggestion-to-be-reviewed
Supplies-Committee-todo
classes-committee-todo
Agreements
Actions-done
Information
You could probably come up with others that more fit your situation. The point is to use the tag to indicate what needs to be done with the email. An email containing the final list for the next supply run could be marked with the supplies-todo tag, and when the supplies are acquired, marked with the Actions-done tag.
The goal in this is to have a process by which each email is dealt with as rapidly as possible, by providing the right place for it to be, and maybe some markers to help people find it again if needed. Most importantly, you must make real decisions about what "needed" means. Don't fall into the 12,000 emails trap. Even with a good search function, there are too many things that will be similar, and you'll have to look at 2000 emails to find that one you remember from 2 years ago.
Well, I'm no deep OS guy, but I'm dubious about a few things with respect to this. One is the use of garbage collection in the kernel. The other is microkernel design. Maybe they've figured out the overhead problems with message passing. I'd have to wait and see.
I'm also dubious about the insistence on type safe languages. These often come with an execution penalty, which can limit speed. And despite recent advances in hardware design, speed is still important.
So all in all, it looks interesting, but I'll remain dubious until it is well tested.
You still haven't convinced me this isn't the same as closed source. Closed source projects are occasionally run by brilliant people, but for the most part the coders are also average folks. Worse yet, their parameters are being set by marketing folks or customers, not experts in the field.
So, with Open source, you get a random set of coders contributing whatever they want, when they want, and hopefully a central person or team that vets the contributions. Then they "release" a beta, and a bunch of people check it, and bugs get noted and fixed. Then they ship it!
In a close shop, you get a "hand picked" (from the available pool) {read "random"} set of coders, contributing what some person wants (which might mean they do a less than stellar job, because they hate the assignment, or they're over their head). This code is peer reviewed (maybe) and sent to testing, which may be mature, or maybe clueless. Then they ship it! Except sometimes they ship it before the testers have had enough time, becuase they really need to hit the store before Christmas, or the next CES or whatever.
The main difference between Open Source, and Closed source is that OSS tends to be effectively peer reviewed by a lot more people, and ClSS tends to pay closer attention to the desires of the customer. All the other factors are darned close to random, and seem to mostly cancel each other out.
Attaching open source to these statements clouds the issue. Serious innovation isn't being supported anywhere, except perhaps in Universities. Even there it's hard because the interesting stuff is at the fringes. Businesses aren't interested in it because that won't make them money any time soon.
OS creation isn't that interesting to most people, because once you know enough about it, you realize that while the Unix paradigm may not be perfect, getting to a current Unix's level of capability and stability would take decades.
I can imagine the "unscrupulous person" scenario. However, my company use Dells, and has a support contract, and they have never replaced anything that they didn't essentially make our tech prove was broken first.
It's more likely that Dell is taking the drive so that they can get some money back from the manufacturer when the drive is under warranty. They are, after all, a business and if it wasn't their fault the drive failed early, they shouldn't have to suck up the cost.
Sure, that's cool and stuff, and I'm sure we'll eventually overcome the other technological problems, but the energy is a gigantic factor in this. How much would the fuel cost jump to have a two hour flight from NYC to Tokyo? Would it be worth it? Remember that ten times faster might mean 1000 times more costly!
If a regular course in Mathematics was going to work, why didn't it work when he was in high school?
How about different ways of learning math?
I won't speak to the accuracy of the studies that you might be citing, I haven't read them. But remember that anecdotes collected on the internet, or anywhere else, are almost useless since they are self-selecting participants in an ill designed casual survey. You don't have a real survey, you have the rantings of perhaps ill treated people.
There was a case brought in India, a civil dispute between two guys.
When the case finally hit the docket, it was dismissed because both the plaintiff and the defendant were dead. Of old age.
It had been 23 years since the filing of the suit. That's a "not speedy" court system.
Besides, we never got to the trial. This was just a bunch of prep work leading up to a trial. This was just a hearing, and a ruling on a motion.
>Oh, man, I'm in trouble - ALL my boxes are running irc!
They have creams for that, you know.
I second that notion.
I'm also worried about the silly statement about security vulnerabilities. "It's Linux, no worries" is one of those stupidly optimistic statements that make me cringe.
If you pay attention to the security announcements, you know that Linux is anything but secure. Better than Windows might be a reasonable statement. His "no worries" makes me wonder how many of his boxes are running irc and spam bots.