Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Citation is a form of professional respect (Score 5, Insightful) 303

Perhaps it's because I'm an academic and my use of Stack Exchange relates to my research projects, but I'm having a hard time understanding why people would object to citing the source of a snippet of code. I have always cited and linked to the profiles people who were kind enough to help me with my code on Stack Exchange, not out of license obligation, but out of professional respect.

In academia, citing the work of others is commonplace. It's super easy to insert a comment in your code with a link. Putting the licensing and legal interpretations aside for a moment, why wouldn't you just want to do this out of respect for another professional?

Reply to This Share Flag as Inappropriate

Comment Rsync Script + Cron job (Score 1) 118

Rsync is simple, lightweight, has been around forever, and gives you incredible power. Assuming by "manage centrally from a console" you mean that you have remote admin access to all the computers in the scope, it's as simple as a cron job running your Rsync script. You can trivially make several versions for different use cases (Linux vs. PC) and only have to configure the setup once in the cron job. After that, you only need to touch it if you make changes.

Rsync can push deltas to any remote server you have access to via a wide range of protocols. The rest of your IT team will appreciate that you're only sending deltas and not sending full copies every execution and hogging bandwidth.

Here's a link to get you started: https://wiki.archlinux.org/ind...

Good luck!

Comment In Canada, term "engineer" is legally protected (Score 4, Informative) 568

In Canada, it's not so much a matter of programs "should not" as "must not" call themselves "engineers". The terms "engineer" and "engineering" are legally protected in all jurisdictions in Canada, much like the terms "lawyer", "medical doctor", etc.

