Location: Honolulu, HI

Remote: Yes

Willing to relocate: Yes (Within US)

Technologies: Java, Scheme, Python, C, C++, dabble in Rust, Git, Atlassian Tools (usage and admin), Spring Framework, TestNG, Linux, FreeBSD

Résumé/CV: https://drive.google.com/open?id=0BxAQdyUW7NZFS1lyOGlGNXJBS3...

Email: dongie.agnir@gmail.com

Website: blog.dongieagnir.com

I'm looking for a challenging work place, preferably where I can work in small teams where I feel like I can make a big impact. I've mostly done backend development work, but I'm also willing to transition to more full stack development.

Almost all laptops these days come with SSDs and last I checked, OpenBSD doesn't support TRIM. Has this been fixed? Is lack of TRIM a non-issue?

Due to TRIM bugs I just follow an advise of never using it. Rather I set aside like 5% of disk that is never touched. This works with both old and new SSD without affecting long-term performance on laptops. As an added bonus it makes full-disk encryption more sound.

I thought SSDs were integrating TRIM into the drive's firmware/controller nowadays.

That's impossible (AFAIK at least) - the drives can't know what parts of the filesystem are in use, only the OS can.

A quick Googling shows it exists only in high-end SSDs, but the information is from 2013.

Just anecdotally, my Nexus 9 does not even have the fstrim command anymore, nor do I see any discard options in the fstab. My Nexus 7 2012 had lots of interest about fstrim improving performance, but not my Nexus 9. I assumed the TRIM issue had disappeared.

Uhh... The nexus 7 and 9? You realize those have SD and MMC cards soldered to the motherboards and work /entirely/ unlike an SSD, right?

Also, the OP is right: TRIM works by telling the SSD which blocks that were previously used are now unused, so that the SSD, at a lower level, can eventually erase the larger flash sector. There is literally no way for the SSD to know this intrinsically because SSDs do not expose a filesystem interface.

Regardless of the differences, the Nexus 7 used trim (introduced in Android 4.3) on it's flash-based (SSD also uses flash) solid-state memory and my Nexus 9 does not. The trim "bug" is well known for some Android devices, but now it has died off. I was attempting to guess why.

Another quick Googling seems to say improved garbage collection (in the SSD itself) has lessened the need for fstrim.

Hopefully someone who is knowledgeable will chime in.

trim is implemented in the controller in that a controller implementing trim is capable of receiving, understanding and acting upon the trim command. It's actually issued higher up in the stack; I've only ever seen it mentioned in the context of an OS issuing the command to the drive if a file on a filesystem on the drive is deleted, or if a utility intended to issue trim against all empty blocks was run.

You're correct in that trim is less necessary if a drive has good garbage collection. I don't know anything about the implementation of either, but I would expect trim to be easier, cheaper and better than GC. It seems like GC would require work to discover/remember things provided as input w/ trim. I've assumed that GC was only implemented by vendors in their controllers because trim wasn't available in the popular OSs yet, and/or because their controllers were already doing most of the work required by GC anyway so it was cheap to implement.

Finally, you can't equate SSDs with the SD or eMMC used in some of the phones/tablets. Yes it's all flash, but an SSD is typically multi-channel with many flash modules, a DRAM cache and a much more sophisticated controller implementing a standard storage interface (AHCI/SATA or SAS or NVMe). eMMC and SD are much simpler, cheaper and slower.

My point was that they are equal from the fstrim perspective.

Not saying that you're wrong, but SD cards for example assume that they're going to be running FAT and make assumptions/optimizations based on that.

http://www.tedunangst.com/flak/post/lessons-learned-about-TR... I do believe it supports trim, since 2011. Need to check the code if and how it's implemented today. I'm using 2 SSDs in a RAID-0 with OpenBSD for 1 year now. No problems and lightning fast.

Been using an SSD in my laptop for 6 months now... UFS / FFS doesnt really seem to fragment that much

# fsck / | grep frag 6395 files, 106651 used, 409612 free (300 frags, 51164 blocks, 0.1% fragmentation)

# fsck /usr | grep frag 396741 files, 4832173 used, 19820289 free (4953 frags, 2476917 blocks, 0.0% fragmentation)

# fsck /home | grep frag 1192199 files, 27780639 used, 3176062 free (216374 frags, 369961 blocks, 0.7% fragmentation)

The effect of fragmentation on file systems on SSDs is minimal, and fragmentation is not related to TRIM. http://askubuntu.com/a/537211/1624

I've made small code contributions to Firefox and Servo, both Mozilla projects, and I have nothing but good things to say about everyone involved with the two projects. As a newcomer to both, the respective teams were very welcoming, helpful, and most of all, patient especially during the review process.

I'm wondering the same thing. In the announcement, they say "two more than MBP" so I'm hoping it's a quadcore

The comparison bewteen the total LOC across all of Google's products against just one of Microsoft's is a bit unfair.

It's been discussed before, but that's not really quicksort though (since it's not in-place)[0]

0: http://stackoverflow.com/q/7717691/1235548

Do we know that for sure? I mean - could a sufficiently smart compiler actually create machine code which _did_ do it in-place?

The Berkeley AI class on edX[0] covers this, and other related algorithms, like alpha-beta pruning. It's a very fun class; recommended for anyone interested in this sort of thing

[0]: https://www.edx.org/course/artificial-intelligence-uc-berkel...

Isn't the first example undefined behavior? I always thought you shouldn't assign data to a union using one member, then access the data using a different member.

IIRC it was undefined behavior until C99. Then it became implementation-defined.

IIRC, LMAX Disruptor[0] uses the same concept with its ring buffer to avoid GC-related slowdown.

[0]: https://github.com/LMAX-Exchange/disruptor

While it does avoid GC, it's mostly a faster way to share data between threads than the builtin concurrent collections.

Yep, that's what Disruptor is for. Here's a blog post by one of the devs giving more details about the ring buffer where she specifically mentions that objects are pooled to avoid the GC http://mechanitis.blogspot.com/2011/06/dissecting-disruptor-...

Very cool! I've been working on the microcorruption CTF myself, and it inspired me to work on a MSP430 emulator. From the newsletter that the folks at Starfighter sent out a few weeks ago, emulating the AVR is tricker so kudos to you.

Cool!

To be fair, we've only implemented 7 opcodes out of ~150 so far. But thanks!

OK that makes me feel much better about mine. I have about 20 instructions left to do.