Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.
Some interesting segments from the interview include: Snowden's assertion that mass domestic intercept is an "unreasonable seizure" under the 4th Amendment; that it also violates "natural rights" that cannot be voted away even by the majority; a claim that broad surveillance detracts from the ability to monitor specific targets such as the Boston Marathon bombers; him calling out Congress for not holding Clapper accountable for misstatements; and his lament that contractors are exempt from whistleblower protection though they do swear an oath to defend the Constitution from enemies both foreign and domestic.
These points have been brought up before. But what may be most interesting to these students is Snowden's suggestion that a defendant under the Espionage Act should be permitted to present an argument before a jury that the act was committed "in the public interest." Could this help ensure a fair trial for whistleblowers whose testimony reveals Constitutional violation?
As a result, engineers tend to favor redundancy for critical infrastructure like power networks, says Robert Farr of the London Institute for Mathematical Sciences. So Farr and colleagues decided to investigate which network structures are the easiest to repair. They simulated a variety of networks, linking nodes in a regular square or triangular pattern and looked at the average cost of repairing different breaks, assuming that expense increases with the length of a rebuilt link. ... They found the best networks are made from partial loops around the units of the grid, with exactly one side of each loop missing (abstract). All of these partial loops link together, back to a central source. ... These networks have three levels of hierarchy – major arms sprouting from a central hub that branch and then branch again, but no further. When drawn, they look remarkably like snowflakes, which have a similar branching structure.
What I'm looking for would be something like a Wiki with YouTube built in — make a playlist of videos with embedded links for certain job based tasks. And reuse and recycle those videos in other playlists of other tasks as they may be applicable. It would go beyond the actual IT we work with and would include things like, "Welcome to working in this department. Here are 20 videos detailing stupid procedures you need to go through to request access to customers' systems/networks/databases to even think about doing your job." I tried MediaWiki and Xwiki, and maybe I'm doing it wrong, but I can't seem to find a way to tweak them to YouTube-level simplicity for anyone to contribute to without giving up on the thing because its' a pain in the butt.
My only real requirement is that it not be cloud-based because it will contain certain sensitive information and I'd like it all to live on one virtual machine if at all possible. I can't be the only one with this problem of enabling many people to contribute and sort their knowledge without knowing how an HTML tag works, or copying files into something more complicated than a web browser. What approaches have any of you out there taken to trying to solve a similar problem?
We've been pumping out builds and publishing them as "Development Stream (Experimental / Unstable" and "Release Stream (Stable)", and this is visible on our support site to all. We had been also providing a link next to each build with the text showing the number of bugs fixed and the number of enhancements introduced, and the URL would take them to the Bugzilla list of issues for that milestone which were of type bug or enhancement.
This had been appreciated by our support and developer community, as they can readily see what issues are addressed and what new features have been introduced. Prior to us exposing our Bugzilla database publicly we produced a sanitized list of changes — which was time consuming to produce and I decided was unnecessary given we could just expose the "truth" with simple links to the Bugzilla search related to that milestone.
The sales and marketing team didn't like this. Their argument is that competitors use this against us to paint us as producers of buggy software. I argue that transparency is good, and beneficial — and whilst our competitors don't publish such information — but if we were to follow our competitors practices we simply follow them in the race to the bottom in terms of software quality and opaqueness.
In my opinion, transparency of software issues provides:
Identification of which release or build a certain issue is fixed.
Recognition that we are actively developing the software.
Incentive to improve quality controls as our "dirty laundry" is on display.
Information critical to 3rd party developers.
A projection of integrity and honesty.
I've yielded to the sales and marketing demands such that we no longer display the links next to each build for fixes and enhancements, and now publish "Development Stream (Experimental / Unstable" as simply "Development Stream") but I know what is coming next — a request to no longer make our Bugzilla database publicly accessible. I still have the Bugzilla database publicly exposed, but there is now only no longer the "click this link to see what we did in this build".
A compromise may be to make the Bugzilla database only visible to vetted resellers and developers — but I'm resistant to making a closed "exclusive" culture. I value transparency and recognize the benefits. The sales team are insistent that exposing such detail is a bad thing for sales.
I know by posting in a community like Slashdot that I'm going to get a lot of support for my views, but I'm also interested in what people think about the viewpoint that such transparency could be bad thing.