csirac2

Ah, I should've thought twice about that - I'm not even attempting reproducible builds in my own work, but I've often seen my Dockerfiles have apt-get-induced shenanigans due to the particular day or half-broken mirror I happen to be running the build from.

NixOS is definitely on my list, although for different reasons (whilst I love using and babysitting Debian systems, orchestrating it is eating up time that could be better spent on something like NixOS).

That's a cool story! I've also had "are you sure you're qualified to do that" conversations when working in remote areas on drilling rigs... certainly character-building thinking you've only further permanently damaged some $60K+ piece of equipment, and possible rig down-time costing $30K+ per day, only to get it working in the end and save the day :-)

But just as a follow-up to my own post: after surveying the females in my family, they all seem to agree that "making stuff" is a male thing, because males all get the credit... I guess I was just ignorant when I wrote the above post.

It can be surprisingly difficult. Funnily enough moving from svn git in one project I know of probably did a lot of the necessary work to achieve this, by having to remove reliance on $SVN tags and pre/post-"build commits" which used to be a part of the release process.

It's an interesting use-case for Docker as well: you can ship the build environment (or its Dockerfile describing it) for people to run builds under the same env as the official released build.

That was my reaction too, but given all the reading of late I've been trying to do in order to understand WTF GamerGate is, I am reminded to start out by saying that we should be careful not to come across as questioning the validity of this author's experiences at all. I've read a few "GG" pieces written by men saying something along the lines of, "hey this sucks, but it's really not that bad WTF". Saying things that I could've written. For example, I get annoyed at the ALL OPEN SOURCE DEVS ARE ARSEHATS characterizations because I happen to have been involved in a few over the years which honestly haven't been this way. There, I tried to recruit (as did fellow developers) and offer commit access regardless of gender and (in at least one case I'm aware of) non-conventional gender identity. And we weren't code-snobs: this includes doc-only and other community contributors. But this was a "boring" project mostly maintained by $dayjob people, so perhaps all the obnoxious jerks found other havens. Additionally, as a white english-speaking male, perhaps I'm poorly placed to make this assessment and perhaps there were injustices that I just couldn't see as such.

Then there's the reactions to these (insensitive? ignorant?) pieces. The main take-home point I've learnt reading @freebsdgirl is: just because a few of us rich white english-speaking males have had a good old time and barely any insurmountable problems in our particular corners of the internet... is great, but completely irrelevant to the fact that a lot of women are disproportionately having a bad time.

Back to the article, I still feel compelled though to share just how odd it felt reading that making was a male thing. By the time I was 5, my parents' farm had failed - the next 10 years were a struggle for them, but for me it was a time that cemented my curiosity and creativity by having to improvise everything. I am forced to rethink this: if I was born a girl, what else could I have done with my time? Didn't my own father constantly find ways to express his view that real men didn't sit around all day on computers? Is it just a fluke that my younger brothers' girlfriends could weld better than me? And when we were 14, being shown by a girl I knew how the primer worked (she was fixing a routine blockage) on a quirky, ancient diesel stationery engine? Is being a rich white male warping my perspective that much?

There were terrible gender imbalances at the time. Some too depressing to write about. But being able to make, modify and repair stuff was a universal skill that I hadn't - until now - considered genderized.

My daughter loves helping me take apart and repair things, just as I did when I was her age. But now odd thoughts occur: were the girls I knew growing up so equipped with "maker" skills because we lived in a poorer area? Or was it the rural living? Perhaps both? If this is the case, does that mean my daughter will have fewer opportunities to pursue these skills without the same pressures I grew up with?

Cool! I've actually had a Virtex-6 ML605 eval board for quite some time now, gathering dust... I always wondered what the Synflow toolchain looked like, it seems quite expensive - perhaps I can dust it off for Cx :-)

It's been 10 years since I did much FPGA dev, but at the time I had a lot of fun in Celoxica Handel-C. Sadly I could never quite synthesize my project to the size I could achieve with Verilog. I seem to recall having the Virtex-II datasheets next to me when coding Verliog, not so much with the Handel-C so perhaps I never quite got the hang of driving the language optimally for the target device at hand...

