SoylentNews

Begun, this grand experiment is. We have had some whose feefees were hurt by moderation, which is strange, since moderation should be by definition moderate, or at least moderating. But maybe we have the opposite effect occurring. Not to say that the extreme views are prevailing, but the noise to signal ratio seems to be increasing. I must confess, bear with me here, that I actually used the "disagree" mod, to disagree with someone objecting to the "disagree" mod. Perverse, yes. Uncalled for? I think not! Mod me the same if you disagree!

But all this belies the dysfunctional state of debate (or the more polite term, discourse) in America. Yes, I specify America, as in the United States of, because of the rank corruption of political discourse by the one percent, combined with a uniquely American anti-intellectualism that discounts scholarship, research, learning, schools, teachers, and basically anything that requires some effort to understand. Americans are lazy. Unfortunately, they have added scared to the repertoire. But I assume that Soylent News includes more than cowardly Americans who have to run of to former Russian Colonies.

So, topic of the day: Faith. Do you believe that free and unfettered argument will get us all closer to the actual truth? Or do you reject the same because of the possibility that your position will lose the debate?

This is just in case it doesn't make it out of the submission queue:

As has been broken recently by several other sites, the US Congress has passed a new bill authorizing continued surveillance activities for the coming year. While budget bills of this type usually fly under the radar, this law has some very interesting sections (text formatting partially taken from https://teksyndicate.com/forum/policy-tech/stop-hr4681-aka-stop-1984/190906) :

        SEC. 309. PROCEDURES FOR THE RETENTION OF INCIDENTALLY ACQUIRED COMMUNICATIONS. (a) Definitions.--In this section: (1) Covered communication.--The term ``covered communication'' means any nonpublic telephone or electronic communication acquired without the consent of a person who is a party to the communication, including communications in electronic storage. [...] (b) Procedures for Covered Communications.-- (1) Requirement to adopt.--Not later than 2 years after the date of the enactment of this Act each head of an element of the intelligence community shall adopt procedures approved by the Attorney General for such element that ensure compliance with the requirements of paragraph (3). (2) Coordination and approval.--The procedures required by paragraph (1) shall be-- (A) prepared in coordination with the Director of National Intelligence; and (B) approved by the Attorney General prior to issuance. (3) Procedures.-- (A) Application.--The procedures required by paragraph (1) shall apply to any intelligence collection activity not otherwise authorized by court order (including an order or certification issued by a court established under subsection (a) or (b) of section 103 of the Foreign Intelligence Surveillance Act of 1978 (50 U.S.C. 1803)), subpoena, or similar legal process that is reasonably anticipated to result in the acquisition of a covered communication to or from a United States person and shall permit the acquisition, retention, and dissemination of covered communications subject to the limitation in subparagraph (B). (B) Limitation on retention.--A covered communication shall not be retained in excess of 5 years, unless-- (i) the communication has been affirmatively determined, in whole or in part, to constitute foreign intelligence or counterintelligence or is necessary to understand or assess foreign intelligence or counterintelligence; (ii) the communication is reasonably believed to constitute evidence of a crime and is retained by a law enforcement agency; (iii) the communication is enciphered or reasonably believed to have a secret meaning; (iv) all parties to the communication are reasonably believed to be non-United States persons; (v) retention is necessary to protect against an imminent threat to human life, in which case both the nature of the threat and the information to be retained shall be reported to the congressional intelligence committees not later than 30 days after the date such retention is extended under this clause; (vi) retention is necessary for technical assurance or compliance purposes, including a court order or discovery obligation, in which case access to information retained for technical assurance or compliance purposes shall be reported to the congressional intelligence committees on an annual basis; or (vii) retention for a period in excess of 5 years is approved by the head of the element of the intelligence community responsible for such retention, based on a determination that retention is necessary to protect the national security of the United States, in which case the head of such element shall provide to the congressional intelligence committees a written certification describing-- (I) the reasons extended retention is necessary to protect the national security of the United States; (II) the duration for which the head of the element is authorizing retention; (III) the particular information to be retained; and (IV) the measures the element of the intelligence community is taking to protect the privacy interests of United States persons or persons located inside the United States.

IANAL, but the above has serious implications for data collection and communications. As far as I can tell, all communications that take place over encrypted streams (like https), or that has been signed off on by the same people doing the data collection, can be retained indefinitely. All other communications can be retained for five years. While there was a White House petition to stop it (https://petitions.whitehouse.gov/petition/protect-our-privacy-and-please-veto-hr-4681-aka-intelligence-authorization-act-fiscal-year-2015/lln5hN5c), there are fewer than 10,000 signatures at the time of this writing and the bill has been passed.

The slashcode seems to make it's own mind up who my friends etc should be. I've not added ANYONE to any of those groups. Odd . . .

It is my impression that a significant number of the people who frequent this site use some *NIX operating system, whether it's GNU/Linux/Potternix/LinuxWithoutTheGNUinFront, *BSD, or Apple's Shiny Bastardized BSD (tm). As such, it may seem a bit odd that I, someone who enjoys bashing Windows at every opportunity, would allow it to share my computers with *NIX-based OSes. Like a lot of people in the same situation, I use Windows primarily as a gaming OS/general fallback in case Wine can't emulate it well enough.

To be honest, I don't hate windows. Rather, I think that it's a crusty mess that has gone from being a fairly nice OS to a usability and productivity nightmare. I have listed the Windows versions that I have worked with as well as my thoughts on each.

Windows Pre 3.0: I find that these were interesting environments in and of themselves. While they were clunky and primitive compared to later versions, they provided a means by which people could run multiple DOS programs at the same time (since there was barely any Windows software). Interestingly, Windows 1 and 2.x programs can still run on modern versions of Windows with minimal modifications (http://toastytech.com/guis/misc.html).

Windows 3.x: I actually like these versions of Windows! When you run them on stable hardware, they aren't really all that crashy. The instability that you likely experienced in the '90s may have actually been because hardware compatibility was "meh" at best. To me, 3.x actually has a nice GUI, as the button on the top left of each Window acted as a menu for very clearly laid out actions. The only real problems were that it was slow, had an absurd learning curve, and was 16 bit despite being released in an era when the 386 and 486 were really beginning to take over.

Windows 95: For many people this was My First Preemptively Multitasked OS. When you consider the fact that it can run DOS and 32 bit software side by side, '95 was actually pretty impressive. I have heard that there were serious compatibility problems despite this, however '95 is clear to be as being a definite step forward. It marked the introduction of the Explorer graphical shell, Start Menu, Task Bar, and basic window layout that would be a staple of the OS until Microsoft threw it away in 8. Each of these additions were massive leaps forward not only for UI design but also true usability studies. The Start menu provided an intuitive and easy starting point for users unfamiliar with computers at the time. The function over form nature of the OS is also very striking to me, as it lends itself to actually getting things done, which tends to be what computers are supposed to do.

Windows 98: A generally more stable if not heftier version of Windows 95. This was the first OS I ever used (95 was my second). This was also the first version to feature IE as the main desktop UI, which was a major problem at the time but gradually got subdued as the years went on. The fact that people could get mad about integrating software seems peculiar to me now, however at the time users actually exerted control over their systems. Users were in charge, not the OS or the vendor.

Windows 2000: This is by far my favorite Windows OS. It's small, fast, and dead reliable (I have never had a BSOD outside of a driver problem). To me it's a shame that it got eclipsed by XP, as it has a very clean default UI with sensible defaults. This was also the last version of Windows to really respect the user's control over the system.

XP: Where do I begin? I am one of the few people who hate Windows XP with a passion. I think that it has to do first of all because I didn't use it until 2008 when my family got a netbook as a stopgap replacement between a Pentium III running '98, a Core 2 laptop running Vista, and an i7 860 with Windows 7. XP to me was a slow, unreliable OS riddled with usability and design flaws. Compared to the sleek, modern looking Vista, XP seemed like some sort of child's toy. It was also the first version of Windows to have activation. That in and of itself really should've ruined its reputation right there. 2000 has a very similar kernel and feature set, yet it doesn't require you to re-activate and get hassled by Microsoft if you make a hardware change.

Vista: My 2nd favorite Windows. I really don't see where all of the hate for Vista is coming from to be honest. In retrospect, the "Vista Capable" branding campaign was despicable, but that was mostly Intel's fault (http://arstechnica.com/gadgets/2008/03/the-vista-capable-debacle-intel-pushes-microsoft-bends/) Also, to be honest, as long as it is given a reasonably good computer (not some POS purchased in 2000), Vista runs quite nicely. There's also the matter of Vista's UI. I still find it to be sleek and nice looking. It pulls off the glass aesthetic in a way that Mac OS had had for a while by that point without going completely overboard. I can tell that it was a well designed if not a little rushed OS that was pretty much completely fixed by SP1.

7: A big round meh to 7. I don't see it as the miracle savior to right Vista's wrongs. Instead, it's more of a point update to Vista, fixing its minor problems like IO speed and such while fixing the brand name. I will say that the new taskbar is a horrible design decision. Instead of keeping it as a low-profile (increasingly important as 16:9 displays were adopted) and including text (for quick identification of each program), Microsoft decided to toss its prior UI research to the wind and wing it. It should also be noted that in Vista, when in classic mode the control panel works almost identically to the 95/98/2000/XP one (in that it flipping works!), while in 7 it has become a terrible web-ified mess.

8: Utter crap. There are no words that can better describe the UI mess that is 8. Rather than making a useful, general purpose desktop OS, Microsoft decided to pander to the tablet market in the wake of PC sales finally stabilizing to where they really should be. Here we have a non-discoverable child's toy masquerading as a serious OS. Tacked on are several useless "apps" that merely waste space in addition to a Windows Store so full of useless s*it that it would make a sewage treatment plant overflow. Gone is the useful start menu, instead replaced by the blatantly misnamed "charms" bar and a start screen for those who are too incompetent to read. Rather than continuing in the pleasant Vista/7 aesthetic or allowing users to revert to the tried and true 9x UI, Windows 8 treats its users to vast swaths of pastel colors. It honestly seems to me as if all of the actual artists and UI designers were replaced with a heap of douchebags masquerading as useful human beings. Windows 8 has no artistic value. The entire UI is simply a paintbucket fill mess.

8.1: I don't know how, but Microsoft manged to make 8 even worse! Now it's slightly more difficult not to get sucked into the hole that is having a Microsoft account.

Technical Preview: Imagine Windows 8 with a terrible, slow, buggy start menu that insists on automatically searching for every term with Bing and the Windows Store. Also add useless search and task view icons to the task bar and you have just pictured Windows Technical Preview. Technical Preview really is designed to be a privacy-free OS from the ground up and I sincerely hope that it doesn't replace 7 in adoption numbers. A clear message needs to be sent to Microsoft that users want competent UI design and privacy above all else.

Keep in mind that these were just my extremely opinionated impressions. I'm willing to hear out what you folks have to say!

So, one thing I do on Linux a lot is run loopback containers with encryption - this gives me a simple way of isolating data out and transferring it between machines without worrying about full disk/partition encryption.

How to do this on Linux is covered in places like this.

How to do this on BSD doesn't seem to be covered as well - so my best guess for loopback devices is below, culled from various sources.

It's a WIP, fairly untested as is, I have no idea how secure this actually is, the instructions are prone to editing, and if you actually use it for anything you're insane :)

First off a plain loopback

# Plain loopback device
dd if=/dev/zero of=tmp.dat bs=1024k count=1024

mdconfig -l
## The number we use for "-u" is the first number not in the list,
## using "0" here
mdconfig -a -t vnode -f tmp.dat -u 0
bsdlabel -w -B md0 auto ## Probably don't need the -B here...
newfs -m 0 md0a
mount /dev/md0a /media/

## Then unmount with
umount /media
mdconfig -d -u 0

## And remount with
mdconfig -a -t vnode -f tmp.dat -u 0
mount /dev/md0a /media/

Now the encrypted version...

## Encrypted loopback, using geli
dd if=/dev/zero of=crypt.dat bs=1024k count=1024

mdconfig -l
## The number we use is the first number not in the list,
## using 0 here
mdconfig -a -t vnode -f crypt.dat -u 0

# Make a keyfile, passphrase it and associate with the device
dd if=/dev/random of=volume.key bs=64 count=1
geli init -s 4096 -K volume.key /dev/md0
geli attach -k volume.key /dev/md0

## Give us md0.eli - Have a Paranoia Moment
dd if=/dev/urandom of=/dev/md0.eli bs=1m

## And make stuff
newfs /dev/md0.eli
mount /dev/md0.eli /media

## Then unmount/disconnect with
umount /media
geli detach md0.eli
mdconfig -d -u 0

## And remount with
mdconfig -a -t vnode -f crypt.dat -u 0
geli attach -k volume.key /dev/md0
mount /dev/md0.eli /media

And making sure that persists

# Testing it....

mdconfig -a -t vnode -f crypt.dat -u 0
geli attach -k volume.key /dev/md0
mount /dev/md0.eli /media

dd if=/dev/random of=/media/test.dat bs=1M count=100
md5 /media/test.dat

## MD5 (test.dat) = "whatever"

umount /media
geli detach md0.eli
mdconfig -d -u 0
reboot

## Wait for it.... Log back in and....
mdconfig -a -t vnode -f crypt.dat -u 0
geli attach -k volume.key /dev/md0
mount /dev/md0.eli /media
md5 /media/test.dat

## and check the md5sum matched

After installing PC-BSD, I found that the computer (a Shuttle XPC from circa 2005) wouldn't make it past BIOS. Moving past this minor setback, I put the hard drive into a far newer computer (built last year from parts released the year before), and the installation continued.

At this point, I was asked the standard OS install stuff, like what my username is, etc. One change that will likely interest the Mint/Ubuntu users out there is that PC-BSD actually asks you for your root password. Any Debian users reading this will likely snicker, but I like the fact that the PC-BSD devs actually trust my competence enough (for better or for worse) to have complete control over my own computer.

Anyway, moving on from that, I found that the MATE system monitor was consistently reporting very high memory usage, and that the system would eventually grind to a halt after enough usage. In the name of fairness (and to try out ZFS raid on 4 80GB hard drives I had available), I decided to do a fresh reinstall on this machine with all default settings.

Needless to say, it worked. I find that the KDE 4 desktop that comes with PC-BSD by default should be a welcome relief for anyone sick of having GNOME shoved down their throat. The only problem is that desktop effects don't work yet, but I should be able to sort that out in time.

The Good:
1. It's fast. PC-BSD starts and stops far faster than Mint 17 did after being used for a while. I hope that it stays this fast after updates make their rounds though the system.
2. There's plenty of software to be had. I was able to install gcc49, LibreOffice, and Seamonkey (because Chromium and Mozilla's Chrome-alike leave a bitter taste in my mouth) from AppCafe.
3. It's far easier to pick up than FreeBSD due to the integrated package management and inclusion of X and desktop environments by default.
4. There's no SystemD in sight! In Mint, if you type "mount" at the console, you see that systemd actually has its own mount point. It's amazing how refreshing it is not to see that. Additionally, user management is D-free. As far as I'm concerned, the SystemD project can screw Linux as much as it wants. I'm sticking with a sane OS.
5. There's quite a bit of choice. See my discussion on the installation process and multiply that by 10.

The Annoying:
1. To set up SSHD took some manual configuration, but for most people it isn't a problem.
2. AMD graphics support is still in its infancy, but is expected to improve. For those of you with nVidia graphics, expect smooth sailing.

The Bad:
1. It comes with PulseAudio

One word: Whoooooaaaaaa.

I'm speechless. I really don't know what to say. I have NEVER been given this much choice in an OS install before. For those of you who are Linux users looking to try out a BSD, go for this one.

First things first: to get the install started, I first dd'd the PC-BSD disk image onto a portable hard drive that I had lying around. After plugging it into the test computer and starting, I was greeted with something familiar to quite a few of the people reading this: "Loading GRUB". Now, I have heard that opinions on GRUB are varied, however I have to say that I quite like it just by virtue of already knowing how to configure it.

After a bit of a wait (this was off a hard drive, so those of you installing from a DVD or slow flash drive will need to be patient), I was greeted with the installer program.

After a few prompts, I was met with a screen asking me what I wanted the computer's role to be. At first I was going to just click "Desktop" and be done with it, but then I saw that I had the option to customize the install. Seeing that there was no reason not to, I proceeded to do so. Needless to say, I was impressed. The installer listed out categories of options to choose from, like, which desktop environment you want (of something like 10 choices, including KDE, I picked MATE because I wanted to. This was in direct contrast to Debian, where you have to explicitly select one of a few desktop environments in the bootloader of all places, or Ubuntu where you basically have to pick an entirely different version of the OS from a few choices. I proceeded to check off the other options that I wanted, like Java and Chromium (Maybe with enough support, we'll see a Pale Moon port to *BSD).

Following this lovely first impression, I was greeted by a disk partitioning screen featuring several options for the amount of control I wanted over the whole process. Seeing that this was going to be the only OS on the machine, I went for the easiest option. So far, so good!

Once the installation had completed, I had the option of saving my specific configuration and settings to a USB device in order to install with the same settings again later on. That was quite nice of them, and I really appreciate that touch.

I'll keep you folks posted as I use the OS.

Since this is a fairly tech-oriented site, I've decided to post my most recent adventure in overclocking.

Where I work, there is a scrap parts bin that is occasionally emptied for recycling. For some reason, this summer I found two Athlon 64 boards (AM2 and 754) that someone had thrown away after removing the heatsinks from the chipsets. The 754 board came with an Athlon 64 3200+ and I had a spare 64 x2 for the other.

I managed to find some replacement stick-on heatsinks on Amazon so that the chipsets wouldn't burn themselves out.

The first step of this process was installing Linux Mint, as I have observed that it is far more stable than Windows when overclocking. Then in the BIOS, I set the core voltage to the max rated (1.55) to brute force stability for testing so that I wouldn't waste any time.

Benchmarks were obtained from HardInfo:

CPU Blowfish
2200 MHz 18.217
2420 MHz 16.639
2750 MHz 14.548
CPU CryptoHash
2200 MHz 69.457
2420 MHz 75.843
2750 MHz 87.045
CPU Fibonacci
2200 MHz 4.028
2420 MHz 4.701
2750 MHz 3.223
CPU N-Queens
2200 MHz 14.026
2420 MHz 12.865
2750 MHz 9.808
FPU FFT
2200 MHz 15.317
2420 MHz 13.218
2750 MHz 11.547
FPU Raytracing
2200 MHz 23.851
2420 MHz 21.389
2750 MHz 18.709

It appears that the talks of there being a debian fork are actually getting serious:

http://debianfork.org/

What say ye, soylent? (If only I had the time and energy to write an article about this *cough*)

Minor disclaimer; wrote this about a year ago, and Google will have changed some of the details - you didn't used to get anything about MISRA at all from the initial searches

You see, MISRA is symptomatic of the big problem with software development.

Go to Google. Type in MISRA; you'll see references to Misra C, links to the homepage, we'll wander over there in a moment. So far so good.

Now type in "MISRA Evidence" - see any evidence MISRA works? You'll find [2], and we'll chase that in a second, but basically - Nope. Maybe it's just buried; throw in "MISRA Evidence language"; nothing on the early pages - if you go through you'll find a nice set of papers from Les Hatton on safe language subsets[0] which review MISRA itself effectively but no hard data as to the comparative usefulness, and in fact seems to come squarely down on the side of "was useless, is now actively harmful" [0a, 0b].

Now, how about "MISRA peer reviewed research"? Nope.
"MISRA language peer reviewed research"? Wait... Oh, it's a press release. No data or citations. An offer to maybe give me a white paper, if I send them my email address. Bzzzzt
"MISRA C peer reviewed research"? Citeseer? The same problems.

The MISRA site (http://www.misra.org.uk)? A lot of offers to sell me Official Specification Documents, Training Programs and Tools. But actual evidence that MISRA works? Citations to peer reviewed journals? Raw data? Not So much.

Now, by digging around you can find a couple of evaluations of MISRA as a coding guideline, and you can find some studies which imply something like MISRA might be a net win when combined with other techniques [1], but no direct cost/benefit to say "if you invest X on MISRA compliance, you will gain Y".

The persistent might go back to the MISRA bulletin boards where somebody asked directly if there was any study to back up the effectiveness of MISRA[2]: In addition to opinions (but no evidence), one posting pushed the idea that the companies using it aren't publishing results because they "are not research places" and "are busy" making software. Imagine for a moment if your local Hospital came out with that one?

"We're feeding them mercury. We don't know if it works, but these people are just busy getting better, and we don't have time to do research. And Mercury is Shiny!"

And this isn't some shiny new niche development idea; It's been in widespread use for over 15 *years* There should be volumes of hard data here, from direct studies across multiple industries to toolset impacts to literature reviews to raw data and meta analysis. We should be swamped with this stuff, not digging through the fifth page of Google or Citeseer and offering up our email addresses for something that's maybe vaguely relevant.

So here's a hypothesis; Studies with actual, real world, hard published data show that:
* Language Pitfalls have a minor impact when compared to other issues[3]
* Defects are, at best, weakly correlated with specific language choices.[4][5]
* Defect rates have a curvilinear relationship to the number of lines of code, with a clear increase as program module size becomes large. [6]

So - MISRA attempts to resolve a minor issue by doing something which is not correlated with the problems it claims to solve and which results in higher SLOC and therefore pushes an increase in defect rates. (This indirectly agrees with the conclusions of [0b])

Is that true? Or could it be that MISRA actually works? Or is it ineffective either way? How much time should we spend on MISRA & associated tools? How much effort in training? How much of that time & money could be spent on other tasks & training? How effective would that time & expenditure be in comparison?

Until somebody collects actual hard data then I don't know, and you don't know. Even the people prepared to sell you tools and training don't appear to know, or at least won't say exactly how in public, (but then again, they make sure to get paid either way). Right now the only real analysis I can find says avoid it, and nobody is asking for anything better.

Why? Well, managers I've spoken to go for MISRA, because it's easy; You trust the claims, buy a spec, book training for a few coders, tick a box. Done. This is far, far easier than fixing the schedule, or locking down requirements, or trying to understand problems in the architecture, or recruiting better developers, or persuading HR to pay more for better developers, or resourcing adequately up-front, or any one of the vast number of other issues: They're hard to achieve, the returns are viewed uncertain, they're politically difficult, and will take too long anyway.

So we go with the Shiny, be it MISRA or Agile or New Language Framework of The Week, and wonder why we have so much information on casualties, but nothing on how well the Shiny works.

[0] http://www.leshatton.org/index_SA.html
[0a] Hatton http://www.leshatton.org/Documents/SCSC_MISRAv2.pdf
[0b] Hatton http://www.leshatton.org/Documents/MISRA_comp_1105.pdf
[1] Hatton & Pfleeger http://www.leshatton.org/Documents/IEEEComputer1-97.pdf
[2] http://www.misra.org.uk/forum/viewtopic.php?f=56&t=710
[3] Perry, http://users.ece.utexas.edu/~perry/work/papers/1010-DP-ms25.pdf
[4] Hatton http://www.leshatton.org/Documents/FFF_IEE397.pdf,
[5] Mayer http://mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/)
[6] http://www.developer.com/tech/article.php/10923_3644656_2/Software-Quality-Metrics.htm