csirac2

It's why I try to deploy xen dom0s without any QEMU installed at all; reading through past xen CVEs was enough to convince me that HVM guests seem more exposed.. If anybody knows a writeup on what you might lose in terms of isolation and protection from guest escapes by sticking to PV, please do share

It's with those thoughts in mind that usually deploy Xen dom0s without QEMU installed at all (so only PV guests). You just have to read through past Xen CVEs to see that HVM presents a lot of attack surface, admittedly I'm unsure if PV is smaller but shallower (certainly you leak more info about dom0 to guests but for guest escapes it seems there are just a lot of opportunities with QEMU in the mix).

Biasing is indeed non-trivial, and most designs require temperature compensation to keep drain current constant. In fact, it's pretty easy to fry a GaN part without proper bias sequencing at power-on and off. At least it is with the parts I'm using.

Edit: parts like MAX881R [1] make it pretty easy though :)

[1] http://datasheets.maximintegrated.com/en/ds/MAX881R.pdf

I've been working with GaN parts for RF after being out of the hardware game for a few years. GaN was around but nowhere near as prolific as it is now. I thought SiC would have made more inroads than it has. GaN parts just seem incredible in every way (to someone like me at least) - amazing performance, efficiency, power handling in such a small package, more impressive impedance matching on wideband parts - it's just a shame the basic problem of harmonics still hasn't been whisked away by magic :)

Yes, we can argue that the content is less than perfect (are there really no permissible controls to get around 90day passwords, such as 2FA?), I'm just taking issue with the assumption that this is a conspiracy designed to line the pockets of QSAs (it's news to me that they provide zero feedback and business value - but then I'm not so close to PCI stuff).

Edit: I'm sure I've read that PCI 3 wasn't written in a vacuum - surely there is some trend in the data that's not visible to us that prompted the 90 day password thing (keyloggers for one, certain POS manufacturers using the same default passcodes on all their products for over 20 years another).

Woah. Precisely the reason that card networks and issuers have been so lax previously is that they want consumers and issuers to use their damn cards. Being painful to use for merchants and consumers is incompatible with that. Until now losses were small enough... Now, PCI assessment industry is such a profoundly small thing next to the losses and risk carried by issuers - let alone the sheer core business volumes at stake here - forgive me for feeling skeptical that the reasons for this security bump are anything other than stakeholders wanting to stem losses and reduce risk.

I had to abandon my reading before I reached the end, I was too angry at the disgustingly sloppy referencing. In particular his second paragraph put me in a bad mood straight away:

> In order to fill these gaps, a storage solution or a backup infrastructure of fossil fuel power plants is required -- a factor that is often ignored when scientists investigate the sustainability of PV systems.

Um. Pardon? Either he's having an argument with himself, or he's reading some pretty lame journals. Or is he just confused? Let's see:

> Obviously, this strategy requires a backup of fossil fuel or nuclear power plants that step in when the supply of solar energy is low or nonexistent. To make a fair comparison with conventional grid electricity, including electricity generated by biomass, this "hidden" part of the solar PV system should also be taken into account. However, every single life cycle analyse of a solar PV ignores it. [3, 2].

Yeah, okay. That's a perfectly debatable paragraph. So let's see the science behind the claim: [2] has nothing to do with anything! It addresses energy storage, but is not about energy storage; and it does NOT claim to be a literature review, nor does it claim to reference "every single life cycle analysis". Am I missing something? Is this citation of "[3, 2]" supposed to represent the entire sum of human scientific knowledge on this matter? Am I an idiot? Surely I'm the idiot, I didn't waste my time reading this article - that point must be shooting straight over my head!

Okay, let's read the paper. It's on energy payback/cannibalism - a logical presentation from what I skimmed - but is absolutely focused on the energy life cycle analysis of a whole technology experiencing rapid growth - Eg. nuclear back in the day - whereby the energy invested to rapidly establish new technologies may be greater than or at least massively offset any efficiencies (or indeed, "zero emissions") they may have over existing (think "sunk cost") incumbent energy production.

Which has nothing to do with central thrust of this article which seems to be that we should point and laugh at all those idiot scientists who forgot that the sun disappears each night!

But this writing forgets one thing - who is saying that PV (or wind for that matter) can replace established baseload power generators in a 1:1 swap?

