Wikipedia (see elsewhere for link) has good coverage of that. "A" was intended to be said, but when humans say lines like that it is common to miss a word here and there. There is no way to know for sure if he said it and the technology of the time didn't pick it up, or if he misstated his own quote.
I have to say, it gets really old seeing this sentiment on HN anytime a post about older technology gets made. We absolutely can and do make technology designed to last this long - it’s just that the vast majority of us don’t work on anything with those kinds of requirements or priorities. There’s no reason you need to be building your CRUD API, data pipeline, or cell phone to last 50+ years and doing so would probably be actively harmful to the actual goals of those projects
For what it's worth, I actually agree. See: Curiosity or Ingenuity, both relatively new and far outperforming their expected life. Not to mention that I'm sure the ground-based transmitters that were used to actually fix Voyager 2 are likely not old, so it really isn't a case of "old is good" which helped in this case.
My comment is unfortunately an example where I let my late night shit-posting bleed over into HN, which is always regretted in the morning. Apologies ;)
Modern space electronics cannot last this long. It would require a significant effort to design similar hardware and have it fabbed today. Modern missions want capabilities that necessitate high transistor counts and that forces feature sizes that will never be robust against radiation effects over long durations.
Cassini lasted 20 years (1997-2017) and was functioning fine all along. It was intentionally ended, but there had been talk of sending it on another 20 year cruise to Uranus.
New Horizons is similar, now at 18 years since launch and still counting.
They're not quite 50 yet, but there's no reason to think either couldn't make it that long.
Most, I think Debian has patch to be disabled at runtime via sysctl. The reason is that most containers or sandboxing techniques are root only unless you mix it with user namescapes. So most container or sandbox software use suid(firejail) , root daemon(docker) or user namescapes (podman and flatpak). Looking at the cves, user namespaces is probably the safer option
Rewritten what? The container runtime will need the same access regardless of what it's written in, and rewriting all of Linux (the kernel) would be... ambitious, although it is adopting rust incrementally.
Some of the issue though is that a monolithic kernel provides more access than necessary to many things. When they made the locks granular, those might be reasonable boundaries for permissions? At this point I'd rather figure out how to make windows drivers work in redox or something crazy like that.
I wrote a top level comment but I really don't understand this argument. Just because the model is "multiple facts about a user" does not mean you have to jump through hoops to name the database table. It would just be user_facts, wouldn't it? That seems intuitive and straightforward to me, even if the class name is also plural.
Some of these arguments are a little questionable imo.
"It reads well everywhere else in the SQL query:"
You can alias the table names and have it read well in all places, and this mostly only matters if you are actually writing SQL and not using an ORM directly, which the next point seems to imply you would be using.
"The name of the class you’ll store the data into is singular (User). You therefore have a mismatch, and in ORMs (e.g., Rails) they often automatically pluralize, with the predictable result of seeing tables with names like addresss."
Almost any modern "pluralize" implementation would handle this correctly. Rails would call the table `addresses`.
"Some relations are already plural. Say you have a class called UserFacts that store miscellaneous information about a user, like age and favorite color. What will you call the database table?"
You would call the table user_facts... Am I missing something?
I think the point the author is making there is that normally, each row represents a single item, but in this example, a row represents multiple facts. So normally you might have User(name=Bob, pw=**), but here you've got UserFacts(age=93, hair_color=gray). That is, UserFacts is a single instance of an object that happens to be a bundle of facts. So when you come to create the table names and use plurals, you can convert User to users, but UserFacts can't be pluralised again. (user_factses?)
Fwiw, this seems like a pretty contrived example, and I'm struggling to think of a better one. Maybe if you recorded user achievements as a single row for each user, with each achievement being its own column? But in most situations like that it would probably be best to take the extra normalisation step and just have a separate table for all the achievements in the game, that way it's a lot easier to add new ones.
But if we’re already in SQL pedantry mode, we wouldn’t be storing multiple facts in one row to begin with. “Use singular SQL table names so that using a relational db like a document store is less awkward” is a weird argument.
(The right answer, as others have already pointed out, is “whatever is consistent”)
I'd call it user_facts too, it's an 1:n relationship from users to facts. Maybe `users_facts` if it's an n:m relationship, but frankly I can never come up with good names for many-to-many tables.
There's definitely some ambiguity there, that's a good point.
I'd probably say that users_facts would be a to-many join table between users and facts, like if you had one row per fact and a multiple facts per user though that example doesn't really make sense here (could just have the FK exist in Fact and not need a join table). If UserFacts were stored in a table with multiple facts in one row about a single user, I would probably call that table user_facts.
Would probably also be fine with running across either in any codebase (or even singular table names, for that matter! as long as it's consistent :D )
Sure, not saying there isn't any discrepancy-- just that the discrepancy is in the measuring methods. I was showing that there _is_ a way to produce a 16GB number (albeit in terms of GB, not GiB) given the number of blocks physically available, that's all.
As a counterpoint, I'd say that my kids have brought a return novelty for a lot of things. Doing stuff with them that I've done before but they haven't is completely new again for me, too.
edit: to be clear, though, I'm not suggesting OP has kids to bring excitement back to life ;)
Yeah I totally agree - I wasn't clear originally. What I meant by "kids takes this feeling away" was the monotony OP experienced. My favorite time of the day is between 6pm when I stop working for a bit, and our daughter's 7:30 bedtime. Still, it's the same routine day to day, even if she has made it a much better routine :)
The point is that lawyers sent the cease and desist, so the other side does have lawyers at their beck and call. If you want to do anything other than what they demand you do, you are risking more lawyery-action. And even if you do comply, that doesn't stop them from continuing to bring action against you for some other reason, or for damages, or whatever they want, really.
It may not be a system that is geared towards fair play, but if you want to play at all, you really should have a lawyer, too.
