Why the Apple II ProDOS 2.4 Release Is the OS News of the Year - <AUTHOR> http://ascii.textfiles.com/archives/5054 <comment><USER2> I have so much admiration for the people who keep old platforms alive. I tinker with a Commodore 64 (a real one) now and then, and I'm just blown away by the community that still exists around it. People still write new software, build new hardware (I have a MSSIAH synth/MIDI interface cartridge and it's a blast to play with), make new demos and intros, discover new graphics modes and sound techniques, etc. The landscape is pretty well mapped out, but people still manage to find new ways to look at it every now and then.

I've always wanted an Apple IIgs, because it had a built-in FM synth that was really powerful for the time (I have a fascination with electronic music and equipment from that era, which is why I have the C64 and MSSIAH, as well as a Gameboy with LSDJ). Maybe now is a good time to start looking around for one.

This is a fantastic story...I want to play with it, just because.

<comment><USER3> "I tinker with a Commodore 64 (a real one) now and then, and I'm just blown away by the community that still exists around it."

I am curious - is there an analog in the c64 world to this new ProDOS 2.4 release ?

That is to say, have enthusiasts reworked and re-released the built-in c64 firmware or otherwise reworked the OS ?

<comment><USER4> Looks like Geos for the C64 has recently been reverse engineered and is now available on GitHub. [https://en.wikipedia.org/wiki/GEOS_(8-bit_operating_system)#...](https://en.wikipedia.org/wiki/GEOS_\(8-bit_operating_system\)#Reverse_engineering_efforts) [https://github.com/mist64/geos](https://github.com/mist64/geos)

</comment></comment></comment><comment><USER5> Wow. This brings back memories of my first job at Apple working on the IIe emulation board for the Mac LC.

<comment><USER6> Would love to hear more also! Did you have any involvement with 'Gus', the IIgs emulator written (but never publicly released) by Apple?

</comment></comment><comment><USER7> Sounds similar to the China Dos Union MS-DOS "7.1" which used the DOS from Windows 98 and included FAT32 support, long file names and a CD-based installer.

[https://winworldpc.com/product/ms-dos/7x](https://winworldpc.com/product/ms- dos/7x)

<comment><USER8> I remember coming across that many years ago, as far as I remember it was a rather interesting group of Chinese DOS-using hobbyists. They also came up with a "Windows 3.2" that fit on a floppy and was also based on the 7.1, creating possibly the only 3.x version of Windows with long filename support. The latter was released under the name "PMWIN3.ZIP" and apparently can only be found in the Internet archives now: [http://web.archive.org/web/20070128175800/http://www.cn- dos....](http://web.archive.org/web/20070128175800/http://www.cn- dos.net/msdos71/pmwin3.zip)

(The rest of cn-dos.net is also worth checking out if you read Chinese or find Google Translate to be sufficient; this is an example of one of the forgotten- yet-very-interesting parts of the Internet.)

<comment><USER9> Interesting, do the open-file dialogues and winfile support LFNs in this ? (@ work and can't look right now).

<comment><USER8> Yes:

[http://reboot.pro/uploads/monthly_04_2008/post-5-1208637282....](http://reboot.pro/uploads/monthly_04_2008/post-5-1208637282.jpg)

I'm not sure how they did it though, maybe when I have the time I'll look into it since this is a very unusual software.

<comment><USER10> probably copied the NT3.5 file manager and hacked it to work with win32s? that's probably easier than modifying the win3.11 binaries to hold file name buffers than what's needed for the 8.3 scheme.

(or maybe they binaries are actually pretty similar, so all it needed was a slight API change for file name lookup)

</comment></comment></comment></comment></comment><comment><USER11> Old apple stuff isn't my thing but I applaud any efforts to preserve our history. Jason makes a number of good points about the sorry state of modern OSes in his article, and it's worth a read for that alone.

<comment><USER8> Along the same lines there's an "unofficial service pack" for Windows 98SE which fixes a lot of little issues and actually allows running some substantially newer applications on the 18-year-old OS. I wouldn't be surprised if 2K/XP get the same treatment, and in fact I know it's already happening. It's sometimes amazing what the community can come up with.

<comment><USER12> I wish one could force vendors to open source operating systems they no longer support.

<comment><USER13> Oh yes! Then we could get the source to Mac OS 9 and bring it into the modern era! Spatial metaphor forever!

<comment><USER14> Imagine a fork of various Apple OS's that took skeuomorphic interfaces to their logical conclusion!

We need a name for this: an open set of parallel computing universes. Maybe OpenCandide: The Best of All Possible Worlds. (Ironic misinterpretation of the phrase intentional.)

<comment><USER13> I'm not sure if you were implying otherwise or not, but: spatial metaphor file managers are not skeuomorphic. Skeuomorphism strictly encompasses non- functional interface elements, such as faux-leather stitching on Apple's old address book application. The spatial metaphor Finder in OS 9 was 100% functional.

The way it remembered all of the details (size, layout, position, display mode) of each window and the way each window had an unbreakable 1 to 1 connection to a folder made it a joy to use. It allowed the user to identify what window belonged to a folder at a glance and to be able to set up a whole workspace arrangement and have it be remembered automatically by the Finder.

</comment></comment></comment></comment></comment></comment><comment><USER15> Here's an interesting retweet from ProDOS's author last month.

       @JBrooksBSI
       [59]Aug 17
       Was MS-DOS copied from CP/M?
       [60]embedded.com/electronics-bl...

       60. https://t.co/mOR5mLBHwC

[http://www.embedded.com/electronics-blogs/say- what-/4442498/...](http://www.embedded.com/electronics-blogs/say- what-/4442498/Was-DOS-copied-from-CPM-)

<comment><USER16> "My conclusion is that DOS source code was not copied from CP/M source code."

"The commands were not copied; they were simple, descriptive terms that were common to other operating system such as VMS and Apple DOS."

 _" The DOS system calls were definitely copied from the CP/M system calls. Given the quantity of identical numbers representing identical functions, it is clear that Tim Paterson referenced the CP/M manual when writing DOS."_

The last bit is alluded to in page D-7 of the DOS 1.0 user manual[1], which says "There is an additional mechanism for _pre-existing programs_ that were written with different calling conventions. The function number is placed in the CL register...and an intrasegment call is made to location 5 in the current code segment." That's because in CP/M, "...access to the FDOS functions is accomplished by passing a function number and information address through the primary point at location BOOT+0005H" [2].

[1] [https://archive.org/details/bitsavers_ibmpcdos61_7006095](https://archive.org/details/bitsavers_ibmpcdos61_7006095)

[2] [http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch5.htm#Sect...](http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch5.htm#Section_5.2)

So, yes, the DOS function calls were designed with CP/M backwards compatibility in mind, and it says so right in the manual. Kind of.

</comment></comment><comment><USER17> Another heroic effort was the posthumous release of Star Fox II. A community took the Japanese alpha of Star Fox II, patched all the bugs, made it fully playable, and translated it into English. I finished it and I can tell you it was better than Star Fox 64.

</comment><comment><USER18> I love this kind of stuff! Related is the reverse engineered GEOS (C64) available at github: [https://github.com/mist64/geos](https://github.com/mist64/geos)

The maintainers are gearing up to support more platforms, CPUs, repair and extend!

</comment><comment><USER19> Hmm, Still looks like it has the 32M (IIRC) partition limit. There are GSOS drivers to work around this, but not for generic 8-bit prodos (AFAIK).

Frankly, the II line was always slow moving (the IIE was sold commercially longer than any other computer without any significant upgrades). Which is why was such a great learning computer, there were only a couple models, very well documented, and hacked on to uncover every tiny little trick/edge case. Now days, I look at 6502 assembly and wonder how I managed to get anything done with such a restrictive stack/etc.

</comment><comment><USER20> Thank you John Brooks!! You are the best!!

Warning: this is going to get mushy...

While my first computer was the TRS-80 COCO I, I spent more time coding on my second computer, the Apple IIe, coming home each afternoon after school to just program and play games constantly. I owe my current occupation to that, and my family and friends that benefit from my salary I all owe to those two computers.

I love the Apple II line along with the TRS-80 COCO line and my heart is full that there are those that continue to develop for them.

</comment><comment><USER21> So how does one fix bugs in ProDOS 2.0.3? I assume John Brooks does not have the ProDOS source code. Is he patching the old binaries?

<comment><USER22> I'm going to go out on a limb and say that ProDOS was originally written directly in assembly and not compiled from a higher-level language.

Disassembling is pretty trivial compared to de-compiling.

</comment></comment><comment><USER23> Interesting read, but no mention at all of what this thing is, or will be, used for. Anyone?

<comment><USER24> My memory of 30 years ago is a bit rusty, but I don't recall an easy way to format an Apple II disk without putting either Apple DOS or Apple ProDOS on the disk. This version is smaller, more widely compatible, and adds several third-party add-on features to ProDOS.

So, it's useful any time you'd format a disk in your Apple II emulator. Now you get more utilities, and you disk works on a wider variety of hardware.

</comment></comment><comment><USER25> FTA, on why this is important:

 _Next is that this is an operating system upgrade free of commercial and marketing constraints and drives. Compared with, say, an iOS upgrade that trumpets the addition of a search function or blares out a proud announcement that they broke maps because Google kissed another boy at recess. Or Windows 10, the 1968 Democratic Convention Riot of Operating Systems, which was designed from the ground up to be compatible with a variety of mobile /tablet products that are on the way out, and which were shoved down the throats of current users with a cajoling, insulting methodology with misleading opt-out routes and freakier and freakier fake-countdowns._

So true. :/

<comment><USER26> > blares out a proud announcement that they broke maps because Google kissed > another boy at recess

Sure, if by "broke", you mean "built a privacy-respecting competitor based on a well-trusted open map technology called OpenStreetMap", and if by "kissed another boy", you mean "withheld turn-by-turn navigation because Apple wouldn't let Google whore out end-users private information as part of the process"..,

<comment><USER27> Most of my friends still think Apple Maps is a complete failure of a product because of their badly received launch. I'm always able to get them admit that Apple Maps' satellite data is far superior when I show them the side by side (try the satellite + map tilt in a major city or try the 3d tours).

<comment><USER26> Mob opinion is generally not the best gauge of reality.

Look at all the shit people are posting about Apple removing an ancient analog audio port, vs how many people are posting about Samsung the phone that self combusts.

<comment><USER28> Note 7 blow rate: 0.01% IPhone 7 jackless rate: 100% If my calculations are correct, then about 10000x more people should write about Apple's jack crucifixion.

Also, technology is not "ancient" just because it's 50 years old. Electric motor is over 180 years old, and that's not ancient. It's not ancient if it's used everywhere. If it's used everywhere, it's called modern.

<comment><USER26> > IPhone 7 backless rate: 100%

iPhone 7 included adapter rate: 100%.

If a phone blowing up is not something to be concerned with (ignoring all the Airlines and government departments telling people to turn them off while flying), then a removed audio port shouldn't even factor into your consciousness when you consider that they give you the adapter for free.

> Also, technology is not "ancient" just because it's 50 years old.

In the world of consumer electronics, 50 years _is_ ancient.

At the end of the day the way the 3.5mm jack is used in 2016 is the ultimate hack-on-a-hack-on-a-hack. The plugs are all the same size, but they could have anywhere from 2 to 5 contact points, depending on device type/manufacturer.

It worked for a while, but at some point you have to move on, and someone has to be the first to move. As I said in another comment, Apple has always been ahead of the pack when it comes to adopting new technology and dropping legacy technology.

> Electric motor is over 180 years old, and that's not ancient. It's not > ancient if it's used everywhere. If it's used everywhere, it's called modern

No, if its used everywhere its called "popular" or "ubiquitous".

An electric motor can be modern, if it's a new/recent design. That doesn't make all electric motors modern.

<comment><USER29> > iPhone 7 included adapter rate: 100%.

iPhone 1-7 requires proprietary connector rate: 100%.

> It worked for a while, but at some point you have to move > on, and someone > has to be the first to move. As I said in > another comment, Apple has > always been ahead of the pack > when it comes to adopting new technology and > dropping > legacy technology.

That'd be a great argument if what Apple was providing was objectively BETTER than the status quo. However, I'd wager that most people wouldn't call needing an adapter to utilize off the shelf headphones they already own or having to buy very expensive ones that will only work on SOME Apple products (not every Mac comes with a proprietary Lightning port) an improvement.

It's a pity too because I was seriously considering making the switch over to an iPhone next year, but then Apple goes and reminds how poorly they play with others.

EDIT: Oh and I almost forgot, want to charge your phone and use wired headphones at the same time? Better buy another adapter (not included).</comment></comment></comment></comment></comment></comment></comment>


How much time should I honestly shoot for to be programming outside of class? - <AUTHOR> At the moment I work about 45 hours a week. Though I am only in 7 credit hours, it's still a fairly full schedule, especially adding in commute times. I also plan on upping my hours quite a bit in the coming semesters in order to hopefully graduate a little earlier than anticipated.
My current workload and other responsibilities really limit how many hours a week outside of class I can spend truly working on my programming. Perhaps this sub is rubbing off on me a bit too much in that I feel like I'm going to need all these sorts of side projects in the coming years in school. Although just starting out I genuinely do enjoy when I get to sit down, program, solve programs and improve my skills. I just worry that being a pretty non-traditional student who needs to work a lot is going to hinder my improvement over the next 2-3 years before I graduate. How much difference could an extra 30 minutes to an hour a day outside of class really improve my skills, if that's all I can do at the moment? I can definitely spend more time on the weekends, as long as I'm not catching up on homework.
I enjoy this and wish more than anything I could find a way not to work and fully immerse myself in these studies and graduate in as good a position as possible. Finding a year round internship is definitely a focus for the coming years as I feel I wouldn't be wasting so much time at an unrelated job.
Overall I suppose I'm asking, should I be worried that I don't have several hours of free time a day to just simply code? I'm learning in my classes, I just don't have the opportunity to dive in like I want. Was anyone else in a similar situation as myself and still end up being "successful", for lack of better terms?
Any advice or inspiration would be great, thanks! <comment><USER2> I think the answer to this question varies from person to person, and depends greatly on the commitments you already have, and the things you value investing time in.

Back when I was at university, my honours supervisor was of the opinion that I should be sleeping in our lab, and doing as much work as possible as often as possible. At the time, I'm rather glad that I ignored this advice because your social life tends to suffer enough anyway, and I had friends, a motorcycle, and a girlfriend that I wanted to spend time with also. In the end I still graduated very successfully, despite what my supervisor's expectations were.

After I graduated, I decided academia wasn't my thing until I knew 100% what I wanted to study, and eventually I slipped into spending a lot of time playing video games and watching TV, and this increasingly became uncomfortable for me, so over the last year or two I've been working on spending more time doing things I find more valuable, in a more structured and versatile way that enables me to quantifiably make progress on the things I care about, while still allowing time for spontaneity, etc.

My current system ultimately comes down to a daily set of checkboxes that reflect the things I find important at present:

\- projects (any progress) \- reading (30 minutes or 1 chapter) \- exercise (walking/running/pushups/swimming) \- other (catch-all tasks, errands, etc) \- up @7:30 \- bed @11:30

These are mostly non-social goals, and my aim is to tick off as many as possible, but I give myself permission not to worry when something else comes up. Christmas is always a write-off, for example. But primarily, it gives me motivation to make time for the things I find important when I am able to, because I too have to work 38 hours a week, a social life that I would like to maintain, a relationship that I'd like to keep, and a smattering of other random things from time to time, and it's not always easy.

So in summary, I guess my answer is to find the balance that works best for you. The people you hear of that seem to work 10 hour days then throw in another 4 hours for side projects (or whatever) have found their balance that likely involves a number of sacrifices and compromises that may not actually suit you, so you should not aim to emulate them, and you can most definitely have a successful career without doing so. I would argue however, that your 'successful career' should be your own decision, and not because you believe "that's what people do". Your definition of 'success' may be very different to what the corporate world wants you to believe is successful. 20 years of 18 hour days working for big names may be one definition of success, but it certainly doesn't have to be yours.

Finally, to answer your question of 'what will an extra 30 minutes a day get me?' \- possibly not much if you only look at it in 30 minute chunks. But 30 minutes is a lot of time, when you accrue it over time. Approximately a week and a half per year if I've done my math correctly (or 22, 8 hour work days per year!). That's not an insignificant amount of time, and if you work on something important to you, it can be very rewarding. As far as skill development, you will likely learn more in a challenging environment (for a business, a startup, or with a group of people more experienced than you), but you can definitely do something valuable to you with that time.

<comment><USER3> I found a solution to the social life issue in college.

I picked the woman majoring in Computer Science as a girlfriend. The ratio was 40-to-1 at first glance, but excluding people who would return to foreign countries it was more like 200-to-1. This did not deter me. She was also kind of taken already, so I sort of had to swipe her.

That solution meant I could spend time with my computer and girlfriend simultaneously. We could sit at computers next to each other in the lab. If she was less busy, she could nap on my lap as I wrote code.</comment></comment>


Mother of Higgs boson found in superconductors - <AUTHOR> http://www.newscientist.com/article/dn26158-mother-of-higgs-boson-found-in-superconductors.html?cmpid=RSS%7CNSNS%7C2012-GLOBAL%7Conline-news#.VAolZGIayK1

<comment><USER2> It's very strange. The newscientist's articles says that this Higg's boson analogue gives the mass to the photons inside a superconductor. The problem is that the photons are related to the U(1) symmetry group. The real Higg's boson gives the mass to the W+,W- and Z particles, that are related to the SU(2) symmetry group. The problem is that the trick that produce the apparent mass don't work with the U(1) group because it's abelian and with dimension=1. (SU(2) is not abelian, and dimension=3).

The original research article is linked at the bottom: [http://www.sciencemag.org/content/345/6201/1145](http://www.sciencemag.org/content/345/6201/1145) I couldn't rear the complete article, so I read only the abstract. The abstract talks about pairs of electrons, but it doesn't mention photons.

Anyone can explain more about this?</comment>


Angel Advice from 1998 Still Applies Today - <AUTHOR> http://www.laevans.com/en/angels_funding.html <comment><USER2> decent article except for one advantage being:

"'vanity' 800 phone number"

<comment><USER3> Make that a vanity Twilio account.</comment></comment>


Expanded HTTP Method Support - <AUTHOR> https://blog.heroku.com/archives/2013/4/22/expanded_http_method_support?ref=twitter <comment><USER2> Now, if web browser would support custom HTTP verbs, you could map application actions to http verbs and start removing the years of work-arounds that used GET and POST to tunnel what you really wanted.

<comment><USER3> I think that if this was done, there'd be a surge of blog posts not long after telling people to just use the original verbs, because everything about them - caching, idempotence, safeness, etc. - is a known quantity and doesn't change based on different interpretations of the same verb. Not to mention ridiculously confusing APIs.

        TWEET /
        GOOGLE /internet/?query=...
        LIKE /friend/jimmy
        GETPUTPOSTDELETE /i-am-too-lazy-to-use-separate-verbs

<comment><USER2> POST <https://api.twitter.com/1.1/statuses/retweet/:id.json>

POST [https://www.googleapis.com/youtube/v3/videos/rate?id=1234...](https://www.googleapis.com/youtube/v3/videos/rate?id=1234&rating=like&key={YOUR_API_KEY})

APIs are already confusing for anything beyond CRUD operations.

</comment></comment></comment><comment><USER4> I'm seeing a 500. Maybe they forgot GET? :)

<comment><USER5> Someday I will understand how corporate blogs break so often. [1]

[1] Has written multiple CMSs that get used on mid-to-high traffic properties.

<comment><USER6> Wordpress ?

</comment></comment></comment><comment><USER7> There is hope for WebDAV SEARCH, the semantic idempotent alternative to POSTing complex queries which don't fit into GET query params.

</comment><comment><USER8> As far as I know, Heroku was using Amazon ELBs.

Given that ELB does not support arbitrary methods, does this mean they've stopped using it?

<comment><USER9> Something tells me they are running their own LBs now.

<comment><USER10> No. Still ELBs. Amazon changed the ELB software silently sometime last week. Our ELBs all started accepting arbitrary methods.</comment></comment></comment>


hexpeek: a hex editor for huge files - <AUTHOR> hexpeek: a hex editor for huge files
Occasionally I need to work with huge binary files. Over the years I've tried many different tools and never found one that was exactly what I wanted. In my experience most hex editors either (1) do not work well with 4GB+ files or (2) require the user to learn a curses interface and are not scriptable.
So I ended up creating a hex editor with some nice features:
    (1) prompt interface with command history (with libedit),
    (2) scriptable interface with a flexible command language,
    (3) no glitches on huge files -- no reading until user requests,
    (4) fully functional insert and delete,
    (5) multi-level backup and restore,
    (6) ability to dump generic file descriptors,
    (7) work in hexadecimal and with 64 bit file offsets by default,
    (8) BSD 3-clause license,
    (9) and more...
If interested, please check out the project at https://www.hexpeek.com or send e-mail to email@example.com.
hexpeek is known to work on Debian, CentOS, FreeBSD, and Cygwin and is expected to work on any recent POSIX-like system. I look forward to improving hexpeek based on community feedback. Please let me know what features you are looking for in a hex/metadata editor.
About the author: visit https://www.resiliware.com for more about me.
Thanks for reading! <comment><USER2> hexedit (included in debian/ubuntu) and dd (included in everything) seem to cover both large files and scriptability quite well

<comment><USER3> Yes, I was confused by this too - because my only experience of using hex editors was hexediting an executable (definitely not to remove some DRM), hexedit was very capable and the executable wasn't exactly small.

<comment><AUTHOR> My lower bound for huge files is 4GiB. The actual use case that started the development of hexpeek was trying to surgically inspect and modify disparate parts of a 100GiB file. I'm not sure if your executable was that large.</comment></comment></comment>


Police response into 'transphobic' tweets was unlawful rules UK High Court - <AUTHOR> https://www.bbc.co.uk/news/uk-england-lincolnshire-51501202 <comment><AUTHOR> [https://www.judiciary.uk/wp- content/uploads/2020/02/miller-v...](https://www.judiciary.uk/wp- content/uploads/2020/02/miller-v-college-of-police-judgment.pdf) here is the judgment which has as the opening paragraph from the Judge a quote from George Orwell:

"If liberty means anything at all, it means the right to tell people what they do not want to hear."</comment>


You Don't Want XTS - <AUTHOR> http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ <comment><USER3> I don't get the title.

The title tells me I don't want XTS.

Then the post explains that I don't want FDE, for sundry reasons. Then it tells me, sure, go ahead and use FDE, but be aware of the limitations.

At that point it looks like I want XTS, after all.

Then it shows how XTS works and where cryptographers are seeing problems.

And then... well, there is no "then". The recommendations don't deal with FDE at all.

I think the post would be much stronger, if it either had some alternative mode to present or (I'd be more interested in that) it showed other ways to achieve what people usually try to achieve with FDE. And usability is a big one there. Bitlocker is huge. FileVault is huge. People can actually use it.

An aside: Has anyone ever seriously used XTS mode for anything but FDE? I've only encountered it in Truecrypt and the part of Boneh's Crypto I where he's talking about FDE. But that doesn't mean much, I admit.

<comment><USER4> The post ends with the takeaways I'm hoping for:

1\. Try not to rely on FDE at all.

2\. For God's sake don't use XTS for anything other than FDE.

There's an encrypted filesystem guy that suggested they were moving to XTS. That's what prompted the post.

Usability is great. I think you should turn FDE on. But turning on FDE buys you a lot less than you think it does. There's a pretty good chance that FDE isn't going to do anything for you if your computer is seized by the FBI, because the key will probably resident when they do that.

You don't want XTS, in general, because you don't want to turn a simpler problem (safely encrypting your secrets) into a hard problem (simulating hardware encryption).

<comment><USER5> Do you know if there are any effective forensic attacks in use against the TRESOR design?

(I was one of the authors of the cold boot paper at USENIX Security, but I haven't followed the subsequent history of attacks and defenses very consistently.)

<comment><USER6> TRESOR is only effective against passive forensics and only protects key material.

It does not protect against an attacker able to manipulate memory contents through, say, DMA or other malicious devices.

<comment><USER5> Hi Steve,

I remember the DMA situation from a few years ago being quite bad, and it looks like you or one of your colleagues has posted some good resources on that at

[http://privatecore.com/resources-overview/physical-memory- at...](http://privatecore.com/resources-overview/physical-memory-attacks/)

I realize that with PrivateCore you're taking quite a comprehensive approach to this problem and not bothering with more piecemeal counterforensic approaches, but I'm still curious about what counterforensic techniques exist for people who aren't going as far as you are. For example, can we make stock Linux deny memory access on external buses with a software policy, or is this simply not something that can be accomplished from software?

I imagine you have good arguments for why the piecemeal approach is likely to fail in the face of an skilled forensic attacker. But many of the attacks that you described to me when we last talked about this were more along the lines of hardware-assisted Evil Maid attacks in an unmonitored and unsupervised colo, rather than forensic attacks against an unmodified encrypted laptop. I'm curious about how different the threat scenarios are between these two cases now.

<comment><USER6> Enabling IOMMU is one relatively easy software mitigation to DMA attacks. There are some gaps, but it stops the trivial cases where a device can access all of memory.

<comment><USER7> > [IOMMU:] There are some gaps

Do you happen to have a link where I can read more about those?

</comment></comment></comment></comment></comment></comment></comment><comment><USER4> If anyone's interested in a fun project:

It's apparently pretty common for people to create virtual Truecrypt volumes and stick them on Dropbox, as a sort of poor-hacker's encrypted Dropbox.

Someone should bone up on the "Evil Maid" attack and do a proof-of-concept of it on a Dropbox-backed volume. Call it "Evil Maid In The Cloud", or "The Mallory Poppins Attack".

My intuition is that the Evil Maid attack is much more powerful vs. Dropbox- backed volumes.

<comment><USER8> The block layer is a poor location to support security, whether access control or encryption. The lack of knowledge of upper layers & the resource constraints of the lower layers (block stealing for metadata) unnecessarily hamper its security and performance.

The only reason for block-level encryption in software is because it was too much work to retrofit UFS, ext23456fs, FAT, NTFS, etc. with encryption. The block device provided a convenient bottleneck, and no one cared too much about the downsides you bring up because it seemed better than nothing.

ZFS generally gets this right, using AES-CCM (an AEAD mode as you recommend). It also has proper integration with the deduplication layer so encryption doesn't waste space. These reasons and more show why security needs to be implemented at the filesystem layer.

Another good example people here may be familiar with is Tarsnap. Again, it handles encryption, integrity protection, and deduplication without storing keys on the server side or unnecessarily restricting itself to a block device metaphor.

You're right that TC+DB are not a safe combo. Dropbox needs to be the encrypted Dropbox.

<comment><USER9> Keep in mind that the simpler implementation of block layer encryption also makes it easier to implement and audit.

I'm not as confident in the design and implementation of encryption in e.g. ZFS as I am in full disk encryption.

I'm not sure Tarsnap is a great example of doing encryption at a high level either. As I understand it the encryption layer only deals with opaque chunks of data; it doesn't know anything about high-level concepts like files and folders that the Tarsnap application operates on.

<comment><USER10> _As I understand it the encryption layer only deals with opaque chunks of data_

Correct.

 _it doesn 't know anything about high-level concepts like files and folders that the Tarsnap application operates on._

Tarsnap doesn't really operate on high-level concepts like files and folders. It flattens everything into a tar archive, then encrypts and signs that. That does however ensure that data and metadata are kept together, in a way that encrypting individual disk sectors does not.

<comment><USER9> From an end user's perspective Tarsnap certainly deals with files and folders. It outsources most of that work to libarchive, which is kind of my point.

The article says to "Encrypt things at the highest layer you can.", but you could imagine a backup utility doing encryption at a higher layer than Tarsnap does, with all the complications that would bring. And would it be even better if instead of file system level encryption, every application encrypted it's own files? I don't think so.

So maybe it should just say "Encrypt things at the highest layer that makes sense", which is kind of vacuous.

IMO it would make just as much sense to say "Encrypt things at the level where it's easiest to do.", where block level encryption is a strong contender. It doesn't give you every property you might want, but it's easy to get right.

<comment><USER4> I think it would be better if applications could provide their own encryption. Applications know better how to cryptographically protect content. For instance: we use GPGMail for our email at Matasano. The operating system could not do a better job of encrypting email messages than GPGMail does.

I understand your point. "Encrypt at the highest layer you can" is an ideal, and achieving the ideal is not always worth the expense. Some lowest-common- denominator crypto in the OS is valuable. But disk block crypto is a pretty crappy lowest common denominator, as this article is at pains to say. What part of it do you disagree with?

<comment><USER9> If every application provided their own encryption, most of them would get it wrong, and it still wouldn't protect important metadata. I don't think that's much of an ideal.

I don't have an issue with adding application specific encryption, as long as you also keep doing it at a suitable "lowest-common-denominator" layer.

A more achievable ideal would be for every layer to do strong integrity checking.

<comment><USER4> I agree that one of the costs for doing everything at the highest possible layer is the potential for mistakes. I don't think every application should _invent_ their own cryptosystem; I think most applications would be well- served with Nacl, and I think things like GPGMail show another good path forward.

I agree that it would be good if the lowest common denominator provided integrity checking, but as we can see with XTS, sector-level encryption makes that hard. Hence the article. :)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> I don't want XTS? Yes I do, for the purpose it was designed - block device level encryption. The title is misleading, and potentially dangerously so - <USER2> could see somebody switching to some CBC-like mode in TrueCrypt "coz tptacek said so" (even if that's not what he said).

And I think several statements are, well, let's say disputable. OK, XTS has the unnecessary complication of two keys, introduced in the standardization process. But the security in storage group (whatever it's called) has apparently seen the light is working on essentially allowing just one again.

Furthermore, XTS is denounced for having "unclear security goals", and the post leaves the impression that wide-block schemes are so much better. Yet their goals are essentially exactly the same as those of XTS, just on a sector as opposed to a (cipher) block level. And do correct me if I'm wrong, but I believe they are pretty clear: essentially ECB encryption of every cipher block on the disk, with a different key. In more concrete terms, I believe those translate to security under deterministic chosen-plaintext attacks, and non-malleability.

Finally Evil Maid attacks (at least the ones presented so far) have absolutely nothing to do with any cipher mode you're using, and everything to do with the trusted platform problem. Maybe in a Dropbox setting the attacker could benefit from the cut-n-paste abilities, but I'm not sure how realistic/severe those attacks would be (presumably you wouldn't have your system partition on Dropbox). I'm having a hard time imagining them, but then again there exist much smarter people than myself in this world.

Not to be only critical of the article, I do believe that the basic messages are sound: be aware of the limitations of FDE and don't use XTS in the contexts outside of FDE (unless you really know what you're doing, I guess). But the rest of it I could do without.

<comment><USER4> Couple responses:

You scare-quote "unclear security goals", but that's not my objection, that's Phil Rogaway's objection. And his argument (and Ferguson's argument, and Liskov's argument) isn't hard to understand: by adopting disk sectors as the setting for your encryption, you trade transparency (the ability to use encryption on any filesystem) for a whole mess of constraints, which the article you're commenting on lays out in detail. The worst of these constraints is that you lose any real authentication, but the fact that XTS is basically XEX-ECB is another problem.

You've also taken the "two keys" issue out of context. The issue isn't that it unnecessarily uses two keys. The issue is that it's hard to derive clean security proofs for XTS, because of all its complications. The way Rogaway puts it: there are three constructions involved in XTS --- the XTS wide-to- narrow block adapter, the "XEX2" two-key XEX construction for full narrow blocks, and the "XEX3" two-key construction for partial narrow blocks.

I believe you're also wrong about the Evil Maid scenario. Perhaps you're getting hung up on a detail that I wasn't implicating (for instance, booting from the drive). The issue is that in a normal FDE setting, attackers don't get _repeated_ use-tamper-use cycles. But in a cloud-backed FDE setting, they easily do get that, so more sophisticated versions of the same attack scenario are possible. Think "Evil Maid" here in the same sense as Kenny Patterson used the "BEAST" attack scenario to build a plausible attack on RC4.

The problem with XTS is that there are better modes you can use, _even for sector-level encryption_ , if you shake off the constraint that you're working with physical disk geometry. Which, in the real world, a lot of FDE users can in fact do, because they're not working with real disks but rather virtual disks stored on cloud filesystems.

If you don't need to comply with physical disk geometry, it is probably feasible to get block-level encryption _with strong authentication guarantees_ , and with a native wide-block PRP that will get rid of the ECB data leak in XTS.

Finally, don't use XTS for anything but FDE, even if you know what you're doing. That's a bit of a tautological statement for me to make, because if you know XTS, you also know that it's only meant for FDE --- but I've been getting comments from people who have seen XTS used in application-layer crypto. Bad. Ick.

<comment><USER11> As for security goals: are they not the ones I stated in my post? No, ciphertext integrity is not among them, and yes, there are consequences to this. Yes, it's a trade-off for efficiency. But I really don't see how all of that relates to the issue of missing security goals.

What paper by Rogaway are you referencing there? I'm assuming it's not the original XEX paper, and I'm genuinely interested in reading it, this discussion aside. Anyway, I don't understand the "wide-to-narrow block adapter" part. Assuming that the standard group removes the two key "improvement", the only bit that I can see that remains to be proved, is the ciphertext stealing. I admittedly don't know whether proofs for the whole construction exist. A quick search revealed Liskov's review of the XTS draft which gives a sketch, but not the whole proof.

I'm confident about my Evil Maid statement. The essence of (what's commonly referred to as) Evil Maid really is the fact that you cannot trust your own computer. The multiple visits make the attack significantly easier, but are not necessary - you just need a more advanced malware.

As for repeated tampering, I'm still having a hard time imagining a realistic attack. I just don't see how the attacker can get any predictable amount of control of the FDE's inputs, but like I said, people can come up with smart things. The "system drive" in my post was referring to things like weakening the system security by overwriting configuration files with garbage and the like, which are theoretically possible although I don't really see them being practical.

Yes of course you can get better security guarantees if you change the constraints. You're probably correct that it should be feasible to offer a 512 byte sector view to the OS on the one side, and use whatever size on the physical side, if your physical side isn't really physical.

P.S. I didn't really think much of the the scare-quotes retort, seemed like a bit of a cheap jab. If you however have a better idea (or pointers for that matter) about how to refer to a specific part of a blog post I disagree with, I'd be interested to hear.

<comment><USER4> It's not the XEX paper; it's "Evaluation of Some Block Cipher Modes". Highly recommended.

Efficiency in the sense of "comparing block cipher modes" is not the reason XTS loses integrity and resistance to chosen-ciphertext attacks. Format constraints are the major reason. To wit: there's no good place to stick an auth tag, and for that matter, no good sense of what you'd be authenticating, because you're dealing with fragments of files, not actual files.

Integrity _does_ factor into the security model of XTS. Rogaway points this out when he explains why NIST apparently rejected CBC (the chaining gives attackers a forward bit-flipping capability) and CTR (which was rejected because it's trivially malleable). NIST claimed that some notion of resisting ciphertext tampering was part of the goal, but, as he said, and Ferguson said, and I said repeatedly in this article, nobody really knows what that tamper- resistance is supposed to mean. Attackers can tamper with ciphertext in XTS, and they can probably do it in ways that will create backdoors in binaries!

But lack of integrity checking isn't the only problem with XTS. Another problem is that XTS is for the most part the ECB mode application of XEX. You can't even get a strong definition of confidentiality from this construction, because an attacker observing block offsets into a given sector can collect useful information as those blocks are changed, changed again, changed back, and changed again. This is the attack Ferguson points out in his objection to NIST standardizing XTS, and it's also related to Rogaway's objection that NIST standardized a wide-block-narrow-block construction rather than something that behaved more like a tweakable native wide block construction. The native wide block construction would effectively randomize _the whole sector_ , not 16-byte chunks of sectors. That would also lessen the harm from XTS's malleability, but here we're more concerned with the granularity of the data we leak by encrypting deterministically.

If you want to call the attack I'm talking about something other than "Evil Maid", that's fine by me. I'd also accept "Mary Poppins is a governess and not a maid" as a valid objection. The point is that virtual disks stored on Dropbox are exposed to far more interesting attacks than physical disk media is, because with physical media, attackers don't get an unbounded number of use-tamper-use cycles.

<comment><USER11> Thanks for the paper reference.

I believe I do understand the constraints under which XTS operates on, and I agree with almost everything you said in the last comment. The only thing I don't agree with is that nobody knows what tamper resistance is supposed to mean - it's non-malleability on the level of a cipher block. Yes this is clearly worse than a sector-level non-malleability, but is also clearly /much/, /much/ better than CBC-style bit-level malleability. But I'll have a look at Rogaway's paper, maybe there's something I'm missing.

I'm still having a hard time conjuring anything resembling a practical attack coming from this. To plant backdoors, you'd have to know the exact location of a binary (feasible and done before, if with pretty strong assumptions), then get the user to change those exact same sectors to something that would be useful to you, and then copy-paste the ciphertext. I just don't see that happening in a real world scenario. Otherwise, taking advantage of the weaker confidentiality notion (deterministic CPA)... still seems quite far fetched, but I accept that I could be proven wrong.

At any rate, I still maintain that this has nothing to do with Evil Maid attacks. Use a CCA2 secure cipher and encrypt the whole disk at once if you want, the Maid still wins.

<comment><USER4> You only need to know where on the disk the binary is. Once you know that, you attack the binary directly, by randomizing a 16-byte chunk of it. The effectiveness of that attack depends on a lot of factors, but remember that X64 binaries aren't the only thing that XTS needs to protect.

For that matter, you can trigger vulnerabilities in the kernel or even application code, by surreptitiously randomizing offsets into metadata that they depend on.

What's clear to a cryptographer is that no scheme that provides serious non- malleability should have this property, but XTS does. What's maddening, in a theoretical sense, is that you can't really put this into formal terms, because --- as I've been saying --- nobody has provided a clear definition of what security guarantees XTS is supposed to provide.

No amount of use-tamper-use breaks a cipher that resists CCA2 attacks, because _every_ attempt to tamper produces a hard failure. That's what CCA2-resistance means: attackers don't get to adaptively choose ciphertext (or really, choose any ciphertext at all). In practice, cryptosystems resist these attacks by authenticating ciphertext.

For what it's worth, the article we're commenting on is clear that CBC is inferior to XTS for disk encryption. I take no responsibility for readers who read random selections of the article and come to their own conclusions, although if you look elsewhere on this thread that has clearly happened at least once.

<comment><USER11> I concede the point about the possibility of triggering crashes in say the kernel code. This however a) does not depend on repeated access to the encrypted drive, b) is only slightly less likely to occur with a wide-block mode, c) might be hard to meaningfully exploit, but I'll defer to your expertise on that one.

It also doesn't really seem to rely on multiple access to the ciphertext (you're not gonna brute force 16 bytes). And as I mentioned, you are not that likely to have your system partition on Dropbox, and I'd wager the contents and offsets of your user partition are not that easy to guess.

For a definition of non-malleability applicable to XTS, see "Security Notions for Disk Encryption".

Lastly, you're missing my point about CCA2 encryption - it does not solve the trusted platform problem, and an encryption system based on it is thus as vulnerable to Evil Maid attacks as your poor old XTS. Unless you want to exclude installation of malware from the definition of an Evil Maid attack, but then your usage of the term conflicts with just about everybody else's.

<comment><USER4> We're in a semantic rut here. Like I said way upthread: I'm not trying to litigate the term "Evil Maid". I'm pointing out that Truecrypt+Dropbox is vulnerable to use-tamper-use attacks in ways that physical disk encryption isn't. Authenticated encryption rules these attacks out, because there is no way to fail anything but completely when modifying ciphertext on the stored image. Call the attack whatever you'd like; I've clearly mentally generalized the Evil Maid idea in a way that you haven't. Maybe I'm giving Joanna Rutkowska too much credit (but I doubt it :)

Regarding "multiple access to the ciphertext" \--- you will indeed brute force 16 bytes, but you won't be trying to find a 128 bit needle in the haystack; you'll be looking for 128 bit blocks that happen to have a mix of innocuous bytes --- of which there will be many possibilities --- coupled with the opcode you want, and you'll have the bytes trailing the previous block and the bytes leading the subsequent block to play with as well to narrow your search. The attack will look a little bit like the byte-at-a-time attack on ECB.

I think that attack is significantly more plausible than you think it is. Apparently, so did Ferguson, since he brought it up ("Code modification attacks") in his NIST objection.

<comment><USER11> My issue with semantics is not that you're generalizing the notion, but rather specializing it. The "tamper" part of use-tamper-use in Evil Maid refers to the entire system, whereas you insist on tampering with only the ciphertext.

I'm still skeptical about code modification. The access the attacker gets is not really an oracle as in your byte-at-a-time scenario (I take it you're referring to the one from your crypto challenges), they can only observe the decryption output in a very indirect fashion. The number of potentially useful "needle" configurations is also hard to tell, you'd need to get alignment right and produce valid opcodes throughout the block etc. And also how many tries would the attacker get in reality? The executable would need to be reloaded for each one of his tries.

But more fundamentally, I find the whole scenario unlikely. To get there in the first place would require the user to sync their system partition with Dropbox. I think it's fair to say that will almost never happen. And if we're talking about a physical repeated-tamper attacker, well the Evil Maid (the original (TM)) is a much easier option for him.

<comment><USER4> If you store an image with executable code in it on Dropbox via Truecrypt, how many times will you potentially run it out of that image?

Again: we are talking about properties that cryptographically sound systems simply don't have. And if you're using Dropbox as your backing store, and not a physical drive, there is no reason to accept those properties!

<comment><USER11> If I store a program on Dropbox, I might run it many times. Thousands? Millions to be generous? But if the attacker has to do a brute force search which relies on me executing each different tampered version of the program, that's probably too small of a number.

The reason to accept sub-optimal properties in this case is convenience. Truecrypt is popular and has a nice interface. Using it with Dropbox gives much better security than not using it with Dropbox. It's not perfect, but I still don't think we have any practical attacks against such a scenario.

I agree that having stronger crypto there is however possible and desirable.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> So why can't we authenticate all the sectors? Is the performance really that bad, even with AES-NI and such? Chrome OS and Android devices that use dm- verity already do this (albeit for read only), so that's hard to believe...

With SSDs, seek time shouldn't be an issue. You can argue that if an attacker can modify your disk, they can probably run code to steal your password, but this does not apply to Dropbox-stored disk images, and AFAIK you can try to secure a PC against modified code seeing the keys using TXT.

<comment><USER4> This is a good question. Here are some reasons:

* If you're working with 512 byte sectors, the cost of individual MAC tags gets high.

* No matter what your sector size, reserving space for the MAC tag gets you odd-sized sectors.

* Most importantly, what does it mean to have a sector with a bad MAC? How does that get reported back to the filesystem? Filesystems aren't designed to cooperate with the disk to track cryptographic attacks.

By the time you solve that last problem, you've already gotten yourself pretty far down the track of just providing crypto in the filesystem layer. Which, because the filesystem layer is format-aware, you might as well just keep going and make a proper cryptographic filesystem.

<comment><USER13> Is there anything wrong with reporting a sector with a bad MAC as an unrecoverable read error, just as the hardware would do if the CRC failed?

Reserving the space is the real killer - either you end up with non-512-byte sectors (and what is more problematic, sectors that don't divide the system memory page size) or you stash the MACs elsewhere in which case every write to a sector also requires a read-modify-write of the sector that holds the MAC.

<comment><USER4> Does an "unrecoverable read error" mean that the file is read with a big zeroed out chunk (and an error somewhere)? Does it mean that the whole file becomes unreadable? Can the user recover any part of the file? How do they know what to do? Do all filesystems handle those read errors the same way?

It's clearly not impossible to get the level of cooperation between the fileystem and the encrypted device that you need, but that's effort, and it's effort perhaps better spent on simply encrypting at the filesystem layer.

I think you're right though that the alignment issue is dispositive.

<comment><USER13> Speaking in terms of UNIX-style operating systems...

No serious filesystem will return a zeroed out chunk. Apart from that, it obviously depends on where the read error hit - it might cause just one block in the file to return EIO from read(); it might cause a large part of a file to return EIO from read(); it might make the entire file inaccessible (EIO from open()); it might make entire parts of the directory tree inaccessible (EIO from open() or readdir()) or it might make the entire filesystem fail to mount.

Files that are mmap()ed rather than read() will SIGBUS the process on an IO error - this includes executables and libraries.

I think I see what you're driving at, though - application code isn't designed with the idea that EIO might be maliciously-induced, so you could do things like induce a database to rollback to an earlier point in time by corrupting its journal, or make a badly-designed firewall fail-open when its configuration files fail to load?

<comment><USER4> Yep. If your cryptosystem is designed properly, _none of that_ should be possible.

<comment><USER13> I'm not sure it's solved by encrypting at the filesystem layer either, though - the problem is that the smarts need to move all the way up to the applications themselves. That's likely impossible, so your next best option is to just hard-fail the entire system on a MAC failure, which is just as easy for dm-crypt to do as ZFS, for example.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I primarily like XTS because it's very fast and can be efficiently pipelined on x86 platforms with AESNI. I can get 215 Gbps throughput on 8 cores of a modern Intel CPU.

Also, if XTS is used in a length-preserving fashion, it can encrypt standard block devices without significant changes.

However, length-preserving means that it's either not going to be authenticated or you need to keep authentication material elsewhere. In the latter case, I'd rather use GCM.

<comment><USER4> The AES-NI properties that XTS exploit can also be exploited by better wide- block-narrow-block constructions; Rogaway for instance suggests that XTS could have cleaned up the CTS construction by using a better understood Feistel construction.

Even better would be a "native" wide-block tweakable cipher, one that created a strong PRP out of the entire sector, rather than chunking the sector into narrow blocks and then ECB'ing those narrow blocks. However you did that, it would also probably involve invocations of the AES block transform, and thus benefit from AES-NI.

But you're right: XTS has a convenience advantage for encryption in the standard hardware block device setting. What's sad about that is that simulated hardware block encryption is actually not a particularly strong protection for users.

<comment><USER14> Have you checked Rogaway's AEZ? Its core could probably be repurposed to disk encryption, being an AES-based tweakable wide block cipher.

<comment><USER4> I remember reading this, but will admit to not having an immediate intuition for what it would look like as a wide-block disk encryption scheme.

</comment></comment></comment></comment><comment><USER15> Authors recommendations seem bit "handwavy" to me. I understand that this article probably is not intended for end-users, but still it would have been nice to have more concrete advice. Eg dm-crypt is usually used with XTS mode, what would the author (or the good crowd of HN) say to be "better" solution (not necessarily at block layer) for eg. protecting laptop?

<comment><USER8> As I mentioned above, ZFS is a good example of filesystem encryption without the block device constraints.

But between your OS and the hard drive in your laptop, use whatever full disk encryption software that is best supported & most secure. He's not criticizing FDE in general, he's saying "don't constrain yourself to the block device model if you're designing database encryption etc etc."

<comment><USER15> > ZFS is a good example of filesystem encryption without the block device > constraints

Would you happen to know if there is anything equivalent planned/done for btrfs (or ext4)?

</comment></comment></comment><comment><USER16> Man I've been having a run around recently with a notebook I just ordered.

First intuition is to just LUKs both disks. Ok, that might work, and then I see the horrible performance degradation from FHDing an SSD.

Second intuition is SED, and I got a Crucial m550 to hopefully satisfy that, but then I find out there is no documentation on if the ATA password is stored in the firmware. If it is, I'm just wasting my time, and I kind of just have to hope Crucial does the right thing and doesn't store the AES key anywhere. I also have to hope the marketing "hardware encryption" is true like on my 840 Pro, where I don't see any performance loss.

And even userspace level encryption of config files that use plaintext passwords is terrible (and lets be honest, way too many different programs hide credentials in plaintext somewhere for me to find all of them easily with a full desktop - off the top of my head, networkmanager, KDE-PIM, Telepathy, Firefox, and Steam all have their own independent unrelated credential stores).

In general I would just want to encrypt all of base ~, /var, and /etc, since that is where personal data can end up (and maybe /opt, because random stuff ends up there) - but then I'm still losing most of the reason of having an SSD, especially one with a hardware AES accelerator that would go unused.

And don't get me started on the mechanical drive, which I'm going to have to part bin when I get the thing and see if it has working hardware encryption. At least on that it isn't too bad to use LUKs, because then the overhead isn't as bad - but having overhead at all kind of sucks.

</comment><comment><USER17> As someone who uses dropbox to store encrypted VirtualBox vdi virtual hard disk files using XTS encryption, can someone tell me what I should be using instead of XTS?

</comment><comment><USER18> TL;DR For random-seek block encryption, don't use XTS, _use CTR._

It's simple. I like simple maths and code, it's less to screw up _and less for implementations to screw up_. For example, I don't trust EC or GCM, even if some people thinks they're the new hotness, because complexity creates more opportunities for obfuscation and puts the code further out of reach of the already few eyeballs actually (or not) looking at it.

Maybe 'cpervica explain why

<comment><USER4> What? No. Don't do that.

<comment><USER18> ? What's wrong with CTR? CTR is basically an OTP. Being OTP, encryption and decryption are basically the same construction (thank you XOR).

        cipherblockdata = blockcipher(key, nonce . block #) ^ plainblockdata
        plainblockdata = blockcipher(key, nonce . block #) ^ cipherblockdata

If MAC is needed, that can happen after encrypting, before decrypting. (Needed if bytes traverse network, but maybe not for local disk or file encryption unless.)

Edit fixed my maths:

<comment><USER19> Uh, yeah, except not a cryptographic hash function, first of all :-)

Secondly, CTR has serious issues too. It is trivial to bit-fiddle. The naive implementation you're suggesting leaks the keystream in one CCA query.

Just because CTR in and of itself is easy to get right doesn't mean that any system composed using CTR is easy to get right.

<comment><USER18> Fixed.

That's beyond the scope of which mode, but it's important. However the less code one has, the fewer places there are for things to hide.

<comment><USER4> No, malleability is _not_ beyond the scope of which "mode" you encrypt something with. That's like saying that security is beyond the scope of which "mode" you encrypt with. People used to believe you could divorce confidentiality from integrity, back in the 1990s, but that turned out not to me true, due to adaptive chosen ciphertext attacks.</comment></comment></comment></comment></comment></comment>


Gtop – system monitoring dashboard for terminal - <AUTHOR> https://github.com/aksakalli/gtop <comment><USER2> is there any alternatives like this with a web based interface?

<comment><USER3> [https://nicolargo.github.io/glances/](https://nicolargo.github.io/glances/)</comment></comment>


A loser's lottery - <AUTHOR> http://statisticalideas.blogspot.com/2016/04/a-losers-lottery.html <comment><USER2> What's far worse is what happens to people who win who are ill equipped to handle that much money.</comment>


Why you should try GraphQL? - <AUTHOR> https://blog.graphqleditor.com/why-you-should-try-graphql/ <comment><USER2> We used it for a b2b backend system with a lot of configurable knobs that change data entry drastically.

It meant that we had almost no possibility in caching anything so we saw a good fit in Graphql. Especially when 3th parties need an API you can easily give them the Graphql and they can query what they need.

We used it in a rails app with a react frontend. Depending on the requirements, GraphQL can bring more problems to the table than solutions</comment>


The Lost Horizon Night Market, bespoke experiences in box trucks - <AUTHOR> http://missionlocal.org/2010/12/guerrilla-art-night-market-rolls-in-on-trucks-saturday-and-then-disappears/

<comment><USER2> This is a brilliant idea! Why isn't it being done in large scale?

<comment><AUTHOR> What do you mean by large scale? The first San Francisco event featured 20 trucks. The most recent Brooklyn one, which is where it originated, had 30.

<comment><USER2> I meant in more places, e.g. Chicago. This is the first time I've ever heard of this. Is there a site where I can check the schedules?

<comment><AUTHOR> It's kind of organized ad hoc. If you're interested in putting one on, I'd suggest contacting the organizers. :)</comment></comment></comment></comment>


Why it's time to learn CoffeeScript (and that other new fancy technology) - <AUTHOR> http://connorblack.me/why-its-time-to-learn-coffeescript-and-that-other-new-fancy-technology/

<comment><USER2> I can't see you up there your horse is too high. If you think that there is no place for PHP or Java or .Net in the modern web development world then you must not get out much. Rails and Node are great for some things. Smaller things. But I don't think they come anywhere close to filling all of the gaps in the web development world. Not everything is a startup and a lot of people would like to be able to work on their software 5 years down the road when node is a thing of the past.

<comment><AUTHOR> You can support more than 250,000 concurrent connections on a node server. That doesn't seem small to me. Anything you can do on other frameworks you can do as good or better on node.js or ruby on rails.</comment></comment>


Microsoft is killing it in all businesses except for one - <AUTHOR> https://wetradehq.com/blog/Microsoft-is-killing-it-in-all-businesses-except-for-one <comment><USER2> > Microsoft was led by stellar results in the Azure cloud computing, LinkedIn > and cloud-software segments, with only one laggard: The Xbox gaming business > and its related services.

The title should be changed to _Microsoft is killing it in all businesses except for Xbox gaming_ , IMHO.

Edit: I meant on HN, since the guidelines say: "please use the original title, unless it is misleading or linkbait"

<comment><USER3> If that would be the headline, there would be no reason at all to click on the story.

<comment><USER4> Except if you're actually interested in the story?

<comment><USER5> If you're interested in the details, surely telling people that Xbox is the one which isn't "killing it" isn't going to stop them clicking on the link?

</comment></comment></comment></comment><comment><USER6> This is a nice tale of redemption for MS.

Going back, they weren't always the ruthlessly cynical bad asses that saw out the last century. They let the desire to win at all costs cloud their vision.

Their time in the penalty box, incurring the opprobrium of much of the IT community, has done them good. They're a corporation, so nothing is done from the good of their heart, but at least now they've recognised it's possible - necessary in fact - to play nice with others rather than stealing their lunch money as their first instinct.

</comment><comment><USER7> They should have kept the Kinect integral to the platform and doubled-down on it -- that thing was fun and worked great (still play those games w/my son), and it could have been a great conversational agent gateway with way more functionality than we have now, well before Alexa et al. w/o the Kinect, the x-box may as well be a PS/x or PC AFAICT.

</comment><comment><USER8> Microsoft is killing all businesses except one?

Would that be Apple or Amazon?

</comment><comment><USER9> Considering mobile isn't it "all but two"?</comment>


How Thou Canst Maketh a Fine Program in Fortran - <AUTHOR> https://www.digitalocean.com/community/tutorials/how-thou-canst-maketh-a-fine-program-in-fortran <comment><USER2> Needed more [https://en.wikipedia.org/wiki/Long_s](https://en.wikipedia.org/wiki/Long_s)

Turns

In troth, the Fortran programming language is well suited for those persons who are scientific and who engineer. Named so for the phrase "Formula Translation," it is a language exquisite for programming machines.

into

In troth, the Fortran programming language is well suited for thoſe perſons who are scientific and who engineer. Named so for the phraſe "Formula Tranſlation," it is a language exquiſite for programming machines.

Way better.

<comment><USER3> Bonus points if he had used þe for the in a few places...

<comment><USER4> she

</comment></comment></comment><comment><USER5> Author, I pray ye learn Early Modern English verb conjugation, the declension of "thou", and how the occurrence of periphrastic "do" changed with the era, that your titles, headings, and text might fall easily upon the eye and mind of the reader.

(Seriously, nice post, and well done on the title graphic font choice.)

</comment><comment><USER6> Author missed a trick by not using a font with a long S. Also had some trouble declining thee/thou/thy, which is admittedly hard for a modern speaker.

<comment><USER7> What were the issues with the declensions?

<comment><USER8> Not the parent, but "your machine" should probably be "thy machine." "Thou compiler" should be "thy compiler." In general, mapping from 3rd to 2nd person, "he" = "thou", "him" = "thee", and "his" = "thy."

I believe "thou doth do" should just be "thou doth" but I could be mistaken about what "doth" is. :)

<comment><USER9> Just to share something I think is fun:

Modern German has separate formal and informal pronouns ("du bist" vs. "Sie sind") and verbs. English used to have them too ("thou art"/"you are"). Even though people assume "thou" is more formal, it's actually the informal/intimate version.

[https://en.wikipedia.org/wiki/Thou](https://en.wikipedia.org/wiki/Thou)

Apparently we (~Angles/Saxons) also used to have a separate tense for "a group of exactly two of you" and words like "both" (vs all) and "either" (vs any) are residual traces of this.

[https://en.wikipedia.org/wiki/Dual_(grammatical_number)](https://en.wikipedia.org/wiki/Dual_\(grammatical_number\))

<comment><USER4> I have always enjoyed the insult "I thou thee thou traitor" offered to Sir Walter Raleigh, presumably just before he was executed. There is a semi- plausible explanation of how thou died out in England

[https://www.quora.com/English-language-Why-did-people- stop-u...](https://www.quora.com/English-language-Why-did-people-stop-using- thee-thou-hath-shalt-thy-etc-in-writing)

but it leaves open the question why it persists in other languages.

</comment></comment></comment></comment></comment><comment><USER10> I'm thoroughly surprised to see that Fortran is still being updated (with an upgrade still in the works for next year apperantly). I had no idea.

I'll give it a shot as it seems interesting to at least have worked in it a bit, but I do wonder, where is Fortran used these days?

A quick glance at Tiobe[1] shows that it scored a bit higher than Haskell, Scala and Kotlin. Can anyone explain me why?

[1]: [https://www.tiobe.com/tiobe-index/](https://www.tiobe.com/tiobe-index/)

<comment><USER11> Personal experience: My general language-to-go is Python, and I'm very fond of Rust. But Fortran has no competition in numerical computing at native speeds in terms of convenience. I was just recently rewriting a small Fortran library (that I usually but not always call from Python) to C, and it was a pain. So, as a result of that, Fortran is still used heavily in scientific computing. (On the other hand, Fortran is a pain for anything else than numbers and arrays.)

It is also the only language I'm aware of that has a special syntax for distributed memory [1], making parallel distributed computing potentially extremely convenient.

[1] [https://gcc.gnu.org/wiki/Coarray](https://gcc.gnu.org/wiki/Coarray)

<comment><USER12> What do you think about Julia language? It's a modern take on a language for number crunching that has support for C and Python code. Also uses some Fortran libraries that are optimized.

[https://julialang.org](https://julialang.org)

Far as distributed, see Cray's Chapel and Taft's Parasail for languages trying to improve on that. Chapel's competition was IBM X10 and Fortress languages. Im not sure if those two are maintained any more, though.

</comment></comment></comment><comment><USER13> maketh is 3rd person singular, but should be an infinitive. cutesy middle english "fail"

<comment><USER14> Translates to the Gollum-esque "You can makes a fine program in Fortran"

lol

</comment></comment><comment><USER15> I guess I was expecting a little more substance to the post. It seems like a long-winded for the little substance in it.

<comment><USER4> I think it was an April 1 post and served its purpose well I would say!

<comment><USER15> I didn't even look at the date! /me facepalms

</comment></comment></comment><comment><USER16> What?!?!?! No separate linking step?!?!?! Heresy, says I.</comment>


Hackerfeed for News.YC - <AUTHOR>

http://ycfeeds.com/hackerfeed
Somewhat similar to friendfeed for News.YC. Its going to be slow because I need you guys to warm up the cache for me.
The AJAX features ("more", "replies") are currently disabled but should be working by this time tomorrow, also previous and next pages are in the works. I'm off to YC meetup in Cambridge, enjoy and don't break it. <comment><USER2> This is neat, not something I would actually use, but neat. Well designed and easy to use. I went to the page and instantaneously understood what it was for. Which, in my mind, is the sign of a well designed and good application. Nice work.

</comment><comment><USER3> Simple. Functional. Fast. Thanks!

I actually like the fact you can look at feeds and see deleted and changed posts. With observation and a little comparison, you can see the revision process (or lack of) for (your favourite) users.

</comment><comment><USER4> _"... Somewhat similar to friendfeed for News.YC. Its going to be slow because I need you guys to warm up the cache for me ..."_

Works fine for me, no delays. I'm still impressed with the personal RSS feed. With comments this makes it even better. Well done.

</comment><comment><USER5> Did you ask for permission to crawl news.yc? (see <http://news.ycombinator.com/item?id=271119>)

<comment><AUTHOR> no i did not.

I'm not crawling the entire site, just enough to get the data that is needed. I think the app would still work if my ip was throttled anyways, albeit new items would show up on feeds later (but the app response time would be quicker).

</comment></comment><comment><USER6> Will it work if I add <http://ycfeeds.com/hackerfeed?user=jfornear> into my friendfeed?

EDIT: I guess not, but you should add friendfeed support :D

<comment><AUTHOR> You want to look at <http://ycfeeds.com>

</comment></comment><comment><USER7> This is seriously cool. It's a fantastic idea and the implementation is great.

</comment><comment><USER8> This is awesome. Gonna put a comment feed on my blog :) Thanks!

</comment><comment><USER9> I love it. Great visualization. Nice work.

</comment><comment><USER10> Cool hack.. keep it up. :)</comment>


Gunsmith Uses 3D Printer To Make A Rifle - <AUTHOR> http://www.webpronews.com/gunsmith-uses-3d-printer-to-make-a-rifle-2012-07 <comment><USER2> Any competent machinist can make functional semiautomatic weapons. This is just the next step in making it even easier.

If the United States ever got serious about banning firearms, a massive homebrew industry would grow up overnight. Gunpowder is not fundamentally harder to make than methamphetamine.

People who quite rightly see our drug laws as pointless and ineffective somehow often miss that a gun ban would be no more effective in the United States. If you want there to be less drugs or guns, you have to attack the demand side, not the supply side. Suppressing supply while keeping demand steady just ensures higher margins for the suppliers.

<comment><USER3> > If the United States ever got serious about banning firearms, a massive > homebrew industry would grow up overnight.

Do you have any stats or experience to back that up? It might happen, but you are stating as fact something that's not been tested.

Anecdotally, in Australia where gun laws are very strict, it's difficult to get firearms. Yes, serious hardened criminals still get their hands on them, which certainly is a problem. The average angry Joe can not simply legally purchase a semi automatic or handgun to walk around to his antagonists house and shoot them.

With a murder rate twice any other developed country[1], the United States clearly has a serious violence problem, and taking guns out of the hands of the average Joe would surely help reduce it.

[1][http://en.wikipedia.org/wiki/List_of_countries_by_intentiona...](http://en.wikipedia.org/wiki/List_of_countries_by_intentional_homicide_rate)

Using the argument of "Hardened criminals will still get them anyway" is like saying we shouldn't have a law against murder because some people will do it anyway, so it's a waste of time. The point is to deter or make it extremely difficult for as many people as possible.

<comment><USER4> _With a murder rate twice any other developed country[1], the United States clearly has a serious violence problem, and taking guns out of the hands of the average Joe would surely help reduce it._

The second clause does not follow from the first. Murder in the US is heavily demographically biased, and most gun owners are not murderers. Furthermore, will you be the one going door to door to collect everyone's firearms? It sounds like you are saying, "Surely, we must do something. This is something; therefore, we must do this."

 _Using the argument of "Hardened criminals will still get them anyway" is like saying we shouldn't have a law against murder because some people will do it anyway, so it's a waste of time. The point is to deter or make it extremely difficult for as many people as possible._

No, no it's not. You are conflating possession of a tool with misuse of the tool to commit a crime. The US has been trying to make it "extremely difficult for as many people as possible" to do a lot of things, and failed spectacularly. Now imagine that same level of failure applied to something protected in the US constitution.

<comment><USER5> To be fair, this tool has only one use: it kills things.

Whenever I see arguments about how we should ban cars because they kill more people than guns per year, I always think about that. Cars are good for all kinds of things, and they happen to incidentally cause death. Guns are pretty much only good for killing things.

I live in the U.S. I'm not saying we should uniformly ban all weapons, period; I think the issue is more nuanced than that. But it seems hard to defend the fact that introducing guns into a dangerous situation would do anything other than make it more deadly.

<comment><USER6> > To be fair, this tool has only one use: it kills things.

I disagree. A gun's primary use for law abiding citizens is that it intimidates things. The most effective way to use a gun is simply to deter crime.

You wouldn't say that the reason the United States and the Soviet Union stockpiled nuclear weapons was because they wanted to level each others' cities. It was simply deterrence.

<comment><USER7> > A gun's primary use for law abiding citizens is that it intimidates things. > The most effective way to use a gun is simply to deter crime.

A purpose they are quite clearly failing at. So the question is what, if anything, citizens of the U.S.A. wish to do about the fact that, empirically, legality and availability of guns has not resulted in crime rates comparable to comparable states.

<comment><USER8> That doesn't follow. There are no comparable states with a comparable history, demography, economy, and culture.

It's possible that gun ownership deters crime, but that something else unique to the U.S. is causing more crime than gun ownership is countering.

The only thing you could possibly do is to compare parts of the US to each other, and in that case you'll find that locations with stricter gun laws have _more_ gun violence.

You could conclude that gun laws cause gun violence, but that would be stupid because many times gun laws exist because of gun violence. What's the difference between my conclusion and yours?

Concluding that guns cause violence without real hard evidence and subsequently banning them is like using the unproven gateway drug theory to justify locking up people for smoking pot.

<comment><USER7> Ah, yes, the U.S. exceptionalism. No other country like it! No one else could have an invasive dominant culture, a disadvantaged minority group, large prosperity divides, and a God-given fear of groups of other people (you call it "government").

Oh well. It's no water off my back if you guys are fine with answering my original question with "nothing" and continuing shooting each other up as price of freedom.

<comment><USER8> >There are no comparable states with a comparable history, demography, economy, and culture.

American exceptionalism refers to the primarily used meaning of exceptional as "unusually good." I never remotely said that.

America is different, not better. I'd also argue that you can't compare Germany to Spain. Does that mean I think Germany is better?

You also didn't answer my argument. Can you point to another country with comparable history, demography, economy, and culture that has passed a gun ban. Or should I just go ahead and hand over my gun, based on your unsupported fears?

<comment><USER7> > American exceptionalism refers to the primarily used meaning of exceptional > as "unusually good."

I am aware. It's fun to use terms outside of their usual meanings sometimes.

I am not supporting a gun ban in the U.S. I'm asking what y'all wish to do about your crime rate.

<comment><USER8> >I'm asking what y'all wish to do about your crime rate.

End drug prohibition.

<comment><USER7> Would be a start!

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Doesn't pass the sniff test.

Chamber pressure in a .22 cal pistol is on the order of 20,000 PSI [1] The tensile strength of thermoplastic at standard temperatures is 1/2 that [2] and it goes down as the temperature goes up (its a _thermo_ plastic for a reason). Firing a .22 caliber round using gunpowder would destroy the barrel on the first firing.

Now I could believe you built the receiver and triggering mechanism on a thermoplastic printer, but not the actual firing chamber.

[1] <http://www.lasc.us/SAAMIMaxPressure.htm> [2] [http://www.engineeringtoolbox.com/physical-properties- thermo...](http://www.engineeringtoolbox.com/physical-properties- thermoplastics-d_808.html)

<comment><USER10> The part that's 3d printed is the lower receiver. In an AR-15 style design, the lower receiver doesn't handle any pressure at all, it just houses the magazine and hammer/trigger/sear/safety, and connects to the upper receiver/barrel assembly and the buttstock/buffer tube assembly.

People have made lower receivers out of aluminum basically forever. Aluminum could maybe be made to handle .22lr type pressures, but certainly not .223rem or bigger. A plastic lower is completely believable.

EDIT: to clarify, I meant if you wanted to make the _whole gun_ out of aluminum you might be able to get away with it for a .22lr. Aluminum for a lower receiver is absolutely no problem at all. Apologies for not being clear.

<comment><USER11> If I recall correctly, the lower is also the only part of the assembled weapon that requires registration.

<comment><USER12> Incorrect. The lower is the only part of the assembled weapon upon which a serial # is applied and a tax is paid. It is also the # that is recorded on the Form 4473 at the dealer when you purchase the weapon.

There is no federal level firearms registration (excepting NFA items), and only a few states that do so as well.

<comment><USER12> Oh, and if you build it yourself (as this person has done), no tax need be paid, no serial # need be applied, and all perfectly legal provided you have not been restricted from purchasing a weapon through normal channels. That is, a felon making a weapon is now a felon-in-possession, where a citizen with full rights making one has not committed a crime.

<comment><USER13> It is recommended that you do apply a serial number because LEO may incorrectly conclude that the firearm is illegal if they don't see one.

<comment><USER12> Yes, but there is no requirement to do so. Nor is that serial # available anywhere to look up.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> I might be reading it wrong, but it looks to me like he printed a receiver and placed all the moving parts and the barrel etc. in it. See "I printed a modified version of the lower from cncguns.com"

<comment><USER15> The receiver is the only part of the rifle that is controlled. Everything other than the receiver can be bought on the internet without background checks or registering of serial numbers.

<comment><USER14> Yes, I know that part, I was simply pointing out that he did not necessarily print out a barrel or trigger pin or any of the other many parts needed to make a whole pistol.

</comment></comment></comment><comment><USER16> A long post on the topic of CNC, printing firearms, and more from a few months back:

[http://www.popehat.com/2011/10/06/the-third-wave-cnc- stereol...](http://www.popehat.com/2011/10/06/the-third-wave-cnc- stereolithography-and-the-end-of-gun-control/)

</comment><comment><USER17> To be clear: he made a lower receiver, a very simple part and the one that has the serial number stamped onto it, it is the "gun" part as far as the legal authorities are concerned.

Every other part (upper receiver, barrel, magazine, trigger, hammer, etc) are just "parts" that one can order untracked.

Making an entire functional weapon is still beyond the scope of most inexpensive printers.

[http://www.quora.com/3D-Printing/How-much-does-it-cost- today...](http://www.quora.com/3D-Printing/How-much-does-it-cost-today- June-2012-to-purchase-a-3D-printer-that-can-print-all-of-the-parts-to- assemble-a-functional-AK-47) (my question about this on Quora.)

</comment><comment><USER18> I love how HN jumps immediately into a gun control debate and almost completely misses the fact that what he printed is a long way from an AR-15. It's just a piece of metal called the lower receiver. When I say lower receiver, I believe he built just the shell not the trigger assembly or bushings. In addition, the bolt and barrel (the upper) weren't manufactured. But lets assume for a minute that he printed the entire thing from scratch, how is this any different than the fact that anybody with a good machine shop can produce a full AR-15 by hand?

</comment><comment><USER19> Well, it's definitely possible to print a silencer, a pistol shouldn't be that much harder. I'm afraid that this would make the governments impose stricter laws on 3D printers, which is not a good thing...

<comment><USER20> I'd be more scared if they could successfully manufacture lethal ammunition.

<comment><USER21> Then you don't understand the current market. Most ammunition is amazingly easy to come by and the trade of it is fairly unregulated.

<comment><USER20> Wow, in that case this is very scary.

</comment></comment></comment></comment><comment><USER22> Seriously, what happened to real journalism?

Articles are now being written based on a handful of unverified forum posts. Really?

<comment><USER23> 1) Betabeat isn't the NY Times.

2) Betabeat only reported that this forum existed and that someone had made these claim, which is indisputably correct. You may think it's not particularly news worthy, but online journalism is a big places and there's plenty of room for everything.

3) Would you rather this article _not_ be written?

</comment></comment><comment><USER24> Man, they didn't show you _that_ in Star Trek...

edit: to be specific, they glossed over it instead of confronting a scenario where an enemy hijacked a replicator to make whatever physical or chemical weapons they wanted at a moment's notice.

<comment><USER25> Actually it was touched on in a number of episodes (which i don't feel like digging up) but in more than once instance they mentioned that the replicators had safety systems that prevented unauthorized creation of at least some dangerous materials, (from what i recall, poisons were mentioned in one, weapons themselves i'm not sure).

<comment><USER26> True, but what could be poisonous to one species, could be nutritious to another. The idea that 'poisons' are easily identifiable is pure fantasy.

<comment><USER27> Everyone on the Enterprise can breath the same air and eaet the same food.

And if something is poison to even just a few of your crew, you forbid it and tell everyone else to eat almonds instead of peanuts. :nerdingout:

<comment><USER24> A lot of things were "forbidden" by social pressures. Alcohol was freely available (or maybe a simple security override, I can't remember) but no one drank real alcohol.

</comment></comment></comment></comment></comment><comment><USER28> 1.) Blogspam. OP is [http://www.webpronews.com/gunsmith-uses-3d-printer-to- make-a...](http://www.webpronews.com/gunsmith-uses-3d-printer-to-make-a- rifle-2012-07)

Does HN have any mods?

2.) Have blue has a blog, he's written two posts about this: <http://haveblue.org/?p=1041> <http://haveblue.org/?p=1321> It appears to be down right now, though. Cache links: [https://webcache.googleusercontent.com/search?q=cache:DlBe32...](https://webcache.googleusercontent.com/search?q=cache:DlBe32HJ0UsJ:haveblue.org/%3Fp%3D1041+&cd=1&hl=en&ct=clnk&gl=us&client=firefox-a) [https://webcache.googleusercontent.com/search?q=cache:Z_5bOF...](https://webcache.googleusercontent.com/search?q=cache:Z_5bOFtsttMJ:haveblue.org/%3Fp%3D1321+&cd=1&hl=en&ct=clnk&gl=us&client=firefox-a)

3.) He printed a AR-15 lower receiver, which is the part, under US law, considered a "firearm". The high pressure components (barrel, bolt) are all made from conventional manufacturing processes, using steel.

Lowers are typically made out of aluminum, but they don't really experience any great stresses, so it's perfectly possible to make them out of plastic. (There's a number of commercial lowers made out of fiberglass: <http://www.mdshooters.com/showthread.php?t=65134> (I'd link directly to the manufacturer's site, but it seems they're better at making guns than they are at securing web servers)) As he notes, people have even carved them from wood.</comment>