Nobody sane, that's for sure. So I'll give you a hint: it's electricity buyers. They don't give a damn that they're destroying the planet by using PV solar, the fundamental fact is that in countries like Australia, even though you seemingly can't swing a cat without tripping over high-grade thermal coal ideal for cheap power, we pay among the highest electricity rates in the world. It's that kind of corrupted and/or government-regulated inefficiency that is the only thing to blame for the fact that PV solar can compete at all, even when subsidies are withdrawn.

I can't keep reading.

To be fair I have this problem on Debian too. Sometimes there is foo-nox, the foo version without X dependencies, but I seem to find myself building such packages for myself to omit some afterthought GUI bit which drags in Qt, gtk, or half of the gnome universe for no reason.

Shared code is the only sane way to manage secure systems. Not only do I not want to wait 6 months for an lzo or libpng RCE to be fixed separately in 28 different pieces of software (some are no longer maintained so I'll have to wait for a kind package maintainer or modify/compile/distribute myself), I also don't want the job of finding which of my software constitute the list of programs making my system vulnerable and require this attention - or don't, if they've already been fixed (how do you check?).

Performance and disk space have almost nothing to do with why we use shared libraries, IMHO.

Also in this space: https://github.com/ricochet-im/ricochet - seems to have some pretty notable people involved.

Really? Last I checked there was no BIOS support to recognize them and Intel was only giving support for embedded CPUs. Ta, I'll have a look

Ok, except... Well I can't help but think that if they can create a crazy unicorn land of negative interest, surely by comparison the monetary policy option of keeping the mint idle would be a would be a walk in the park...

I'm pretty sure that's Ubuntu's fault :)

I'm typing this on an X230, with 16GiB RAM. I busted the screen recently and considered an X250... it's such a shame that "ultrabook" means "one DIMM slot" these days, i.e. they max out at 8GiB RAM - same as I was using in '2009 on my old X61s!

Luckily replacement screen parts are quite affordable these days. And before anyone complains, I do use all this memory, currently dom0 has 4GB free.

Yeah, but this article makes no sense for another reason: hardly any of the money supply is actually made up of cold hard cash! Less than 4% according to these 2004 stats: http://www.frbsf.org/education/publications/doctor-econ/2004...

We live in shitty knee-jerk reactionary times, but did anyone else see his tweet at the time? At best, it seemed in poor taste. At worst, the outcome seems depressingly predictable.

I don't know what I'm trying to contribute here, except that whilst I have no problem with EFF working on this, their article here seems overly shrill and over-reactionary at how shrill and over-reactionary the airline was in their response to what (admittedly, in hindsight) could have easily been interpreted as a threat by an over-zealous corporate drone blind to smily-face emoticons.

Something that bothers me is (seemingly) widespread use of passphraseless ssh keys or, using ssh-agent without a timeout setting (so your keys are always loaded). I have to wonder if part of this is because ssh-agent -t starts the timeout clock for automatically unloading keys from whenever the agent was launched, rather than resetting the clock at each signing operation (which would mimic the familiar sudo behaviour).

This makes using ssh-agent with a reasonable timeout incredibly painful.

So you're left with either reentering your passphrase every 5/10/15mins, or basically never. Using smartcards for humans and TPMs for servers is a step in the right direction, but it seems ssh-agent is still missing this basic functionality - or am I missing something?

Hrm, I'm pretty sure I'm not alone in the Java/C cohort around ~2004-2006 who discovered Ruby/Python and friends and felt.. liberated. Java 1.3/1.4 was so thoroughly completely awful and unproductive, I'm quite sure the uptick in dynamic language popularity was a reaction to that.

Funnily enough, it's the few years of Perl+Moose I've done since which has made a switch back to python just over a year ago a bit hard to stomach. Now that I've tasted something resembling an expressive type "system" (however narrow, incomplete and warty it is), which encourages immutable objects, and does so in a very painless and idiosyncratic way - while still bringing many of the benefits of declarative/"up front" programming for free - I really, really miss it.

So of all the things that could have made me realize I've had enough of dynamic languages, it certainly feels odd that a Perl OO bolt-on would show me a glimpse of what I've been missing out on. And even weirder that the closed-mindedness of the average pythonista made up my mind to move on.

"However, all practitioners in data science and statistics would benefit from integrating Bayesian techniques into their arsenal" - that this wasn't already the case is news to me. Perhaps bioinf is less mainstream than I thought.

A few countries already do this around the EU - Latvia, Czech Republic: http://www.ica.cz/Get-ZEP-package

That's an important distinction, thanks.

Mary L Boas "Mathematical Methods in the Physical Sciences" [1] has absolutely been my favorite and most-used maths text in the 9 years since graduating uni. It's like a reference manual of just about all the non-CS (i.e. continuous/non-discrete) mathematical techniques required in my career. Highly accessible. It's a little too terse in places but I prefer this style of presentation over the insane long-form verbiage in other books I've since discarded which can make even simple topics seem overwhelming: the "Boas" book gets right to the point.

Edit: Calling it a mini-TAOCP of most of the maths needed for physics/EE work might be a bit of a stretch, but I've yet to see another maths text that does better as a highly readable, self-contained and compact reference.

Edit2: I moved house once and thought I'd lost my copy from university. I eventually found it, and yes, I have two copies... It's that important to me for brushing off the things I've forgotten :)

[1] http://www.amazon.com/Mathematical-Methods-Physical-Sciences...

Make sure you have wheezy/security as well. The vuln tracker often indicates issues fixed in wheezy/security iceweasel packages a lot more quickly than wheezy.

The mint packaging of the real Mozilla Firefox (tm) works for me, on jessie at least.

You should have iceweasel 31 according to https://packages.debian.org/wheezy/iceweasel

Which websites refuse to work?

You could always just add the linux mint repositories and install the real firefox that way. http://superuser.com/questions/322376/how-to-install-the-rea... is old but the instructions in the top-rated answer still work.

It's a strange title, given that towards the end it seems more like he's recommending to not bother migrating from bcrypt to scrypt (if you're already using bcrypt).

But now I'm curious: the author states that neither scrypt or PBKDF2 are really designed for password storage. Can anyone explain how a construction designed for this purpose would differ?

Edit: I get that one of the goals for a KDF is to securely hash/expand a short input (password) of N bits out to something potentially >> N bits; and in the case of scrypt, do it in a way that's expensive for bruteforcers but acceptable for authentication.

Is the reason scrypt/PBKDF2 aren't for password "storage" simply because they're not usable as such OOB (missing salt handling which bcrypt gives you for free?)

That's fascinating. But what was the modulation scheme? What was the printing mechanism? Achieving this, stand-alone without user intervention in a 100% analogue system sounds like a story worth a bit more technical detail..

It was a bespoke build system but this aspect of it was similarly "wrong". IIRC pre-build commit, yes, was version-number related. It also gathered issues fixed in the release being built and updated change logs/release notes/upgrade info documentation automatically. IIRC the post-build commit helped confirm in the commit history that a particular build for release x.y.z was successful and the version number can now be incremented (occasionally it took multiple attempts for the release manager to build successfully). Of course, one could go through the tags but most of the developers liked seeing release management stuff in trunk/release branches.

I didn't mean to criticize SVN as being inherently incapable of reproducible builds (if anything that's harder to achieve with git, especially with hacks like I've listed above), but the act of cleaning up the SVN repos and preparing for migration to git where a lot of our old SVN (and RCS!) habits would be problematic, also seem like the same kind of housecleaning you'd need to prepare for reproducible builds.

Thanks for sharing, that sounds great. Do you have a GitHub/bit bucket/etc. account I could follow?

I've found myself automating Debian/kernel/boot loader/libs/app stack packages for some ARM hardware for which I'm an app developer. This is due to the outrageous situation of COM module vendors (and/or SoC manufacturers) thinking that kernel 3.0 and horribly ancient/unsupported/unpatched userlands are acceptable in 2014/2015.

I run our .deb builds (and final debootstrap) in a bunch of docker containers, given that xapt/debcross toolchain has some stuff that, although these are awesome in themselves, still have some quirks when building stuff with awkward/complex dependencies and require a lot of hand-holding normally. So dockerizing the build env makes my life easier (some of it still has to be done from arm native chroot via qemu+binfmts). I use Jenkins to automate and integrate with the rest of our build tools but make files work too.

The /etc/passed et. al. copying from host is definitely the wrong thing to do in my circumstances as well; it's curious the various failure modes chroot builds can have.

I'm interested! I actually have had to work around the /etc/{passwd,group} shenanigans for other reasons, interested to see what you did there.