Programmers who are not licensed professional engineers may not call themselves engineers. The computer science and computer/software/electrical/systems engineering programs at Canadian universities are very different. The engineering programs are accredited at the national level (http://www.engineerscanada.ca/accreditation-resources) to ensure a minimum standard of education for the practice of engineering. There are also post-graduation examination(s) and internship requirements (typically 4 years) prior to licensing. There is no such accreditation for non-engineering programming/related programs.

Further, programmers who are not licensed professional engineers may not do the work of engineers, even if they don't use the term. Many companies have trouble with this one. The definition of what constitutes engineering work can be found here: http://www.peo.on.ca/index.php... - For example, a programmer who is not a licensed professional engineer may not design the software controlling a self-driving car because life and safety are at risk.

Laws & regulations: (For Ontario, but similar in all Canadian provinces/territories): http://www.ontario.ca/laws/sta... & http://www.ontario.ca/laws/reg...

Comment Important part is ability to hop past fried switch (Score 1) 303

The important part of the described attack is its ability to hop past the fried switch, possibly more than one level, to affect devices elsewhere on the network, possibly hundreds of meters away. That makes it distinct from traditional ethernet killer or hammer attacks.

With about 15 minutes of research and looking at electrical diagrams and discussion with a colleague, I figured out exactly what device he's using. If I can figure it out, so can anybody. Out of respect for the author, I won't disclose it either, but I'm sure most of the Slashdot crowd could figure it out as well. The device in question is not expensive and is portable as he describes and has the right electrical properties to not fry the voltage shielding on the ethernet cables while being able to bridge circuit gaps in a sustained manner, as he demonstrates with the 4-5cm spark distance. It is also distinct from lightning strikes because of the variable duration of application and precision with which it can be controlled, which can result in more damage than a large burst of lightning.

With some tweaking, it is conceivable that a single ethernet port in an unattended area like a hotel lobby or university public area (both of which are common) could be targeted such that in just a couple of seconds, damage could be done to devices throughout the building, even devices not directly connected to the switch to which that ethernet port is wired. It's unclear how many hops are theoretically possible, but I suspect at least 2. Research in a controlled lab environment would be worth exploring.

That's a threat worth serious consideration. None of the network architecture in the many different places I have worked was ever designed with this sort of attack in mind; a fried switch was considered the worst possible scenario. This is much worse. At the very least, it should remind people that unprotected ethernet ports can be a huge risk and encourage them to improve physical security design.

Submission + - Sharing Lessons from Creative and Innovative Open Source Strategies (opensource.com)

celest writes: I shifted from engineering to study management because of my frustration that most problems related to the adoption of open source in organizations were not technical in nature. To curate some of the most important lessons from my research, I am editing a special issue of the Technology Innovation Management Review (http://timreview.ca) open access journal with the theme of open source strategy. The vision of the special issue is:

To showcase how organizations have actually implemented their open source strategies in practice, both to sharpen our theoretical understanding of how open source strategies work, and to provide real-world examples of the successes and failures of different ways of implementing these strategies. The intent is to highlight both the breadth of possible different open source strategies and to examine innovative models in more depth in order to better understand how they can be adapted to different organizations and different industries.

Opensource.com has generously showcased our call for authors and we welcome submissions from Slashdotters who have implemented creative open source strategies in their organizations.

Comment In Canada Engineers Are Required to Write the Code (Score 1) 664

In Canada, the public is protected from such software bugs by statute, in the same way the public is protected from medical screw ups: a professional engineer is required by law to write any software code where safety is on the line. Just like when a new bridge is constructed and must be designed and validated by a professional engineer who is an expert in structures and who becomes professionally liable for the project, the same is true for software. If safety is on the line, a professional engineer who is an expert in software and/or computer systems (as the case may be) must design and validate the code and they become professionally liable for the software. Unfortunately, too many companies ignore the law.

Source: Professional Engineers Act of Ontario (http://www.e-laws.gov.on.ca/html/statutes/english/elaws_statutes_90p28_e.htm ) and Professional Engineers Ontario (http://www.peo.on.ca/). There are similar acts and professional associations for all provinces and territories in Canada.

Full disclosure: I'm a professional computer engineer registered in Ontario with PEO.

Comment Illegal in Canada (Score 4, Informative) 405

It's worth noting that this action (auto-enroll and bill) is illegal in Canada. Each province/territory has its own consumer protection act that requires explicit opt-in for any new services that are provided to existing customers, in writing. You cannot auto-enroll people and require them to opt-out to not be charged.

Source (for Ontario, at least): http://www.e-laws.gov.on.ca/ht...

Non-legalese summary provided by the Ministry of Consumer Services of Ontario: http://www.sse.gov.on.ca/mcs/e...

Comment In Canada Professional Engineers Must Do The Work (Score 1) 100

In Canada, under the various provincial acts (and a National act that keeps them largely consistent), professional engineers (note, the word "engineer" is legally protected in Canada, like Medical Doctor or Lawyer, unlike in the US.) must do any work that involves human safety. That INCLUDES computer/technical related work. The classic example is software for air traffic control systems or software on space shuttle modules.

One of the problems for the engineering regulatory bodies (Professional Engineers Ontario - PEO - in the case of Ontario) is that many companies don't employ computer/software engineers even when their software involves human safety. They use computer science majors, or people with 1 year technical diplomas from the local college, or people with Microsoft or Cisco courses, or whoever happens to know whatever programming language they are using. The companies are legally required to have the work reviewed and signed off on by licensed engineers, but they just assume "oh, it's not like software is like a bridge or a building or something", so don't realise that the engineering priciples are no different than those used in structural engineering. Where it becomes even more fuzy is that the laws also state that licensed engineers must be used when "financial welfare" is on the line. Very few banking systems are properly designed by licensed computer/software engineers...

Source: I'm a professional engineer (P.Eng) registered in Ontario. Related legislation in Ontario:http://www.e-laws.gov.on.ca/html/statutes/english/elaws_statutes_90p28_e.htm - Professional regulatory body in Ontario: www.peo.on.ca

Comment Why is "monetizing" OS still = "clamping down"? (Score 3, Insightful) 168

Why is it that in 2013 the majority of discussions about generating revenue using a free/libre/open source strategy are still focused on "clamping down" and other zero-sum game thought patterns? Haven't we shown yet that there are not only strategies to generate revenue with open source that don't involve trying to control everything, but also that these strategies can be more successful in the long run? The type of "collision course" competition that the OP mentions is strategy thinking from the 70s and 80s. We're past that. We can do better.

I think a more interesting question to ask is: "How can Google generate revenue from Android while continuing to nurture the ecosystem and helping other stakeholders also continue to benefit from its success?". Facing challenging questions and trying to solve them is far more interesting than simply assuming that there is no solution, especially when anecdoctal evidence suggests otherwise.

Disclaimer: I'm doing my doctoral research in strategic management in the area of open source strategy, so my perspective is necessarily biased. Some of my work can be found at http://osstrategy.org/

Comment Real problem is estimated market size, not tech (Score 1) 160

The real problem is that pharmaceutical companies don't think there is a market for male contraceptives. It has nothing to do with technologies. There have been many effective, reversible, non-invasive procedures in human trials for the past 30 years:


The issue is that "most men" think contraceptives are "unmanly" and will "never take them". At least that's what several doctors have personally told me when I was investigating contraceptive options. Nothing will move forward until there is a (at least perceived) cultural shift towards the acceptance that males should be responsible for their own fertility, creating a (at least perceived) market to justify the large capital expenses required to finalize and make available the various drugs and procedures.

Slashdot Top Deals

Make headway at work. Continue to let things deteriorate at home.