> Back when Unix was first becoming broadly used in private companies, want ads were filled with job offers for low-level unix sysadmin positions - all requiring experience with Unix and its tools that could only be met - if at all - by Ken Thompson, Dennis Ritchie, M. D. McIlroy, and J. F. Ossanna. B-)
And later, this occurred with Linux, NT, C++, Java, PHP,.Net, and it still occurs now. It's still very funny to me when a recruiter calls for a mid level position with 5 years of experience with a technology, and they don't realize that I'm one of the maintainers of the software. I do try to point out good candidates to t hem, if I know of any.
I'm afraid there's far more concrete evidence. Take a look at the video of the presentation by a law firm on how to hire H1B visa holders while skirting the edge of US law.: it's quite an infamous seminar.
I've dealt with employers who used such tactics. it's not the only reason to have an extremely specific resume: I've helped create job descriptions that were "wish lists" of job skills, lists that we knew we could not possibly afford if one candidate had them all. But we'd accept 3 out of 5 with demonstrated flexibility.
Where no one reports it, or prosecutes it, it's already being done. I've recently worked with educational facilities whose compliance with basic security practices for student and staff data is in "compliance" with EU law because they passed an audit, but the audit was basically a checklist they filled out. I refused to sign the parts of it that came to my crew, because the answers were lies, and submitted my concerns to their company and my company's lawyers and security managers. The education company was very, very careful to keep the auditors away from _me_.
They have changed their approaches to a number of the security issues I raised, but their own leaders did not know the security violations performed as a matter of common practice by their own staff, especially concerning student private data.
I'm afraid that you've already been trapped by starting out with a flawed assumption, that such a device would require explosives. Self-destruct drives already exist, from a company called RunCore, at http://www.runcore.co/en/ Their site seems to have been slashdotted, but it's an interesting approach for high seurity data.
I believe that the age discrimination you are referring to is described at http://www.law.cornell.edu/cfr/text/29/1625.5, and the actual code for federal employees is at http://www.law.cornell.edu/uscode/text/29/631. There is nothing in it that prohibits asking for date of graduation. Asking for it without need may cause "scrutiny", but the simple claim that "we verify academic credentials as a matter of course" works very well to cover that, and I've not heard of any company being scrutinized for asking in the last 10 years.
I've certainly met managers and hiring personnel in the last 10 years who discriminate on illegal bases. It's extremely difficult to prosecute, and such discrimination is actually _taught_ in legal seminars how to avoid prosecution for such discrimination. The most outstanding example was the "how to hire H1B applicants only" presentation at http://www.youtube.com/watch?v=TCbFEgFajGU&list=PL126DD55E0E6CD89B.
And working on projects that help people, or let you have a real life as well as program, or medical issues that limit your mobility. That can also be a reason for telecommuting. And one disastrous marriage or start-up company can take a 10 year bite out of your career path without difficulty. Also, expertise can be seriously obsoleted: how many "DOS" or "BeOS" or "Lotus Notes" experts have watched their expertise obsoleted?
This is one reason that they personnel departments ask for your college graduation date. Calculating age from that is pretty easy. Similar questions can be, and are, used to collect race, gender, religion, nationality, visa status, or medical issues that may affect your workplace behavior. This is true even in places that claim not to discriminate on these bases:, or where such discrimination is used illegally. Subconscious bias exists, even without directly citing it in the applicant review process.
As an older engineer, I've found that helping out the youngsters with their freeware and bringing lesons learned decades ago is rewarding, and professionally helpful. I can name at least 3 freeware or open source projects that I've been involved with for more than 10 years that get me recruiting calls from other countries. Very very few people have that much experience with it, my name has been in the developer mailing lists for that long, and I've done it as a matter of technical interest. Put those on your CV.
Also, companies that are migrating from older to newer platforms may welcome people who've worked extensively with both. As I've become older I've become the "local reference" for the older technologies. Simply having a hint of what the differences might be can same hundreds of man-hours of labor porting software or keeping the old system alive during the migration.
That is what off-site dropboxes are for. A timed release if coded, public transmissions are not received regularly would seem a basic precaution, and one that I'm sure Wikileaks could have helped him set up.
As a "serious network admin", most groups have little control over the critically necessary BGP handling of their upstream nework provider. Ones is't left your building, it takes considerable extra steps to track and verify the packets to ascertain the packets are being routed outside your upstream venror, or their colleague's, control. By the time you can get the evidence passed along to any party in any of those companies that can actually do anything about the problem, the attack is often already over, if not simply better concealed.
Unfortunately, BGP has been a necessary evil to _balance_ traffic in a dynamic network. It's also unfortunate that it is often deliberately manipulated, as a matter of corporate strategy, to avoid expensive but faster routes, or to manipulate competitor's traffic reports. The amount of business based manipulation of what was designed as a metric based feedback and tuning system means that it will not ever be used for "honest" routing. I'm afraid that any plan to sanitize the BGP tables will run afoul of business needs and wind up rejected.
Please forgive me for this, but I'm going to try to be logical for the education of other slashdot readers who have to think about real risks.
There are other means: the blood supply is one of them: I've even had injured people bleed on me, on open cuts. Many years ago, I helped a convulsing man who bit me and drew blood, and he was choking on blood from his bitten tongue. If he'd had AIDS, I'd have been at serous risk. It wouldn't have stopped me from helping him stop choking, but it gave me pause later when I thought about such risks, and I did wind up getting a tetanus booster shot.
Do you get transfusions or donate blood, or did you do so before the tests improved? Do you share needles, or have you had surgery where a surgeon accidentally cut their hand, even wearing gloves?
AIDS requires the exchange of intimate body fluids, but it can still happen by accident. And given how quickly it spread originally from a very "active" gay man, the risk of a surgeon accidentally infecting patients or a hooker engaging in unsafe practices is still a real epidemiological tracking reason to want to track the source of an AIDS cluster.
Also anyone who's got low blood pressure problems, or who needs so many IV's for medical reasons that they have veins fail. I've certainly had cancer burdened friends on chemo who've had veins become very difficult to find after they've had so many IV's and so many needle sticks for treatment. And with age, people's veins often become more frail and more likely to be damaged.
Expanding the weapons free perimeter to the edges of the airport, itself, is a massive increase in manpower and scanner resources. The existing checkpoints work, somewhat, by creating chokepoints in the flow of traffic, and restricting it to tocketed passengers who are actually boarding the plane. Expanding that border to the airport borders is multiplying the number of doors to control by a factor of 20, or installing new chokepoints that will interfere profoundly with the most casual of traffic.
It's what you refer to as the "add-on" that has me concerned. That "add-on" could easily multiply, by 10, the cost of the whole project, both in the costs of maintaining a secured perimeter and in lost revenues for the airlines and the airline shops.
The 1st amendment hasn't worked well, yet, for Wikileaks, for Edward Snowden, or for the services who've been encountering the Patriot Act search orders for the last decade. It's been very difficult to get the cases to court, since the evidence gathered has not been a matter of court records on which an appeal on constitutional grounds could be mounted.
> You don't have to publish the details of an intrusion.
What I'm trying to point out is that there are fiscal reasons not to publish, and you may be contractually blocked from publishing. I'm afraid that if you expect every ISP and service provider to give you enough information to know whether they're being open about intrusions, or simply sweeping them under the rug, you have a very op unrealistic view of most businesses. The only times in the last decade when I've seen a security break published to non-staff members of a partner company was when the resulting cleanup effort required users to reset their passwords. And while there are many breakins where doing such changes would be wise as a matter of course, most companies that suffer such intrusions simply do not bother to do so.
This is partly why regular password changes, and no plain-text password records are so critical: it's very difficult to know when an intrusion, detected or undetected, has occurred on some system that an attacker or thief has gained access to.
> However, upon discovering that my router has been compromised by persons unknown, there's nothing stopping me from raising a general alert with my customers.
Besides the lost revenue, the departmental embarrassment, and the NDA and security agreements at your workplace which prevent you from publishing this information, certainly. I've certainly been in the situation of being forbidden by management, or by software partners, from publishing the discovered security intrusion.
> There are more than a few ways to do reasonably secure check-in of whatever. Hat-check style, with lock boxes, for instance
Have you ever had to check all your metal in somewhere, and tools, for security reasons? Or because you'd be working near radiation or strong magnetic fields? I have: theft of checked in, locked down equipment is _rampant_ in many environments. These are legal firearms, for off-duty police, military, or people with concealed carry. The "just check them in a lockbox" is a proposal I've seen before, and it never works out well.
> LaTeX is just a text processing language. Your.tex file will not display anything correctly. It's a plain text file.
You've a good point. But PDF is also a text file: as is evident form opening PDF document with a text editor. Both need to be processed for viewing. LaTeX has an intermediate stage, a "DVI" file that is effectively an intermediate format, and can then be processed to Postscript, PDF, or other display formats. Writing the original document, and doing the layout work, in LaTeX is both safer and more reliable, than doing so with Adobe's feature filled PDF crafting tools.
The inherent instability of software that does not follow its own published specifications, the burdensome bulk and inherently insecure nature of the of the those "free" versions of those tools from Adobe, and the cost of the development tools for writing documents that provide those new features are all powerful reasons to avoid Adobe's tools. The point that you note that "it's a mess, I know", is a hint that there are fundamental issues with the standard.
That people "already paid for the software" is a common one, and understandable. But at some point, the continuing labor and testing and support cost of overly complex software accumulates to where it's actually much cheaper to discard it. I'm not certain where that point is with PDF, but there are certainly well-tested technologies that could take over the document display role.
Unfortunately, the "ISO standard" for PDF is not complete. What Adobe tools publish, and expect clients to use, does not actually follow the ISO. Interestingly, Aladding ghostscript and the freeware ghostscript releases seem to do a much better task of rendering standards compliant PDF.
I'm afraid your point has been lost. You pointed out that PDF was to display documents in the intended format, and I gave you 2 examples that work well and have for years. Your original point that other standards should support "forms, digital signing,... and any other feature PDF may have that people want to use" are not well supported in those tools I mentioned. But those features are precisely why PDF has become so difficult to manage, so dangerous in security terms, and so bulky in system resources to use. Simpler and safer tools for displaying document content, and for handling forms or embedded images, were available before PDF. It's the insistence on melding and merging them into one huge tool suite that have destabilized
It's hardly free: the ability to handle power fed back _into_ a generation system, safely, requires revisiting the design of the entier local power grid. Even if it was designed robustly, the safety checks themselves take time and cost money. It's difficult to find the citations, simple searches are buried in advertising for the cost of the home interface equipment.
There is nothing "rare" about needing to do maintenance on any electrical generation system. It should be an annual event, especially for an exposed external system. And such a checkout should certainly include a temporary disconnect form the power grid, system, in order to inspect and test the cutover systems themselves. And when those maintenance steps occur, they're not power company personnel. They're the home owner or whatever unknown service person they've contracted, not a known reliable power company engineer. This creates the kind of risk, and the need for over engineering at the power company, that a network engineer fails when people start connecting laptops to a local network. This engineering time is not free.
And clouds do not "reduce demand for electricity" on the short timescales that they will reduce power feeds from solar paneled homes. Air conditioners will not instantly be turned off becuase there is a cloud, nor will the air around building s cool instantly. A cut in solar power will also affect the uuploaded power _first_, before it affects the solar home owner's home usage, because such systems upload the _excess_ power. They're not providing consistent flows of energy. The result is some potentially very strange electrical feedback from solar homes to the power grid. "Strange feedbacks" can cause unanticipated feedbacks, especially when there are phase delays in the responses to the feedback. Predicting, and protecting against that, is a well known and generally solved problem for full scale power plants, but local power generation makes it far more complex.
Except that building in the necessary safety management, and power management, to deal with current coming the other way from your customers is not free. Clients with solar panels are unlikely to call the electrical plant and announce when they are disconnecting for maintenance. And clouds passing over an area can cause serious variation in the customer provided solar power, in highly variable fashion that affects whole neighborhoods of panels.
It's extra work to design flexible, robust systems, so it is hardly "pure gravy".
Slashdot Mirror
> Back when Unix was first becoming broadly used in private companies, want ads were filled with job offers for low-level unix sysadmin positions - all requiring experience with Unix and its tools that could only be met - if at all - by Ken Thompson, Dennis Ritchie, M. D. McIlroy, and J. F. Ossanna. B-)
And later, this occurred with Linux, NT, C++, Java, PHP, .Net, and it still occurs now. It's still very funny to me when a recruiter calls for a mid level position with 5 years of experience with a technology, and they don't realize that I'm one of the maintainers of the software. I do try to point out good candidates to t hem, if I know of any.
I'm afraid there's far more concrete evidence. Take a look at the video of the presentation by a law firm on how to hire H1B visa holders while skirting the edge of US law.: it's quite an infamous seminar.
http://www.youtube.com/watch?v=TCbFEgFajGU&list=PL126DD55E0E6CD89B
I've dealt with employers who used such tactics. it's not the only reason to have an extremely specific resume: I've helped create job descriptions that were "wish lists" of job skills, lists that we knew we could not possibly afford if one candidate had them all. But we'd accept 3 out of 5 with demonstrated flexibility.
Where no one reports it, or prosecutes it, it's already being done. I've recently worked with educational facilities whose compliance with basic security practices for student and staff data is in "compliance" with EU law because they passed an audit, but the audit was basically a checklist they filled out. I refused to sign the parts of it that came to my crew, because the answers were lies, and submitted my concerns to their company and my company's lawyers and security managers. The education company was very, very careful to keep the auditors away from _me_.
They have changed their approaches to a number of the security issues I raised, but their own leaders did not know the security violations performed as a matter of common practice by their own staff, especially concerning student private data.
I'm afraid that you've already been trapped by starting out with a flawed assumption, that such a device would require explosives. Self-destruct drives already exist, from a company called RunCore, at http://www.runcore.co/en/ Their site seems to have been slashdotted, but it's an interesting approach for high seurity data.
I believe that the age discrimination you are referring to is described at http://www.law.cornell.edu/cfr/text/29/1625.5, and the actual code for federal employees is at http://www.law.cornell.edu/uscode/text/29/631. There is nothing in it that prohibits asking for date of graduation. Asking for it without need may cause "scrutiny", but the simple claim that "we verify academic credentials as a matter of course" works very well to cover that, and I've not heard of any company being scrutinized for asking in the last 10 years.
I've certainly met managers and hiring personnel in the last 10 years who discriminate on illegal bases. It's extremely difficult to prosecute, and such discrimination is actually _taught_ in legal seminars how to avoid prosecution for such discrimination. The most outstanding example was the "how to hire H1B applicants only" presentation at http://www.youtube.com/watch?v=TCbFEgFajGU&list=PL126DD55E0E6CD89B.
And working on projects that help people, or let you have a real life as well as program, or medical issues that limit your mobility. That can also be a reason for telecommuting. And one disastrous marriage or start-up company can take a 10 year bite out of your career path without difficulty. Also, expertise can be seriously obsoleted: how many "DOS" or "BeOS" or "Lotus Notes" experts have watched their expertise obsoleted?
> Age on a C.V?! Who does that
This is one reason that they personnel departments ask for your college graduation date. Calculating age from that is pretty easy. Similar questions can be, and are, used to collect race, gender, religion, nationality, visa status, or medical issues that may affect your workplace behavior. This is true even in places that claim not to discriminate on these bases:, or where such discrimination is used illegally. Subconscious bias exists, even without directly citing it in the applicant review process.
As an older engineer, I've found that helping out the youngsters with their freeware and bringing lesons learned decades ago is rewarding, and professionally helpful. I can name at least 3 freeware or open source projects that I've been involved with for more than 10 years that get me recruiting calls from other countries. Very very few people have that much experience with it, my name has been in the developer mailing lists for that long, and I've done it as a matter of technical interest. Put those on your CV.
Also, companies that are migrating from older to newer platforms may welcome people who've worked extensively with both. As I've become older I've become the "local reference" for the older technologies. Simply having a hint of what the differences might be can same hundreds of man-hours of labor porting software or keeping the old system alive during the migration.
That is what off-site dropboxes are for. A timed release if coded, public transmissions are not received regularly would seem a basic precaution, and one that I'm sure Wikileaks could have helped him set up.
As a "serious network admin", most groups have little control over the critically necessary BGP handling of their upstream nework provider. Ones is't left your building, it takes considerable extra steps to track and verify the packets to ascertain the packets are being routed outside your upstream venror, or their colleague's, control. By the time you can get the evidence passed along to any party in any of those companies that can actually do anything about the problem, the attack is often already over, if not simply better concealed.
Unfortunately, BGP has been a necessary evil to _balance_ traffic in a dynamic network. It's also unfortunate that it is often deliberately manipulated, as a matter of corporate strategy, to avoid expensive but faster routes, or to manipulate competitor's traffic reports. The amount of business based manipulation of what was designed as a metric based feedback and tuning system means that it will not ever be used for "honest" routing. I'm afraid that any plan to sanitize the BGP tables will run afoul of business needs and wind up rejected.
Please forgive me for this, but I'm going to try to be logical for the education of other slashdot readers who have to think about real risks.
There are other means: the blood supply is one of them: I've even had injured people bleed on me, on open cuts. Many years ago, I helped a convulsing man who bit me and drew blood, and he was choking on blood from his bitten tongue. If he'd had AIDS, I'd have been at serous risk. It wouldn't have stopped me from helping him stop choking, but it gave me pause later when I thought about such risks, and I did wind up getting a tetanus booster shot.
You _give_ AIDS by donating blood, and already being infected.
Do you get transfusions or donate blood, or did you do so before the tests improved? Do you share needles, or have you had surgery where a surgeon accidentally cut their hand, even wearing gloves?
AIDS requires the exchange of intimate body fluids, but it can still happen by accident. And given how quickly it spread originally from a very "active" gay man, the risk of a surgeon accidentally infecting patients or a hooker engaging in unsafe practices is still a real epidemiological tracking reason to want to track the source of an AIDS cluster.
Also anyone who's got low blood pressure problems, or who needs so many IV's for medical reasons that they have veins fail. I've certainly had cancer burdened friends on chemo who've had veins become very difficult to find after they've had so many IV's and so many needle sticks for treatment. And with age, people's veins often become more frail and more likely to be damaged.
Expanding the weapons free perimeter to the edges of the airport, itself, is a massive increase in manpower and scanner resources. The existing checkpoints work, somewhat, by creating chokepoints in the flow of traffic, and restricting it to tocketed passengers who are actually boarding the plane. Expanding that border to the airport borders is multiplying the number of doors to control by a factor of 20, or installing new chokepoints that will interfere profoundly with the most casual of traffic.
It's what you refer to as the "add-on" that has me concerned. That "add-on" could easily multiply, by 10, the cost of the whole project, both in the costs of maintaining a secured perimeter and in lost revenues for the airlines and the airline shops.
So, don't waste the time and money on a system bound to be deeply flawed in execution due to budgetary limitations and civil rights issues.
The 1st amendment hasn't worked well, yet, for Wikileaks, for Edward Snowden, or for the services who've been encountering the Patriot Act search orders for the last decade. It's been very difficult to get the cases to court, since the evidence gathered has not been a matter of court records on which an appeal on constitutional grounds could be mounted.
> You don't have to publish the details of an intrusion.
What I'm trying to point out is that there are fiscal reasons not to publish, and you may be contractually blocked from publishing. I'm afraid that if you expect every ISP and service provider to give you enough information to know whether they're being open about intrusions, or simply sweeping them under the rug, you have a very op unrealistic view of most businesses. The only times in the last decade when I've seen a security break published to non-staff members of a partner company was when the resulting cleanup effort required users to reset their passwords. And while there are many breakins where doing such changes would be wise as a matter of course, most companies that suffer such intrusions simply do not bother to do so.
This is partly why regular password changes, and no plain-text password records are so critical: it's very difficult to know when an intrusion, detected or undetected, has occurred on some system that an attacker or thief has gained access to.
> However, upon discovering that my router has been compromised by persons unknown, there's nothing stopping me from raising a general alert with my customers.
Besides the lost revenue, the departmental embarrassment, and the NDA and security agreements at your workplace which prevent you from publishing this information, certainly. I've certainly been in the situation of being forbidden by management, or by software partners, from publishing the discovered security intrusion.
> There are more than a few ways to do reasonably secure check-in of whatever. Hat-check style, with lock boxes, for instance
Have you ever had to check all your metal in somewhere, and tools, for security reasons? Or because you'd be working near radiation or strong magnetic fields? I have: theft of checked in, locked down equipment is _rampant_ in many environments. These are legal firearms, for off-duty police, military, or people with concealed carry. The "just check them in a lockbox" is a proposal I've seen before, and it never works out well.
> LaTeX is just a text processing language. Your .tex file will not display anything correctly. It's a plain text file.
You've a good point. But PDF is also a text file: as is evident form opening PDF document with a text editor. Both need to be processed for viewing. LaTeX has an intermediate stage, a "DVI" file that is effectively an intermediate format, and can then be processed to Postscript, PDF, or other display formats. Writing the original document, and doing the layout work, in LaTeX is both safer and more reliable, than doing so with Adobe's feature filled PDF crafting tools.
The inherent instability of software that does not follow its own published specifications, the burdensome bulk and inherently insecure nature of the of the those "free" versions of those tools from Adobe, and the cost of the development tools for writing documents that provide those new features are all powerful reasons to avoid Adobe's tools. The point that you note that "it's a mess, I know", is a hint that there are fundamental issues with the standard.
That people "already paid for the software" is a common one, and understandable. But at some point, the continuing labor and testing and support cost of overly complex software accumulates to where it's actually much cheaper to discard it. I'm not certain where that point is with PDF, but there are certainly well-tested technologies that could take over the document display role.
Unfortunately, the "ISO standard" for PDF is not complete. What Adobe tools publish, and expect clients to use, does not actually follow the ISO. Interestingly, Aladding ghostscript and the freeware ghostscript releases seem to do a much better task of rendering standards compliant PDF.
I'm afraid your point has been lost. You pointed out that PDF was to display documents in the intended format, and I gave you 2 examples that work well and have for years. Your original point that other standards should support "forms, digital signing, ... and any other feature PDF may have that people want to use" are not well supported in those tools I mentioned. But those features are precisely why PDF has become so difficult to manage, so dangerous in security terms, and so bulky in system resources to use. Simpler and safer tools for displaying document content, and for handling forms or embedded images, were available before PDF. It's the insistence on melding and merging them into one huge tool suite that have destabilized
It's hardly free: the ability to handle power fed back _into_ a generation system, safely, requires revisiting the design of the entier local power grid. Even if it was designed robustly, the safety checks themselves take time and cost money. It's difficult to find the citations, simple searches are buried in advertising for the cost of the home interface equipment.
There is nothing "rare" about needing to do maintenance on any electrical generation system. It should be an annual event, especially for an exposed external system. And such a checkout should certainly include a temporary disconnect form the power grid, system, in order to inspect and test the cutover systems themselves. And when those maintenance steps occur, they're not power company personnel. They're the home owner or whatever unknown service person they've contracted, not a known reliable power company engineer. This creates the kind of risk, and the need for over engineering at the power company, that a network engineer fails when people start connecting laptops to a local network. This engineering time is not free.
And clouds do not "reduce demand for electricity" on the short timescales that they will reduce power feeds from solar paneled homes. Air conditioners will not instantly be turned off becuase there is a cloud, nor will the air around building s cool instantly. A cut in solar power will also affect the uuploaded power _first_, before it affects the solar home owner's home usage, because such systems upload the _excess_ power. They're not providing consistent flows of energy. The result is some potentially very strange electrical feedback from solar homes to the power grid. "Strange feedbacks" can cause unanticipated feedbacks, especially when there are phase delays in the responses to the feedback. Predicting, and protecting against that, is a well known and generally solved problem for full scale power plants, but local power generation makes it far more complex.
> It really is a big-time win for most utilities.
Except that building in the necessary safety management, and power management, to deal with current coming the other way from your customers is not free. Clients with solar panels are unlikely to call the electrical plant and announce when they are disconnecting for maintenance. And clouds passing over an area can cause serious variation in the customer provided solar power, in highly variable fashion that affects whole neighborhoods of panels.
It's extra work to design flexible, robust systems, so it is hardly "pure gravy".