143 karma · joined March 10, 2009
Systemtap probes are available to eBPF instrumentation, so in that sense this does indirectly use eBPF. I know this isn't obvious, I haven't had a chance to get the docs up to my standard.
In fact I went to great lengths to ensure that the eBPF tracing tools can discover the trace points generated by this implementation. This even required submitting an upstream bug to the BCC toolchain. But now it works great for primitive types that have some meaningful equivalent in eBPF terms.
This was my first real Rust project and I was really impressed with how powerful proc macros can be.
Now I need to polish the docs and publish...
What made a huge difference for me was setting up Arch Linux on my XPS 15 laptop. Following the install guide[1] forced me to go through the process of standing up a functioning Linux desktop from a much lower level starting point than I'd ever done with Ubuntu or CentOS or even Slackware. The whole experience reminded me of the first few times I built PCs as a kid: At first they were intimidating boxes full of complex circuit boards and imposing nests of ribbon cable, but putting a few together demystified all that in a hurry. Setting up my Arch laptop had the same result as it relates to Linux configuration in general and command line operations in particular.
[1](https://wiki.archlinux.org/index.php/Installation_guide)
http://apocryph.org/archives/556
and
http://apocryph.org/archives/693
Summary: Highly entropic Markov-generated phrases are long and hard to remember.
True, but I submit this is not a sufficiently large quantitative change.
> Also the debate is ultimately not about this one thing today, but about a future in which one can download and print an open-source AK-47-equivalent with only slightly more difficulty than printing a picture.
I humbly suggest there is more to it than that, and will still be more to it than that in a future in which 3D printers can print composite materials strong enough to survive the extreme pressures of a 7.62x39mm cartridge firing a bullet down a long rifled barrel. Even if that were possible, the result of the AK-47 print job would be a whole mess of parts, including tiny pins, springs, etc. With the exception of the lower receiver, all of these parts can be bought (in the US at least) online with no government oversight or regulation. Once the parts are obtained, they must be assembled, which is not difficult for the mechanically inclined, but is considerably more difficult than printing a picture.
So, before this quantitative change:
* Obtain AK-47 spec and assembly instructions * Obtain necessary tools for assembly * Order AK-47 parts kit online * Buy AK-47 lower receiver from firearms dealer, or assemble yourself from sheet metal * Assemble AK-47
After this quantitative change:
* Obtain AK-47 spec and assembly instructions * Obtain AK-47 3D printer files * Obtain assembly tools printer files * Print AK-47 parts * Print AK-47 lower receiver * Assemble AK-47
Hardly a revolutionary shift.
Legally I don't see any sticky issue here, and if there's an ethical dilema I don't see it. Having said that, I agree with the general proposition that the law has not kept pace with technological innovation, and that there are areas in which this lag has serious consequences.
It's not hard to imagine a Congresscritter raising a fuss over concerns of "children printing machine guns" or some such nonsense, and thereby introducing legislation to regulate such materials, including executable scripts for 3D printing machines. It's even possible to imagine such legislation passing the House and Senate. Our current president would likely sign any such legislation he was given. However, it is very difficult to imagine the legislation surviving a Supreme Court challenge on First Amendment grounds.
Then again, I said the same thing about the McCain-Feingold Campaign Finance Reform Act, and SCOTUS upheld that 5-4, so what do I know.
Given this environment of legal uncertainty, it's not at all clear that BATFE would not pursue the 3D printer operator who produced the receiver. In this case, charges against the 3D printer operator would likely be unlawful manufacture of a firearm, possibly in addition to charges related to interstate transfer of a firearm. Given the creativity of some US attorneys, perhaps a conspiracy case would be made alleging the buyer of the printed part 'conspired' with the printer operator.
I would also suggest a lower receiver could probably be made from materials weaker than you might imagine. The lower receiver does not bear any gas pressures from the firing of the cartridge, though the holes for the roll pins which hold the hammer and trigger in place would probably start to 'egg' after a round or two. In any case, the legal question has nothing to do with how reliable the resulting firearm is; only whether it meets certain vague and broadly-interpreted legal definitions.
[1] http://www.everydaynodaysoff.com/2010/01/25/shoestring-machi...
There is no question that Evernote 3.5 sucked. It was slow, yes, but that was only part of it; using it one got the sense that one was using software without polish. The text editing experience was particularly broken, with formatting as simple as a bulleted list behaving strangely.
I've experienced some of the same WPF issues as Evernote reported, plus a few they haven't, and I'm sure those issues impacted the usability of their client. There is no question that WPF 3.5 has some serious issues. However, the lack of polish and poor fit and finish of the Evernote 3.5 client cannot be blamed entirely on WPF.
Having played very briefly with the Evernote 4.0 GUI, I can already tell it's better. It's back to feeling like a polished, performant tool. I imagine some of this is due to the use of native code, but at least a bit of it must be due to a team of great C++ developers working in an environment they know well.
Get the latest edition, covering .NET 4. The chapters on concurrency and I/O alone are worth the price of admission.
This gives me an idea: when will Mattel give us "Asynchrony is hard" Barbie?
My development environment is Visual Studio 2010 with R# and the zenburn theme.
Work is on site in Reston, VA, USA. No visa sponsorship so must have right to work in USA.
http://www.appassure.com/company/careers/junior-senior-engin...
I'm the development director at AppAssure, so drop my name and mention HN when you apply.
http://www.hanselman.com/blog/ScottHanselmans2009UltimateDev...
I think a lot of the stopping power complaints would be relieved by one of the following not-at-all-realistic changes:
1. Issue the M193 5.56 round to units fielding the M4 carbine. The M855's heavier and more complex bullet has been shown to fragment less reliably at the sort of velocities the M4's shorter barrel can achieve. Since the 5.56 FMJ round's lethality is tied to fragmentation more than punching big holes, this could fix many of the failure-to-stop issues
2. Back out of the damn Hague Convention and issue hollow point ammunition to our military forces. Hornady TAP law enforcement ammo is some pretty nasty shit, even out of a poodle shooter like the M4. Not as effective against body armor, but much more effective against flesh. Our LEOs and civilian contractors use this ammo; why not our military forces?
Logically, I know this is devastating for my productivity, but so is staring at a progress bar for 10 minutes after every change. After the iteration, I focus on fixing the one or two serious lags that hurt productivity. It's not always possible (I've no idea how I'll speed up this integration test), but it's a worthwhile effort.
It is for this same reason that my company spares no expense on dev workstations. When a build takes 10 minutes, the productivity hit is at least twice that, and it's a recurring penalty.
My parents at one time or another had me enrolled in just about every structured education scheme you can imagine, from reputable urban public school to shitty urban public school to expensive Catholic school to quaint small-town school to rural one-room schoolhouse to formalized home-school curriculum. I found them all stifling, boring, and wasteful of my time.
Unschooling, on the other hand, was very liberating. I got to study whatever I wanted, however I wanted. I dabbled in chemistry, electronics, literature, even carpentry. Once we got our first computer when I was 13, I dove into computing and programming utterly.
It worked out wonderfully for me. I had a paying job as a programmer when I was 15, and haven't looked back.
I was always introverted, so school was not a positive socializing experience for me; in fact it was quite the opposite. Despite concerns to the contrary, I've socialized myself over time through professional and personal relationships with co-workers and friends.
The most appealing outcome of my unschooling experience is the autodidactic learning style it reinforced. This comes in very handy as a software engineer, where the ability to independently pick up a new language, tool, technology, or architecture quickly and completely is a real asset.
I am the oldest of five children. All of us were homeschooled to some extent, with the proportion of homeschooling to structured education declining from oldest to youngest. We are all fairly bright, but the difference between those of us with more homeschooling and those with less is striking. The home schoolers are more eloquent, more insightful, more responsible, more disciplined, and more politically active (although not politically homogeneous, which makes for tumultuous dinner conversation at family get-togethers).
There is no doubt in my mind that unschooling had a massively positive net impact on my life, and would encourage any parents able to make the necessary time commitment to try it as well.