Are you sure it's not just a dodgy SSD that simply failed to persist data when losing power mid-write? I've had my share of sudden power cuts upon OpenBSD during the past 20+ years, and FFS has so far never gone corrupt on me.
Drive is a 2TB Intel 670p NVMe SSD (INTEL SSDPEKNU020TZ) with 9078 power on hours and 42TBW - so pretty spry, but not at the start of the bathtub curve either.
It was mounted as fast storage for a Bitcoin node.
Perhaps the only 'unique' thing is it is using a NVMe to PCIe adapter card (Synology M2D20) due to this being my "legacy" server that's still rocking a Broadwell chip.
That does sound pretty spry. But it doesn't rule out that it utilizes slow storage which is fronted by a (too) large RAM buffer making the device appear much faster than it really is. Most SSDs are like this.
FFS corrupted multiple times on me, with intel video driver freezing on OpenBSD. My short OpenBSD sidetrack ended after reliably corrupting itself the third time... every time video driver panicking, leaving a corrupted filesystem after reboot, when I had eg. ports install going on during panic.
Windows ran fine on the machine (Lenovo 200) before, and Linux ran fine after. FFS (and the intel video drivers) are the weakest part of OpenBSD in my experience, I liked many other aspects.
If writes are happening while the power cuts you will lose that data. Journaling doesn't help against this. FFS will need a consistency check if it doesn't "unmount cleanly", but this isn't the same as the file system having been corrupted and losing data. If something really got corrupted and it was something else besides what you were writing in the moment the machine died, it sounds like a lot of data (for whatever reason large amounts of data was still buffered; usually an SSD is the reason) just hadn't persisted yet. With the exception of the old unadvisable softdeps feature, FFS doesn't defer a lot of writing. And It's possible to tell FFS to be fully synchronous, with the caveat that it becomes even slower than the sluggish performer it already is.
I think that's a symptom of the provider you chose, not the XMPP sphere itself. I've used Jabber/XMPP for just over 15 years and while I've seen plenty of bullshit going on in various highly popular MUCs (join-floods, phishing attempts and such) I've never personally been subjected to spam directed at me.
With emphasis on shit. Really. I can relate to the rose-tinted memories, but DivX and XviD both encode to MPEG-4 ASP which has a lot of shortcomings that manifestly result in the infamous sludgy green-purple banding artefacts of the time, no matter how good the chosen encoder is. XviD is the better of those two MPEG-4 ASP encoders, but it simply does not look good in an absolute sense, just in a relative sense compared to the alternatives of the era.
There's no such thing as a codec that looks good or bad in an absolute sense. Codecs boil down to a quality versus bitrate curve. And starving them always looks bad.
While the most common kind of artifact will shift between standards, significant artifacts are fundamentally bitrate issues or encoder bugs.
If you gave DVD levels of bits-per-pixel to MPEG-4 ASP you could get something that looks nearly perfect.
> There's no such thing as a codec that looks good or bad in an absolute sense.
There are plenty of examples of both awful codecs (software; encoders) and of digital audio/video standards (e.g. Vorbis and MPEG-4 ASP) suffering from material limitations.
> If you gave DVD levels of bits-per-pixel to MPEG-4 ASP you could get something that looks nearly perfect.
No. Not even if the source is encoded by XviD. Not all problems can be solved by throwing higher bitrate at it. The ASP only supports 4:2:0 chroma subsampling, which is the largest of several shortcomings contributing to the limited quality you can achieve with ASP video material.
People on at least an intermediate knowledge level of digital video know what a damning problem 4:2:0 subsampling is and how heavy a penalty it incurs on color and clarity. Your comments mostly hold a suggestion that you kinda have some rough idea about digital video. And that's OK.
MPEG-4 SSTP is a very different matter, but that's not what DivX and XviD encodes.
I should have added "general purpose". I know there are restrained encoders for specific situations. Can you list a few of your examples for video? And I don't understand the other example you did mention, isn't vorbis more than enough at high bitrate?
4:2:0 is just fine for video. It is not a heavy penalty. It's OK for you to be rough about this. More seriously, if it's good enough for bluray and UHD bluray then it's fine.
Yeah sure, a few example that spring to mind would be...
Poor encoder: FAAC/FAAC2, the first open-source encoder for AAC audio, produce terrible audio no matter how much bitrate you let it work with. The AAC standard itself facilitates crisp audio quality at low bitrates, as heard with e.g. Apple's Core Audio AAC encoder or Nero AAC.
Poor encoder: Xing, a popular MP3 encoder of the early 2000s, was similarly infamous for producing chirpy and slurry audio even at or above 192 kbps, while bona fide MP3 encoders like LAME do far better on less.
Poor encoder: NVENC, Nvidia's on-GPU hardware video encoder, produce very poor H.264 video even at 8-10 mbps, even on the current 8th and 9th generation (RTX 40/50 series). Good H.264 encoders like x264 is capable of producing excellent FullHD video at just 2-3 mbps.
Poor standard: Vorbis is a good example of a spec whose limits/mistakes make it impossible to preserve certain combinations of frequencies, resulting in brief passages where parts of the reproduced spectrum deflates, making some music sound as if it lost its breath, so to speak. When fed certain "triggering" audio content designed to expose problems in the spec, Xiph's reference Vorbis encoder will produce ringing sounds. Interestingly also the MP3 spec has similar limitations where certain frequency combinations (usually towards the lower and upper ends) will reproduce with quantized amplitude, even when encoded with LAME, though the outcome is nowhere near as pronounced as it can be with Vorbis.
Poor standard: MPEG-4 ASP, being limited to 4:2:0 chroma subsampling and PAL/NTSC resolutions. My beef with 4:2:0 is because of how harsh it is on low-resolution content. MPEG-4 ASP being limited to a maximum of 720x576, and the 4:2:0 chroma coverage being only a quarter of that, is the reason why DivX/XviD content is smudgy even with reproduction filters.
On FullHD content a 4:2:0 grid has almost three times higher resolution, which I agree works out on both still scenes and slow panning (the two scenarios where low chroma resolution makes itself most reminded).
Oh I didn't mean to waste your time on poor encoders. I'm sure there's many of those. I mean actual codecs that have a problem, that make it impossible to do good quality.
> Vorbis is a good example of a spec whose limits/mistakes make it impossible to preserve certain combinations of frequencies, resulting in brief passages where parts of the reproduced spectrum deflates, making some music sound as if it lost its breath, so to speak.
So the people that talk about bitrates where it's transparent are basically delusional?
> Poor standard: MPEG-4 ASP, being limited to 4:2:0 chroma subsampling and PAL/NTSC resolutions.
That makes a lot of sense, I had no idea it was limited to those resolutions.
> So the people that talk about bitrates where it's transparent are basically delusional?
In my opinion they are not. A lot of people won't pick up on differences unless something is pretty off, even if they were intimately familiar with the audio beforehand. Some people are barely able to tell the difference between one and the same piece of music being played to them first in stereo and then in mono. A fundamental problem with blind listening tests, such as those often cited from the venerable Hydrogen Audio forums, is that they provide subjective instead of objective truths - besides everyone's hearing being different, an individual's perception of music also changes by the day as it's affected by their current mood, state of health, emotional state, whether they are rested or not, and so on. Applying a scientific method (e.g. PSNR or spectral analysis) reveals an objective truth of how close a lossy product is to the original, which is where Vorbis has been shown to fall short. But subjectively a lot of users may never notice, nor even care.
> A lot of people won't pick up on differences unless something is pretty off, even if they were intimately familiar with the audio beforehand. Some people are barely able to tell the difference between one and the same piece of music being played to them first in stereo and then in mono.
Well anyone that declares something is transparent without "to me" attached, based on only their own testing, is in the flippant "delusional" category.
I'm talking about people that get the best listeners they can find to seek out differences, and combine their knowledge together while hunting for flaws. If they can't even find one or two people that can pick out a distortion, then that's a pretty trustworthy standard, even if that only gives you a 99.9th or 99.99th percentile listener. Are these people aware of the specific problem you're stating? Do they agree or disagree?
> Applying a scientific method (e.g. PSNR or spectral analysis)
But that kind of truth is far from what you actually want, a measurement of how imperfect the compression is to human ears. You can use a complicated mathematical model for how listening works, but you're stuck calibrating that model with humans, punting the problem up a level. Bulk semi-subjective data is the best foundation we can get our hands on.
And thats another reason why you had two CD drives in tower cases. My 667mhz AMD-K7 had two CD drives, insert both VCDs and nearly seamless watch a movie.
There was the part where you had to double click the media player to make it full screen again however pretty wholesome for its time.
Nowadays, it's just not the same and Ai isn't nostalgic at all.
"DivX and XviD both encode to MPEG-4 ASP which has a lot of shortcomings that manifestly result in the infamous sludgy green-purple banding artefacts of the time, no matter how good the chosen encoder is."
That's the fault of your decoder; I never had that problem playing DivX or XviD videos in VLC.
If anything it would be an issue with the encoder, but it's not. Both DivX and XviD are prime pieces of software but they live within unbridgeable limitations of the MPEG-4 ASP profile. This or that individual may not care about the outcome, and they may use various post-processing to smooth out the creases, but the limitations are all the same real and inherently visible.
It's just that you have different (or no) post-processing filters running between those two video players. MPEG cannot be arbitrarily decoded, only arbitrarily encoded.
Sweden has such a system*, and a couple of related laws, since the early 2000s. In my personal experience it works very well here, and I've never heard friends or acquaintances complain either about getting unsolicited calls despite having signed up on the list. An identical system would of course not perform equally in any other country, depending on local "telephone culture" and general moralities.
No, that's a bad idea. There's no hurdle or legal issue, and money isn't behind it either. Those "prefixes" (area codes) are all the same segments of this or that national numbering plan that are also allocated by legitimate businesses both for placing legitimate outbound calls to their customers and for numbers that connect e.g. switchboards/IVRs to serve customers who are calling in.
If a specific region (or more likely: operators within it) are responsible for the vast majority of abusive traffic, then absolutely they should bear the consequences of this. Yes, there's collateral damage, but those negatively affected by being unable to make legitimate calls should be a prime lobby for effective egress control from their respective operators and regulators.
The ones to really bear the consequences are legitimate businesses and the customers of these businesses. It sounds like your desire to see offenders punished, instead of the problem actually being solved with the help of functional regulations, makes you incapable of seeing the wider picture.
What you mean to describe is a free tenancy vs a paid tenancy, the latter having provided a validated payment method which gives them a higher priority on allocations, even if they are of the "Always Free" kind (a single x86-64 vCPU + 1 GB RAM) or "Free-Eligible" kind (e.g. a certain amount of the Arm stuff), even if the user never paid anything.
reply