My question is, to a layman like me - does Cx bring something to the table that other C-like HDLs missed?

Edit: I Also very much enjoyed a scheme-like HDL called confluence... Seems it fizzled out. Have any alternative HDLs stuck?

virtualenv appears to be a giant, epic work-around for... what exactly? Somehow, perl managed to achieve the same thing with the PERL5LIB envar. And did it in a far more portable, reusable and repeatable way.

I was invited to interview with Google in Sydney (site reliability engineer), but the salary range was less than I was already making in a much cheaper town (Canberra).

Arrogance is the right word... I got the impression they would prefer candidates who were bending over backwards to get in the door, and by asking about salary and relocation costs I clearly wasn't.

Edit: Then about 6 months later I took a job in Sydney anyway, at a 20% higher salary... Then took another paycut to go back to Canberra (Sydney is expensive!)

Well, I'm sure the creators of JSON weren't thinking of XML use-cases at the time. When it comes to solution-agnostic, self-describing, self-validating semantic markup, I'm not sure JSON-LD buys you much over RDF serialized to XML (for example).

A few years ago they mandated the inner-most 5mm or so of the active pins be insulated for that reason, so that by the time you have enough of the plug out to reach exposed conductor with your fingers it's disconnected. At least that's idea... and I can't tell you how much ebay junk is sold with the old "illegal" exposed active pins

I think woz is perhaps staring at a big bank of 3, 5, 10 and 20A fuses though. As mentioned in my other comment, experimental aircraft have a few different instrumented electronic circuit breaker solutions such as http://verticalpower.com/ which can integrate with the cockpit EFIS.

Well, amateur experimental aircraft have something like this available: http://verticalpower.com/ - but there's a lot of negative reactions to this kind of technology, because it introduces new failure modes where none previously existed before.

But I think something that people forget is that generally, fuses are there to protect wiring and fixtures (switches, connectors, etc) from fire. Preventing the device on the circuit that you, the user, cares about from completely melting down is just a nice bonus.

That's why building wiring codes generally spec fuses to cope with the capacity handled by wiring and switches, rather than the loads attached to it.

EDIT: In any case you NEVER want the car to silently and automatically try to "re-set" a tripped breaker, surely. You want this kind of fault to present itself noisily and obviously; it's a precursor to a potentially dangerous condition.

Any automatic re-set will have to factor in some cool-down time for the wiring in between attempts... what is the temperature of an overheating pair of conductors in the wiring loom when the breaker tripped? What rate of heat dissipation is there allowing them to cool down again? A wire which has experienced overheating will have a different (higher) resistance after the short-circuit event. Even if the wire isn't permenantly damaged, the temporary increase in temperature will still guarantee a momentarily higher resistance. Will the wire still have low enough resistance to trip the breaker again when the short is applied again?

It's been a few years, but the plant geneticists I used to work with until 2012 seemed to have to solve a lot of problems to get reliable full-genome sequences of de novo species (these have no reference assemblies to go by).

Including what I had until then assumed was the simple act of just sampling DNA material: multiple consistent sites on the plants were sampled and this context was important not just for gene expression, but overall sanity checking of final assemblies (speaking of sanity checks: flow cytometry as well). Then there was setting up Illumina and 454 sequencing experiments, which seemed to involve quite a few iterations/experimentation in developing primers, choosing bead configuration, amplification procedures and a whole lot of other stuff I don't understand...

And still, after all that, the literature did have a bunch of species that had already had a few genes sequenced using earlier methods and traditional PCRs, so the whole sample set was given this treatment as well, again as a sanity check and to get a strong reference to earlier results (1000+ of species, thousands of individual plants, each with multiple samples as I mentioned).

And still, after all that... the evolutionary history of this group of plants still looks slightly different depending on which genes you looked at.

And so now I know what a consensus tree is... and how much fun it is to see researchers have their software doing MCMC tree building run in just a few days on HPC compute clusters when they'd previously waited months :-)

