It seems that a couple of recent stories have suddenly disappeared off our screens. We are looking into the cause but I apologize for those who were having a discussion which has now been cut short.
We will keep you informed.
janrinok
This discussion was created by janrinok (52) for logged-in users only, but now has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
(1)
(Score: 5, Funny) by looorg on Monday October 02 2023, @04:16PM (4 children)
I might be missing one but I think it's the "Google lets you Opt out of AI training" that is missing. I didn't think the AI overlords would punish us this harshly for not providing their models with free language content ...
(Score: 3, Informative) by ls671 on Monday October 02 2023, @04:38PM (3 children)
It seems to me like the eclispe article is gone as well, maybe it "eclipsed" itself.
Everything I write is lies, including this sentence.
(Score: 4, Interesting) by janrinok on Monday October 02 2023, @05:42PM (1 child)
I have reproduced the 'Eclipse' story - it will be out in a few hours time.
The other 2 missing stories can still not be found. The problem might be linked to using an Android smartphone for editing, but that is still speculative and unproven. Pressing the 'update' button - which is what we do when we edit stories - appears to have deleted stories rather than updated them.
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 3, Interesting) by looorg on Monday October 02 2023, @06:24PM
I still have the Google story in my "submit story" list, as I submitted it. So I can resubmit that again if needed and wanted.
(Score: 4, Informative) by Mojibake Tengu on Monday October 02 2023, @05:45PM
October Eclipse stuff is basically covered by https://www.space.com/annular-solar-eclipse-2023-guide-ring-of-fire [space.com]
Rust programming language offends both my Intelligence and my Spirit.
(Score: 2) by Gaaark on Monday October 02 2023, @09:23PM
Was it the Toy Story? Something about things falling with style.
Some guy named DebIan posted it.
--- Please remind me if I haven't been civil to you: I'm channeling MDC. I have always been here. ---Gaaark 2.0 --
(Score: 2, Funny) by Anonymous Coward on Monday October 02 2023, @11:22PM
I loaded the pages on my mobile device, then the battery died. I'll blame Motorola for batteries that only last two days or so.
(Score: 2) by PiMuNu on Tuesday October 03 2023, @09:30AM
Thanks for your efforts!
(Score: 2, Interesting) by pTamok on Tuesday October 03 2023, @04:22PM
I used to run a COW filesystem (NILFS2 [kernel.org]) where recovering recently deleted files was almost trivial: find a time at which the deleted (or modified) file existed, grab a checkpoint at that time, convert checkpoint to a read-only mountable snapshot, recover file. That general capability is missing is more modern filesystems, which do not have continuous snapshotting.
It seems such a fundamental thing, and useful too, that it is somewhat surprising to me that it is not implemented more generally, including in (relational) databases. Often journalling and snapshotting are available, but not incorporated into application design, making recovery needlessly complex.
I'm absolutely not saying you should run NILFS2, But, in principle, if you are journalling database updates, you should be able to roll back to before the point in time the articles went missing, grab a copy, roll forward, and reapply the update to get the articles back.
I did say, in principle.
This is not intended as criticism. I do know the SN infrastructure is held together by spit and baling wire, and I am extremely grateful for all the work the volunteers who run this site put in.
But a thought for the future: there are many ways in which things go wrong and stuff gets accidentally modified or deleted. If you implement new systems, perhaps look to see how continuous snapshotting could be implemented. There's no good reason to lose data in this way.
Note: Obviously, continuous snapshotting will use up oodles of disk space. The beauty of a COW/Ouroboros filesystem being a circular buffer is that you simply overwrite the oldest parts as time goes on. If your full backup interval is less than your log-eating-its-tail interval, you need never lose data. There are accounting challenges in working out how 'full' a filesystem is when all blocks are used and the oldest written are overwritten continuously, but those challenges are not insuperable. There isn't an actual Ouroboros filesystem, but I used the image of the creature eating its own tail as an illustration of what is going on. When there are no blocks available to be overwritten because all blocks are currently allocated to existing files (rather than snapshots of previous versions), everything comes to a dead stop.