I wonder how well Sagan's own "baloney" holds up against his kit. Historians despise the guy for all the stuff he made up about the library of Alexandria, Hypatia, Eratosthenes, etc... People still repeat a lot of that to this day.
Sagan made solid contributions to Planetary Science in the 60's and 70's.
His role as PBS educator, SF author, etc. needs to be considered as a separate thing.
I also loved James Burke and his Connections series, but as it got into the later seasons the so-called "connections" got tenuous and sometimes quite strained.
You can go through all the classic PBS science shows and find problems, Stephen Hawking's Universe was basically unwatchable because they refused to engage with the math.
People like Sagan have a worldview in which we are all either rational robots that only believe in "science", or else silly magic-believers that can't think by themselves. Of course Sagan himself proves that this is wrong: you can be a great scientist while believing a lot of silly nonsense about the ancient world, and about crab evolution apparently.
I actually kinda like Sagan, Cosmos is seriously gorgeous (though Vangelis does a lot of the heavy lifting there). I'm just kinda tired of the whole "Library of Alexandria" myth that comes up constantly around nerdy forums such as this one.
> 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.
I had to look up what specifically Sagan's errors about history were and yes it looks like he popularized a lot of bad mythology (I referenced this site[0]). I have to admit I believed a lot of this myself at one time. But I think there's a difference between the plausible but wrong and the impossible. If he'd said he thought Atlantis was real, or gone on about Tartaria or the great Ice Wall, that would be a lot closer to magical thinking.
Although it is a lot easier to be led astray by plausible lies than implausible ones. It seems like Sagan is certainly guilty of not being critical about narratives that reinforced his worldview.
> 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.
"As I write, the number-one videocassette rental in America is the movie Dumb and Dumber. “Beavis and Butthead” remain popular (and influential) with young TV viewers. The plain lesson is that study and learning—not just of science, but of anything—are avoidable, even undesirable.”
Mike Judge's satire was lost on Sagan. Carl took his knee-jerk reaction and ran with it.
I think it was lost on a lot of the audience at the time as well, who saw Beavis and Butthead as cool rather than a critique of anti-intellectualism. That's the problem with satire in general -- no position is so absurd that somebody won't take it at face value rather than satire.
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 think "made up" is fair. I can't know what his process was and everybody makes mistakes, but almost every single thing he said about history was wrong in a way that was convenient to his narrative, and it's not like he ever retracted anything. Surely if he wrote a whole book about dealing with bullshit he could have used that opportunity for some reflection about his past mistakes, now that would have been interesting to read.
Do you have a specific source for this claim? I have read through what someone else posted in this thread (https://talesoftimesforgotten.com/2020/02/05/carl-sagan-was-...) and while some details are indeed incorrect, a lot of it is nitpicking or common misconceptions from his time.
You think it's nitpicking because you don't care much about truth when it comes to history, and that's perfectly fine. But it's weird to complain about other people's baloney while spreading your own, and I think in his position as a trusted science communicator he should have been more responsible about this stuff.
No, I think it's nitpicking because it truly is in some cases. Science communication is about simplifying things and making shortcuts while keeping things engaging. Of course Sagan didn't go into a tangent about the first use of the word barbarians or whether ancient greeks would define robots the same way we do. That's pedantic.
There are a few good examples of significant errors in the link I cited which I think are substantial - the portrayal of Hypatia is a big one. I just wondered whether there were more discussions about other history topics he got wrong, since you yourself mentioned that "almost every single thing" he said was wrong.
I loved watching Cosmos when I was a kid but as I got older I developed a dislike for Sagan. He strikes me as supremely arrogant and probably insufferable to be around. I don't know that of course, I never met him. Just a feeling.
> I wonder how well Sagan's own "baloney" holds up against his kit. Historians despise the guy for all the stuff he made up about the library of Alexandria, Hypatia, Eratosthenes, etc... People still repeat a lot of that to this day.
Yeah, but he's a saint of science-fandom, so don't question him. Instead, admire and follow him, and encourage others to do likewise.
> yet its integral over any interval is exactly zero
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.
Oh. Er... I didn't really consider whether it could be proven to have an integral, I just went off of intuition. After an additional lifetime of study, magically compressed into 15 minutes of skimming Wikipedia articles, I'm going to (tenuously) claim that the function is Lebesgue integrable. Heck, if it works for the {0 if irrational, 1 if rational} function, this should be much easier. I hope?
My original intuition is that every value in [0, 1] will be cancelled by a value in [-1, 0].
My updated intuition to make it more Lebesgue-compatible would be to sort the (infinite) set of values in the interval. This will give the everywhere continuous, linear function from -1 at the minimum coordinate of the interval to 1 at the maximum coordinate.
Hm... I notice that when applying Lebesgue to Dirichlet, it uses countability, and reals aren't countable. I have no clue whether that's a problem here or not.
It won't be Lebesgue integrable because it won't be measurable. Your function is actually a good (though not rigorous) argument for the existence of non-measurable sets.
That's for uniform distributions. We don't know the distribution here, that's part of the problem, but I would expect early cave art to be more sparse and worse preserved.
Wouldn’t it make just as much sense that once a site reaches X age it will likely make it to 10X since the conditions that allowed it to get to X are slow to change?
> And milk can get pretty expensive pretty fast in this country: It always come in 1 litre recipients, and the cheapest one (The one that is within the mentioned program) is right now at ~70 pesos (Some 73 dollar cents at the official dollar price, 40 cents at the current rate for the dollar in the back market... but foreigners can hardly get this price for their dollars).
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.
Thanks for the link; This was something I wanted to see.
All in all, I doubt that number is entirely accurate. Argentina is a _very_ large country, and even the minimum price varies greatly depending on the region.
I have family in Patagonia, for instance, and they tell me it's impossible to get the cheap milk brand over there.
> compatible with macOS filesystems (HFS+ and APFS)
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.
FreeBSD differs quite substantially from the XNU kernel used by MacOS because XNU is based on Mach, and it was forked (Edit: from 4.3BSD) in 1988 - before Linux even existed.
The XNU kernel does not have a stable syscall ABI so perhaps it doesn't matter if the syscalls are different because the implementation of libSystem can convert as appropriate in userspace (see also: WINE).
By the time Apple got to them it was a few years later, and so they decided to updated that part of the kernel, and also brought in FreeBSD's userland.
I don't think I can, I'm using gpl code from other parts of the kernel. I'm not sure I would want to either, I put a lot of work into this and the gpl gives me more of a feeling of ownership.
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.
Syscalls are mostly the same, but indeed, the interface between the kernel and the file systems is very different. However, code which implements that interface on the file system is a relatively small part of the whole thing; most of the code should be reusable.
Historical note: FreeBSD used to support XFS; I believe it was ported from Linux.
The main problem is simply that people really really really don't like losing their data after they saved it to disk. A simple app that corrupts its in-memory state once a year is probably acceptable. A filesystem that corrupts its on-disk state once a year is pure garbage. You basically need to aim for zero bugs.
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.
It's worse than this. You not just need to aim for zero bugs, but zero bugs despite working with hardware that can degrade with use and who's firmware often does have bugs.
And yet this didn't stop Apple from automatically converting HFS+ volumes to APFS in iOS 10.3 and macOS 10.13.0 soon after the APFS beta dropped in macOS 10.12.5 and it didn't stop Apple from requiring APFS for all volumes in macOS 10.14+. Apple must have been pretty confident that APFS was working reliably to be so bold.
Not sure why you are telling me this, I don't know anything about Apple's internal development process. I assume they did run a lot of tests. But I recall at least one serious bug early on too[0].
> C being a shitty language that does not force or even encourage programmers to handle errors
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.
I'm curious why you think file systems written in C would somehow be better than any other type of program written in C. We have plenty of data suggesting C programs have more bugs and vulnerabilities than programs written in safer languages.
If you are thinking about rust, we don't have any data about it in the context of the kernel yet, not even for device drivers. It may prevent some exploitable bugs, but those aren't a big concern for filesystems - otherwise they wouldn't be put inside the kernel at all. The reality is, we don't know if it would help; and given how conservative we all are with our filesystem implementations (for good reasons), it's possible that we never will.
I'm not thinking about anything specific, I'm simply disputing your general claim that moving away from C would not help, when it has clearly helped in every single other domain of software development. I see no real reason why file systems should be any different, but clearly you do, so I was asking you why you think file systems would be different.
And for specific examples of options with better safety records, then sure Rust would be one possibility, as would Ada, or Frama-C if you need to stick with C.
However ReactOS has a more challenging/bigger goal for a few reasons. It aims to be binary compatible, not just source compatible. Much more of the underlying tech is proprietary while the BSD subsystem on macOS is free for them to use.
Oh, I wasn't trying to diss FreeBSD. It would probably have been better to write my driver for fuse to make it portable, but it's too far along at this point.
Out of interest, why can't file system implementations be portable? A shared core that exists as a library that can be tested in userland, and which can then be used by a lightweight shim that implements the kernel-facing interfaces. But I haven't seen any file systems implemented this way.
The irony is that most of the newer ones in Linux are written that way, just nobody writes a FUSE binding to them. For example, both Btrfs and XFS contain fully functional pure-userspace implementations of the filesystem inside their userspace code (libbtrfs and libxfs both contain the complete filesystem code), but nobody has written a FUSE binding to either.
Btrfs' implementation is even used to do most of the functionality in the tools (like send/receive) rather than using the kernel to do it (in order to minimize context switches that reduce I/O performance).
FUSE is neat for one-off access to obscure file systems, and FUSE is usable for things like sshfs for those who use that, but it is my impression from having used FUSE myself that FUSE does come with a noticeable performance penalty. Is my perception wrong on this? Because if it is not then I’d be hesitant to use a system where the main storage was relying on FUSE.
FUSE is also great for slower media. Copying files over USB sticks without being restrained by FAT-32 limitations is great. There have been times that I've used NTFS-3g for this because its FUSE implementation meant I could read it on any OS.
The benchmarks on their website[1] compare it running on a 4 x 3.20GHz with hardware AES-N instructions, against an in-kernel implementation of a different cryptosystem running on a 2.7GHz cpu that does NOT have AES instructions. I also can't see anything that speaks to speed of the storage (or if this is controlled for), so I'm admittedly quite skeptical.
The numbers they do publish aren't particularly impressive to me either, so we may also have wildly different ideas about what "quite high performance" even means.
While the kernel interfaces aren't exactly wildly disparate, they are perhaps surprisingly diverse (and coupled to kernel implementation details) for something as boring as a filesystem. At least some of this is for performance reasons. Accessing offsets into kernel structures is usually going to be faster than copying the data to use on your own.
On top of that, since there is no single standard interface in the kernel, kernel maintainers are skeptical of adding shims to the mainline kernel. The Linux kernel developers are perhaps the most famous for being vocal about this, but they are not unique.
That being said, there are portable file system implementations that use FUSE. See e.g. NTFS-3g[1]
Shims in the kernel seem a bit anti-social, since all module developers are expected to contribute to the shared core code. Of course it can be done, and it has been done. But I think FUSE is better if all you care about is portability, and you don't mind the heavy performance cost. My module could be ported for FUSE of course, but it's a lot more work than it may seem, the kernel interfaces are too alien compared to a userland library.
I don't think you should get downvoted, it's a good question. I live in Buenos Aires, and there is definitely a general perception that the country is hopeless. But for some reason we do get a fair share of immigrants from more prosperous countries such as South Korea and China. There's also a lot of people coming in from Africa, mainly Senegal from what I've heard.
China still has huge wealth disparity. So, while China might seem overall more prosperous than Argentina, Chinese emigrants are often from parts of the country with a standard of living below Argentina's.
And there are other reasons to move too, like air quality, a pressure cooker educational system, extremely high housing cost as a multiple of salary...
Sure, but there's plenty of starving people in Argentina as well, not all the country is as wealthy as Buenos Aires. So the question is, why do they come here instead of going to a bigger chinese city? My guess is that they already have a support network here. That's why many of them end up working in the same businesses, such as running small supermarkets.
I've never been to Sao Paulo, but it has a reputation for being very violent and controlled by gangs. Buenos Aires is actually pretty safe (at least the city itself, the suburbs are worse, but still nowhere near the number of murders that Sao Paulo had at its worst).
reply