No kidding; even my 2010 X61s had 8GB and my 2 year old X230 has 16GiB.

Typically I would agree with you, but I've worked on a lot of old codebases with extensive testing for deep scary private parts. A good example is some public method which does something seemingly innocent and useful, but in its guts calls a bunch of black magic to deal with different operating systems and configuration options.

For what it's worth, the perl object system was actually borrowed from Python, so perl code is full of $self (or $this) too.

Solr is something you can implement faceted search with, but I'm not sure what you'd want from emacs integration...

Faceted search typically helps you drill down to find a set of objects or other discrete entities; not really for searching within such an entity.

In other words you need to have a set of objects/entities that are already fairly well-structured or have reasonably coherent attributes on them from which to build the facets.

In the worst-case, a faceted search view of your computer's filesystem might only be able to show you facets based on datetimes (created/modified), filesize, filename extension, permissions etc. but nothing about the content of the files.

If you've drilled down to a collection of .mp3 files, your faceted search engine might then be able to offer facets based on MP3 tag data.

A good example is RS Components and Digi-Key. I can't pull one up now, but sometimes I find that these suppliers won't show you many facets until you've drilled down into a subset of their product range that has a common set of attributes - at which point you can suddenly filter by current rating, voltage, MTBF, etc. whereas at some broader category view you might only have brand-name, stock status and lead-time facets.

See down the left bar here: http://au.rs-online.com/web/c/semiconductors/processors-micr...

Wow, that's new - there didn't seem to be any low volume pricing info at all until now.

What a great list; I used this holiday season to build a similar list actually. Genode's potential is really understated in the post - it can apparently run a number of different microkernels including the formally verified seL4 which provides secure isolation of each individual driver, VM, or process. They seem to have some Linux interoperability going too. I really want to find the time to dig into this one some more.

Qubes is great, however the project really is a bit absolutist in my (amateur) opinion in placing all the trust in isolation: I still care about integrity of the isolated environments too, but Qubes seems to somewhat throw that baby out with the bathwater by, for example, insisting on passwordless sudo in all AppVMs.

I get where they are coming from - local privescs are a dime a dozen and they have a small team. Linux process isolation sucks but is it that worthless that we should deliberately introduce new vulnerabilities by leaving the doors completely wide open? When the skids find a new RCE in my crappy mail client or attachment viewer, the effort required to engineer exploits is massively reduced.

And accessibility to small business.

An amazing write-up. Although I am using my EE training a lot more at work these days, and I've designed my fair share of MCU (and USB, FPGA, analog...) projects I've never found the time to dip into learning even a fraction of the detail presented here on low-level modern x86 architecture.

For me, reading this really hammers home just how feasible evil maid type attacks really are (considering attacks aimed at defeating Eg. Full disk encryption). But at the same time, if I am still typing the passphrase for my encrypted disks at each boot, simply filming me use my laptop would seem easier... So using that logic, I have been working on passwordless unlock before fiddling with the very tedious task of maintaining a SecureBoot Linux installation.

Can anyone say how strong the x86/TPM-equipped machines out there are against malicious firmware updates, assuming one has their BIOS admin password set?

As a type 1 diabetic I can tell you that eating fat requires insulin commensurate with the energy it has. My own mental model of fat elevating my blood sugar level compared to other forms of energy is the rate at which it happens: somewhat slower than simple sugars, and much faster than complex carbohydrates.

Ah, so a little more arbitrary than I assumed. I initially hated perl when I first started with it, for what it's worth. I guess you've progressed beyond the point of finding [1] helpful (even if the perl looks a bit strange to me in places). And, apart from Moose I also miss perl's lexically scoped variables :)

It would suck to do numerical work without pandas though. I love pandas.

[1] https://wiki.python.org/moin/PerlPhrasebook

The thing about kerberized ssh that I've wondered, do you really want your kerberos session to open up ssh access to all the boxes in the enterprise you have an account on?

