179 karma · joined October 30, 2019
Of course human directed selection is a thing, when did I ever say otherwise? This is the problem with the Sagan types, you actually think that baloney is fine as long as it's sciencey-sounding baloney.
> I don't think it is? I think there's a difference between the plausible but wrong and the impossible.
I find that the word "magic" is very overused by smart people online as a sort of thought-terminating cliché. It's a vague concept and I'm not always sure what they mean by it.
It's often extremely hard, even for top minds, to tell apart magic and science ahead of time. Think of Einstein mocking quantum physicists for believing in "spooky action at a distance". Of course if you still don't believe in quantum entanglement today then you are being irrational, but that's only because science has (mostly) settled the question, nothing to do with how magical or plausible the concept may sound.
Someone defending astrology will tell you that the gravity of the moon affects their bloodstream like it affects the tides of the ocean. That doesn't hold water if you sit down and do the math of course, but the same is true if you bother to check the dates for events in ancient history.
> Believing silly nonsense which is still plausible isn't the same category of error as believing in magic.
Eh, hard to say what is magic and what is not. Sagan's beliefs about the ancient world could have been fixed with a five minute conversation with an expert. He just didn't care enough to do that, and for some reason that attitude is common among so-called skeptics when it comes to history.
That function doesn't actually have an integral in any sense that I know of. The Riemann integral doesn't work because, for every interval in every possible partition, the function's upper bound will be 1 and the lower bound will be -1.
https://web.archive.org/web/20181123085448/http://www.contro...
That's actually extremely cheap by international standards, if this source[0] is to be trusted. Of course it seems expensive for most argentinians because wages are also terribly low.
[0] https://www.numbeo.com/cost-of-living/country_price_rankings...
> I'm simply disputing your general claim that moving away from C would not help
I never said such a thing, I said we don't know. As always, in theory, there is no difference between theory and practice; in practice, there is.
[0] https://www.theregister.com/2018/02/16/apple_file_system_bug...
I don't see where this is coming from. Most of the world's top filesystems are written in C, and they work just fine. Maybe other languages could get better results, but it's hard to say with so little data.
> implementation knowledge about file system technology is generally stuck in the 1990s
If you are talking about me, that might be true, I'm relatively new to this and still learning. But there's definitely people out there with some serious "implementation knowledge". And tools like xfstests did not exist in the 1990s, that makes a huge difference.
That said, there's nothing stopping you or anyone else from reworking my code into a (gpl-licensed) FUSE driver. I don't think it's a straightforward task, but it can definitely be done.
How hard this is, it depends on the filesystem. Something like FAT, for example, is pretty much designed for ease of implementation, with few edge cases. Modern filesystems are not like that at all, the data structures are very complicated, so they must be extremely well tested before they are good enough to use. That would probably require an fsck to check for subtle inconsistencies; in the case of APFS you can use mine, but it's still very incomplete. Apple's published fsck is not very thorough.
As an example of the kind of problems to expect, I recall a bug in the Linux HFS+ driver. If you had a drive with lots of short filenames and lots of long filenames, and you started deleting the short filenames, eventually you would lose half of your files. This kind of things happen because HFS+ has variable-length keys in the index nodes of its trees, so deleting a record may trigger a complicated cascade of node splits. APFS inherited this feature, and it was very annoying to implement.
But HFS+ is very well documented; APFS is not, and that doesn't help.
How far along is this? I think she's underestimating how hard it is to implement a modern filesystem that won't eat users' data. I've been working on a Linux APFS driver[0] for several years, and it's not fully functional yet. It's a pity that she is working with FreeBSD, or it could have been of use to her.
Email: hn.eafer@gmail.com
I'm a programmer, most familiar with C on Linux and Win32. I'll be happy to start a project from scratch, or to help support any old codebase. For a sample of my work please see rdrview [1], a small command line tool that found some success here on Hacker News; or [2], a naive filesystem implementation I've been working on.
My current rate is 20 USD/hour. For what it's worth, I have a background in math.
Email: hn.eafer@gmail.com
I'm a programmer, most familiar with C on Linux (both userland and the kernel) and Win32. I'll be happy to start a project from scratch, or to help support any old codebase. For a sample of my work please see rdrview [1], a small command line tool that found some success here on Hacker News; or [2], a naive filesystem implementation I've been working on.
My rate is 20 USD/hour, and I don't expect to be paid until I have something to deliver. For what it's worth, I have a background in math.