It looks to me like the STUN server is the one doing the leaking. And that's a function of whatever WebRTC service you're using, not your VPN provider or your browser.
The game does have moderation for location submission. It can take weeks to get a "yes" or "no" response once you've submitted a photo, description, and GPS location.
Your biggest problem isn't humidity, it's going to be salt. Those cargo containers are not airtight, and if nothing else your crates and pallets may be sitting on a dock for an extended period of time. If things are in well-sealed cardboard boxes, it shouldn't be an issue... but you're not very clear on how your stuff is being packed.
Consider getting one of the large rolls of cling-film used for shipping (i.e. similar to saran-wrap). For electronics (TV, computer, printer, maybe even the coffee machine) wrap them individually with the cling-film; it's not perfect, but if done well (i.e. tightly and completely) that should choke-off any salt spray from finding it's way inside.
Also, anything that is on a pallet (but not a crate) should be wrapped and strapped so that the (a) the pallet stays in one piece, and (b) it is tamper-evident.
I use DenyHosts to identify attackers and protect my system. Then, for any new blocked IP, I check to see if it's local to my service provider. Generally, I think the service providers will be much more reponsive to one of their customers attacking another, even if it's a compromised machine.
Cheap CCD + Rad source from smoke detector == true RNG. If nothing else, some of the advanced physics or math classes in the district might be interested in the project.
Sounds like this list needs to be broken down into multiple sub-functions.
Web filtering, site access control, and total Internet denial are functions for a web proxy or other content filter. You should be able to find a linux-based web proxy that will do what you want in that department.
Scheduling usage hours, forcing logout, etc. is the sort of thing you can do with "policy" objects if you had a Windows Domain Controller. That's probably outside of your budget. But, generally, you need to be looking for client/workstation policy tools.
The computer health monitoring stuff might be part of the policy tools, but might not.
We seem to get a lot of these sorts of questions at/. -- and as someone who interviews and makes hiring decisions, let me tell you about the number one factor for making the call:
The Value Proposition
At the end of the day, what I'm doing is entering into an agreement where I give you money (and things that cost money, ie. benefits), and you give me your labor. Your skills and experience and a few other factors (ie. culture fit) alter your "productivity", or how much "labor" I get for my money. In other words, I am spending my money on you, and I want to make sure I get good "value" for that money.
As such, I really don't particularly care who you worked for in the past, unless it can be used as some predictor of future performance. I do care about the skills and experience you have picked up along the way, your personality, your thought-process, etc.
Occasionally, very occasionally, the "where you used to work" question does become relevant. If your last job was for a blood-relative, that is going to be a yellow-flag that needs further investigation and verification. That's probably the most common scenario where it comes into play.
Gee, thanks for giving that one away to everyone.:)
As for not knowing much C, if that is a requirement of the position you had better d*mned well tell me you're not that comfortable with the language early in the process.
Two things will get you immediately disqualified during an interview: 1) Lying to me (and getting caught, obviously) 2) Wasting my time, which usually happens due to #1
This is a fair comment. This screening technique would tend to be biased against individuals such as yourself.
At the same time, I would expect that for a job which requires C/C++ and assembly experience, you would review the relevant material before showing up at the interview.
I did have one person ask if I cared if they solved it in another language, because it was easier to solve there. I accepted that answer, so long as the person could tell me *why* it was easier.
As for the puzzles.... I could ask you about your code for solving "well known" problems, but that would show me your ability to recall past problems solved. While that's valuable, what I'm interested in is how you approach problems you've never seen before.
Electricians have to be licensed by a State agency which guarantees a minimum skill level. To get that licensing, they needed to pass a test. They also need to carry insurance, in case they screw up.
I can understand this feeling, but look at it from the other side: As an interviewer, I *need* to know if you're telling me the truth or not. Just the act of hiring you to fire you a week later consumes significant resources; I can't really afford to make a mistake.
Also, I've had people fail the test. And it was a really really simple test. I once asked someone to "write a C function that takes an integer as a parameter and returns the square of that integer". After 15 minutes of fumbling at the whiteboard, they had something that looked like a cross between Matlab and Pascal and completely failed to be anything close to correct, even if you ignored the syntax problems. That candidate claimed to have 20+ years of experience.
Generally, my interviews consist of 3 parts.
First, I ask you some questions about items on your resume. "What was XYZ project like?" "Did you like working with that CPU?" "How was the weather in FOO?" Here, I just want to get a feel for who you are, will you fit our culture, and a quick verification that you at least read the resume you handed to me.
Next, I ask you to solve some simple problems. Square an integer. Why is "#define foo(x) x*x" worse than "#define foo(x) (x)*(x)"? Sort an array. I won't give too many away here, but generally anyone who has actually worked in the field can get these correct. Again, this is just a screening tool.
Finally, we get to the open-ended portion. I hand you a whiteboard marker, and ask you a question which may (or may not) be impossible to solve. Brainteasers, some. Logic puzzles. I want to see you take a problem, take it apart, and put it back together. I warn the candidate (and it's true) that I don't care if they actually get a solution or not; most people don't. This is what really makes or breaks a hire.
Of course, if they can't pass the first two sections of the test, I don't bother with the third.
It sounds like you are a contractor. So, your "clients" have to trust you, don't they? You could read their e-mail, calendar, etc... and if you developed an interest in one of their more famous clients, you could do just as much damage.
The question, then, is not one of "needing to trust Google". The question is, "Is Google more or less trustworthy than the current solution?" There is a fair argument that a large, multi-billion dollar company has a lot more to lose should things go sideways than a contractor. There is also a fair argument that they probably have 1000x more people with access to the data than an independent contractor.
This, of course, ignores any legal requirements like HIPAA, PCI DSS, etc. etc. But I think my point is still valid: If the client has already contracted out management and/or hosting of their data, they have already made the decision to trust an outsider. Going with Google or not is just a question of "which outsider do we trust"
You're probably just joking, but....
If you find that you are completely uninterested in every aspect of your job, then yes, you probably should think about a career change.
Honestly, if you dislike your job that much, you'll probably be a much happier person if you find some other way to make a living.
Writer's block occurs when the stuff you're trying to write is SO BORING or otherwise uninteresting and unengaging that you, yourself don't even care about it. I've heard at least one writer say that writers block is a good thing, as it tells him when he needs to go in another direction.
I would take the same approach to this situation. You've got this piece of code to write, but it's so uninteresting that you don't even care about it. The question then becomes, "Why?" Is it a feature that isn't really needed? Is it an ugly brute-force approach to a problem? Maybe it's just a piece of backend code that you don't really consider "sexy".
Once you figure out why you're not interested, you can then address that problem and the coders block will fix itself.
Depending on your business, you may not need all those things. The original post asks about "small/medium" business... but when you have that many machines, you're clearly a 'medium' business. Small businesses don't need all that.
Also, why are people so hesitant to use multiple levels of DNS domains? Couldn't that server also be named mark-pfs-01.sjc.whatever.com? That way, everyone in SJC knows it just as "marketing production file server 01". Only people off-site need to realize that it's in SJC.
In addition to the "software as a service" and "sell support" models, you could have two versions. One is open-source, the other closed source but more feature rich.
Actually, the fix is actually to back out a command filter option that was put in place a long time ago.
The SCSI core used to send START_UNIT commands arbitrarily during device discovery. Unfortunately, a lot of USB devices choke on that command, so we filtered it out at the usb-storage driver level. Later, the SCSI core was re-written to avoid using this command unless a "needs initialization" ASC/ASCQ was received from the device.
So, we just removed the filter. The device requests a startup command, and the SCSI core obliges.
It's not a bug, or a "POS" if it spins down from inactivity. The bug is in disconnecting from the bus, but even that's probably not an accurate description of the problem. When the device fails to respond, linux engages it's recovery procedure, which involves some device resets. The real bug in the device is that it doesn't spin-up and return to a "good" state after a the various attempts at the recovery procedure.
BTW, the recovery procedure is done as per USB spec. It's not linux-specific.
EOL is really only appropriate if the question of 'support' is taken to mean 'required to fix bugs'. After all, it's perfectly reasonable to say that IE 1 has bugs that weren't fixed, and this web site just won't render properly (even if it's plain HTML). You can substitute your own similar example with another software package easily. But, in this situation, the 'fault' lies in old software which is EOL; a simple upgrade to a supported package would fix the problem.
However, the other half of the question is "should I design to require features which are only present in newer releases"? For example, if you want to use CSS, you're implicitly ruling out lots of old web browser technology (if you assume you want perfectly uniform end-user experience). That question is really driven by the business-end of things; you need to design towards your target audience.
I've had this debate before. It depends on the type of job you want.
Do you want to work on rev 6 of commercial software which is on rev 5? Add a feature or two, port to Vista from XP, etc.? Just polish the existing product, treading no new ground?
Or do you want to work on the cutting-edge? Working with the latest processors, memory controllers, and applications? Do things that nobody else has done ahead of you?
Put another way: I do the later. When I interview job candidates, if they can't explain n-way cache associativity off the top of their head, I'm not interested. Same goes for the Halting Problem. I need people who understand and can THINK, not just code monkeys.
That's not to say that there isn't a place for code monkeys. It's just not in my shop.
If you want an argument to convince the boss, try this one. It's something he can relate to: legal liability.
Several studies have shown that lack of sleep can be just as bad (if not worse) on reaction-time and attention-span than moderate quantities of alcohol. Driving while chronically tired is basically as dangerous as DUI.
Now, if I worked 15 hours a day, that's a minimum of 17 hours that I'm not at home (1 hr commute each way). Add 1 hour to eat a meal twice a day , and I'm down to 5 hours of sleep. That assumes perfect time-allocation, no spin-down time to unwind, no time for showers, etc..
When someone gets killed because one of these workers falls asleep at the wheel after a week of this schedule, guess who is going to get slammed with the lawsuit.
Simple HR-like questions (i.e. how do you handle deadlines, etc).
Simple-to-moderate technical questions (i.e. why is it important to use parens in a #define)
Brainteasers
It's the brainteasers that's where the 'okay' and the 'excellent' really differentiate themselves. The questions I ask have solutions... they take the typical person several days to work out. But I'm not interested in the answers, I just want to see how they think and attack the problem -- can they see the blind alleys? can they recognize when they don't have enough information? what sort of questions do they ask?
Occasionally, I throw a curveball. "I see you have experience with the PPC architecture. What's your favorite PPC instruction?" You'd be suprised how many people answer that with "eieio, because it sounds funny". Which isn't a bad answer -- I wanted to see how they reacted to an unexpected question. Another candidate told me once that (for the ARM platform) the bit-invert function was good for writing highly-optimized bit-manipulation functions for banging away at hardware registers.
Through all of this, tho, you need to keep in mind their personality. Will they play well with the rest of the team? That's a difficult factor to judge, and I'm likely to cut a candidate some slack on this.
The problem with 'user-friendlyness' is really about equal parts an engineering problem and marketing problem.
From the engineering side, products could/should have much better interfaces. The interface should just be more than a way to access every feature. It should present some sort of logical pattern. Part of that is trying to figure out how the product is going to be used (as opposed to should be used), and try to identify how your consumers are going to look at it.
As an example of this, consider the VCR. The basic functions for tape manipulation (play, stop, rewind, fast-forward) are generally on larger buttons and prominently labeled. Good design there -- of course, then they make the buttons needed to program the thing small and badly labled (dark blue text on black background!?!). The engineers failed to recognize that those buttons would be important to me.
On the marketing side, consumers are misled. The easiest way to get someone to identify a task as difficult is to convince them that it should be trivially easy and then make it just slightly more difficult than that. No matter how easy it is to do, if you've got people's expectations set to expect easier, the task seems impossible.
As an example of what I mean by this, consider the PVR marketing which tends to claim that the unit (regardless of who makes it) is just as easy to use as a VCR. That's a nice thing to say... and as someone who has owned multiple VCRs for more than 10 years, I expect something that is downright trivial to operate. Well, they aren't. Luckily I'm used to menus, 'selecting' items, and navigation keys from my experience with other devices... but my expectation (from the marketing) was set to 'extremely easy', and it wasn't.
In summary:
We do need to work on our interfaces as more than just a logical extension of the function set. They should impose some clear structure on the choices based on common usage scenarios.
We need to make the marketing more honest. A PVR is no more difficult to use than a computer, but it's notably more difficult to use than a VCR. It's 1000% better to have someone take a unit home with an expectation of spending 30 minutes to set it up, and have it only take 5. The reverse is not good, and leaves the consumer with a bad taste in their mouth.
My guess on the "how is this a benchmark" question is that they're actually playing speed chess.
Each side is evaluating moves with a maximum time limit per move. If they make a decision sooner, that's fine. But if the time expires, they just take the best move they've found so far.
In theory, whichever side can evaluate more moves to evaluate the alpha-beta minimax tree to a deeper level within the time allowed _should_ win.
So, in effect, they are evaluating which side can look at more nodes/sec, but taking an average over the entire game, and reducing the answer to a one-or-the-other result instead of a numerical comparison.
Like most benchmarks, all it tells you is how well the benchmark ran. But, I have to admit, this is a pretty novel approach.
Slashdot Mirror
It looks to me like the STUN server is the one doing the leaking. And that's a function of whatever WebRTC service you're using, not your VPN provider or your browser.
The game does have moderation for location submission. It can take weeks to get a "yes" or "no" response once you've submitted a photo, description, and GPS location.
And how is this any different from the PICMG 1.x standards?
http://www.picmg.org/v2internal/resourcepage2.cfm?id=8
Lots of people have been building systems around this technology for years using passive backplanes.
Your biggest problem isn't humidity, it's going to be salt. Those cargo containers are not airtight, and if nothing else your crates and pallets may be sitting on a dock for an extended period of time. If things are in well-sealed cardboard boxes, it shouldn't be an issue... but you're not very clear on how your stuff is being packed.
Consider getting one of the large rolls of cling-film used for shipping (i.e. similar to saran-wrap). For electronics (TV, computer, printer, maybe even the coffee machine) wrap them individually with the cling-film; it's not perfect, but if done well (i.e. tightly and completely) that should choke-off any salt spray from finding it's way inside.
Also, anything that is on a pallet (but not a crate) should be wrapped and strapped so that the (a) the pallet stays in one piece, and (b) it is tamper-evident.
I use DenyHosts to identify attackers and protect my system. Then, for any new blocked IP, I check to see if it's local to my service provider. Generally, I think the service providers will be much more reponsive to one of their customers attacking another, even if it's a compromised machine.
Cheap CCD + Rad source from smoke detector == true RNG. If nothing else, some of the advanced physics or math classes in the district might be interested in the project.
Sounds like this list needs to be broken down into multiple sub-functions.
Web filtering, site access control, and total Internet denial are functions for a web proxy or other content filter. You should be able to find a linux-based web proxy that will do what you want in that department.
Scheduling usage hours, forcing logout, etc. is the sort of thing you can do with "policy" objects if you had a Windows Domain Controller. That's probably outside of your budget. But, generally, you need to be looking for client/workstation policy tools.
The computer health monitoring stuff might be part of the policy tools, but might not.
We seem to get a lot of these sorts of questions at /. -- and as someone who interviews and makes hiring decisions, let me tell you about the number one factor for making the call:
The Value Proposition
At the end of the day, what I'm doing is entering into an agreement where I give you money (and things that cost money, ie. benefits), and you give me your labor. Your skills and experience and a few other factors (ie. culture fit) alter your "productivity", or how much "labor" I get for my money. In other words, I am spending my money on you, and I want to make sure I get good "value" for that money.
As such, I really don't particularly care who you worked for in the past, unless it can be used as some predictor of future performance. I do care about the skills and experience you have picked up along the way, your personality, your thought-process, etc.
Occasionally, very occasionally, the "where you used to work" question does become relevant. If your last job was for a blood-relative, that is going to be a yellow-flag that needs further investigation and verification. That's probably the most common scenario where it comes into play.
Gee, thanks for giving that one away to everyone. :)
As for not knowing much C, if that is a requirement of the position you had better d*mned well tell me you're not that comfortable with the language early in the process.
Two things will get you immediately disqualified during an interview:
1) Lying to me (and getting caught, obviously)
2) Wasting my time, which usually happens due to #1
This is a fair comment. This screening technique would tend to be biased against individuals such as yourself.
At the same time, I would expect that for a job which requires C/C++ and assembly experience, you would review the relevant material before showing up at the interview.
I did have one person ask if I cared if they solved it in another language, because it was easier to solve there. I accepted that answer, so long as the person could tell me *why* it was easier.
As for the puzzles.... I could ask you about your code for solving "well known" problems, but that would show me your ability to recall past problems solved. While that's valuable, what I'm interested in is how you approach problems you've never seen before.
Electricians have to be licensed by a State agency which guarantees a minimum skill level. To get that licensing, they needed to pass a test. They also need to carry insurance, in case they screw up.
I can understand this feeling, but look at it from the other side: As an interviewer, I *need* to know if you're telling me the truth or not. Just the act of hiring you to fire you a week later consumes significant resources; I can't really afford to make a mistake.
Also, I've had people fail the test. And it was a really really simple test. I once asked someone to "write a C function that takes an integer as a parameter and returns the square of that integer". After 15 minutes of fumbling at the whiteboard, they had something that looked like a cross between Matlab and Pascal and completely failed to be anything close to correct, even if you ignored the syntax problems. That candidate claimed to have 20+ years of experience.
Generally, my interviews consist of 3 parts.
Of course, if they can't pass the first two sections of the test, I don't bother with the third.
If you're concerned, ask them to carry a performance and fidelity (aka surety) bond.
The question, then, is not one of "needing to trust Google". The question is, "Is Google more or less trustworthy than the current solution?" There is a fair argument that a large, multi-billion dollar company has a lot more to lose should things go sideways than a contractor. There is also a fair argument that they probably have 1000x more people with access to the data than an independent contractor.
This, of course, ignores any legal requirements like HIPAA, PCI DSS, etc. etc. But I think my point is still valid: If the client has already contracted out management and/or hosting of their data, they have already made the decision to trust an outsider. Going with Google or not is just a question of "which outsider do we trust"
You're probably just joking, but.... If you find that you are completely uninterested in every aspect of your job, then yes, you probably should think about a career change. Honestly, if you dislike your job that much, you'll probably be a much happier person if you find some other way to make a living.
Writer's block occurs when the stuff you're trying to write is SO BORING or otherwise uninteresting and unengaging that you, yourself don't even care about it. I've heard at least one writer say that writers block is a good thing, as it tells him when he needs to go in another direction. I would take the same approach to this situation. You've got this piece of code to write, but it's so uninteresting that you don't even care about it. The question then becomes, "Why?" Is it a feature that isn't really needed? Is it an ugly brute-force approach to a problem? Maybe it's just a piece of backend code that you don't really consider "sexy". Once you figure out why you're not interested, you can then address that problem and the coders block will fix itself.
Depending on your business, you may not need all those things. The original post asks about "small/medium" business... but when you have that many machines, you're clearly a 'medium' business. Small businesses don't need all that.
Also, why are people so hesitant to use multiple levels of DNS domains? Couldn't that server also be named mark-pfs-01.sjc.whatever.com? That way, everyone in SJC knows it just as "marketing production file server 01". Only people off-site need to realize that it's in SJC.
In addition to the "software as a service" and "sell support" models, you could have two versions. One is open-source, the other closed source but more feature rich.
Projects like VirtualBox do this sort of thing.
Actually, the fix is actually to back out a command filter option that was put in place a long time ago.
The SCSI core used to send START_UNIT commands arbitrarily during device discovery. Unfortunately, a lot of USB devices choke on that command, so we filtered it out at the usb-storage driver level. Later, the SCSI core was re-written to avoid using this command unless a "needs initialization" ASC/ASCQ was received from the device.
So, we just removed the filter. The device requests a startup command, and the SCSI core obliges.
It's not a bug, or a "POS" if it spins down from inactivity. The bug is in disconnecting from the bus, but even that's probably not an accurate description of the problem. When the device fails to respond, linux engages it's recovery procedure, which involves some device resets. The real bug in the device is that it doesn't spin-up and return to a "good" state after a the various attempts at the recovery procedure.
BTW, the recovery procedure is done as per USB spec. It's not linux-specific.
EOL is really only appropriate if the question of 'support' is taken to mean 'required to fix bugs'. After all, it's perfectly reasonable to say that IE 1 has bugs that weren't fixed, and this web site just won't render properly (even if it's plain HTML). You can substitute your own similar example with another software package easily. But, in this situation, the 'fault' lies in old software which is EOL; a simple upgrade to a supported package would fix the problem.
However, the other half of the question is "should I design to require features which are only present in newer releases"? For example, if you want to use CSS, you're implicitly ruling out lots of old web browser technology (if you assume you want perfectly uniform end-user experience). That question is really driven by the business-end of things; you need to design towards your target audience.
I've had this debate before. It depends on the type of job you want.
Do you want to work on rev 6 of commercial software which is on rev 5? Add a feature or two, port to Vista from XP, etc.? Just polish the existing product, treading no new ground?
Or do you want to work on the cutting-edge? Working with the latest processors, memory controllers, and applications? Do things that nobody else has done ahead of you?
Put another way: I do the later. When I interview job candidates, if they can't explain n-way cache associativity off the top of their head, I'm not interested. Same goes for the Halting Problem. I need people who understand and can THINK, not just code monkeys.
That's not to say that there isn't a place for code monkeys. It's just not in my shop.
--MD
Several studies have shown that lack of sleep can be just as bad (if not worse) on reaction-time and attention-span than moderate quantities of alcohol. Driving while chronically tired is basically as dangerous as DUI.
Now, if I worked 15 hours a day, that's a minimum of 17 hours that I'm not at home (1 hr commute each way). Add 1 hour to eat a meal twice a day , and I'm down to 5 hours of sleep. That assumes perfect time-allocation, no spin-down time to unwind, no time for showers, etc..
When someone gets killed because one of these workers falls asleep at the wheel after a week of this schedule, guess who is going to get slammed with the lawsuit.
- Simple HR-like questions (i.e. how do you handle deadlines, etc).
- Simple-to-moderate technical questions (i.e. why is it important to use parens in a #define)
- Brainteasers
It's the brainteasers that's where the 'okay' and the 'excellent' really differentiate themselves. The questions I ask have solutions... they take the typical person several days to work out. But I'm not interested in the answers, I just want to see how they think and attack the problem -- can they see the blind alleys? can they recognize when they don't have enough information? what sort of questions do they ask?Occasionally, I throw a curveball. "I see you have experience with the PPC architecture. What's your favorite PPC instruction?" You'd be suprised how many people answer that with "eieio, because it sounds funny". Which isn't a bad answer -- I wanted to see how they reacted to an unexpected question. Another candidate told me once that (for the ARM platform) the bit-invert function was good for writing highly-optimized bit-manipulation functions for banging away at hardware registers.
Through all of this, tho, you need to keep in mind their personality. Will they play well with the rest of the team? That's a difficult factor to judge, and I'm likely to cut a candidate some slack on this.
From the engineering side, products could/should have much better interfaces. The interface should just be more than a way to access every feature. It should present some sort of logical pattern. Part of that is trying to figure out how the product is going to be used (as opposed to should be used), and try to identify how your consumers are going to look at it.
As an example of this, consider the VCR. The basic functions for tape manipulation (play, stop, rewind, fast-forward) are generally on larger buttons and prominently labeled. Good design there -- of course, then they make the buttons needed to program the thing small and badly labled (dark blue text on black background!?!). The engineers failed to recognize that those buttons would be important to me.
On the marketing side, consumers are misled. The easiest way to get someone to identify a task as difficult is to convince them that it should be trivially easy and then make it just slightly more difficult than that. No matter how easy it is to do, if you've got people's expectations set to expect easier, the task seems impossible.
As an example of what I mean by this, consider the PVR marketing which tends to claim that the unit (regardless of who makes it) is just as easy to use as a VCR. That's a nice thing to say... and as someone who has owned multiple VCRs for more than 10 years, I expect something that is downright trivial to operate. Well, they aren't. Luckily I'm used to menus, 'selecting' items, and navigation keys from my experience with other devices... but my expectation (from the marketing) was set to 'extremely easy', and it wasn't.
In summary:
Matt
Each side is evaluating moves with a maximum time limit per move. If they make a decision sooner, that's fine. But if the time expires, they just take the best move they've found so far.
In theory, whichever side can evaluate more moves to evaluate the alpha-beta minimax tree to a deeper level within the time allowed _should_ win.
So, in effect, they are evaluating which side can look at more nodes/sec, but taking an average over the entire game, and reducing the answer to a one-or-the-other result instead of a numerical comparison.
Like most benchmarks, all it tells you is how well the benchmark ran. But, I have to admit, this is a pretty novel approach.