Why are accept headers next-to-worthless? I'm not heavily involved in front-end stuff these days but it's something I've relied on for years by now - admittedly not for image/media content, but still I'm curious.

In this specific use-case wouldn't plain old content-negotiation/accept headers work?

Although large organisations tend to have a goal of minimizing the number of languages and platforms they depend on, rarely does this turn out to be the case in practice. HPC systems in particular are expensive assets which could never justify themselves if they could only run one kind of workload in one particular language :-)

If I had to guess, you're working in a business unit that is heavily invested in perl and so sticking other stuff in that environment is perceived as an unnecessary future maintenance burden. The HPC system on the other hand is perhaps shared across multiple business units who don't have the exact same stacks as each other so it's flexible in that way.

python + pandas is pretty awesome though, I was able to delete thousands of lines old perl code dealing with irregular time series when I re-wrote with pandas - it made sense in that instance to ditch the old perl code, it doesn't always though.

Perl I think, if nothing else, shows a great example of how a language can evolve dramatically. You can almost date the code you're reading (or the programmer, or the age of the online tutorials the coder read) based on style of the code.

I've been paid to write perl in a team maintaining high-volume web properties and internal APIs for a large telco, and I also spent a few years in a Bioinformatics role which used it a fair bit at a national science agency (the research community in that particular corner of the discipline had some pretty awesome tools/libraries written in perl, but the full gamut of stuff we used also included ruby, python, R, C, Fortran...)

Just a few days ago I wrote how I missed Perl's Moose OO framework now that I'm doing mostly Python [1] [2], and that interestingly it's this that has prompted me to think more seriously about using a more strongly/statically typed language for large projects in future.

[1] https://news.ycombinator.com/item?id=8627143 [2] https://news.ycombinator.com/item?id=8627819

As someone who studied engineering I have to say my maths skills have only atrophied enormously since becoming a full-time developer.

Which is a shame, I see software sometimes that appears to have some special heuristics in there when I'm sure a standard statistical technique would've achieved the same or better result.

I have a theory that the info-sec industry would benefit from folks with robust stats/data-mining/"big data"/algorithms training (in a lot of ways bioinformatics people are solving similar-looking problems).

Edit: Yes, http://securabit.com/2014/10/03/securabit-episode-129-bioinf... said the same thing... :)

I was on a project a few years ago (first PoC with Mongo 1.2, started properly in 1.4, delivered with 1.8). Have the following things improved?

- RAM usage was a killer. For some datasets, key names took up more memory than values. - Throwing custom JS at mongo nodes was kind of fun, and we could do interesting stuff with it that we couldn't easily do on the previous (non-sharded) datastore. But out-of-memory situations in the JS runtime was less than graceful and caused mysterious replica breakage/hangs. Eventually it was suggested that we were using MongoDB in a way that wasn't typical or intended, which was fair enough. - We had trouble using it as a truly "schemaless" database (scientist users defining, maintaining, collaborating on their own data with object-level access controls and versioning): when you sort the result of a query (needed for paging), you either needed indexes (exploding RAM usage, finite number of indexes possible per collection) or if you could tolerate slowness (as we could) then you could use .limit() but it was hard to get the what-should-the-limit-be heuristic right, our object sizes varied wildly (sometimes exceeding BSON data size limit at times).

In another project we used MongoDB to back a read-only HTTP API representation of some 10s GiBs of reasonably stable and predictable external data, in that case it felt we were fighting it a lot less and it worked reasonably well.

I've also messed with eXist, Neo4j (which was fascinating) and a few other NoSQL things - at the end of the day I have to believe that for large sprawling heterogeneous systems (i.e. not the lone django web-app use-case) you will always want to keep authoritative data in something else and treat the NoSQL thing as a cache that can be rebuilt at any time.

Curating arbitrarily connected business objects in a graph (or having different codebases with slightly different understanding of the data mess with a given mongo collection) is infinitely harder than orderly relational tables, especially for the traditional DBA people who know how to read business process from a well-designed relational DB and likewise write such a thing by understanding those processes themselves quite well (something I didn't give them much credit for until a few jobs ago).