When One Door Bug Closes Another Opens, But Often We Look So Long Upon the Closed Door Bug That We Do Not See the Open Door Bug

I've been looking around for projects with similar potential as xz. Unsurprisingly lots of GNU projects, they do the groundwork, are direct or indirect dependencies everywhere, were feature complete years ago, no new development, one last guardian of the code with credentials to ftp.gnu.org.

There's one hurdle that could raise the difficulty of infiltration though, the FSF copyright assignment paperwork.

@vbabka @danielsnor ještě by mohli sladit frekvenci a fázi

rc1 out in in time, as if nothing happened, as if ...

I too am excited about 30th anniversary of DOOM release, also kernel 6.6.6.

Collatz conjecture of programming: assuming there are N bugs, when it's odd your patch will reduce the number to N/2, otherwise bug count will be 3N+1. 🔢

@monsieuricon Eventually yes, thanks.

@monsieuricon The btrfs wiki is actively used and not everyhthing has been moved to btrfs.read-the-docs. I think some quick sync to the RTD sources can be done and reformatted properly later so hopefully the archived version won't confuse people once it becomes obsolete.

@jann @kernellogger Right, that's probably the most convenient way.

@jann @kernellogger Nice. A static list of already known bad addresses (or patterns) plus a run time check that can remove newly found ones but at this point it's dangerous to use such system. I used to patch my 2.x kernels with BadRAM (http://rick.vanrein.org/linux/badram/index.html), crazy times.

@brauner I haven't found anything else than https://github.com/mafintosh/fuse-block-device which is a bit hacky

I have a few ideas what to implement with the ublk. It's like FUSE for block devices (though BUSE exists, it's not maintained), the kernel/userspace separation makes it really convenient for experimenting.

wikipedia.org##.mw-page-container:style(max-width: 100% !important)
wikipedia.org##.mw-content-container:style(max-width: 100% !important)

@drewdevault Depends, IMO twitch has a problem with discoverability of the small but good streamers, heavily promotes just by number of viewers. It takes time to find small streamers where the chances of finding a good community is higher. Paying a visit to high profile streamers is worth for the experience how bad it actually is, so I partially agree with you. I've found several local streamers and it's mostly about having fun on the background of games, chatting or just streaming work.

Trolls or other disruptors haven't been a problem, either get called out or banned if it's beyond bearable. Bits and subscribes support the entertainment and encourage the people to continue. Sometimes it's a compensation for a costly joke or entertainment that needs some equipment.

One particular thing that helped me to filter out what I don't want to see in the recommended or 'people also watch' is the 'Not interested' option - hard to find and only available on the main page if the stream is on.

Twitch by default pushes users to its dark side and I've definitelly seen what you describe, but it is possible to find the bright side too.

In past years, the devel cycle spanning end of the year was the worst. Dealing with everything took at least month, not-so-well tested patches piled up, regressions are not cheap in total. This time, code freeze was in early December and last minute or risky changes were postponed. Yet the first week was only about regressions and the second is the same but it's getting better.

@marcan @ljs

You call the requirements arbitrary or silly, I'll give you my perspective:

> "put your declarations in reverse Christmas tree order"

I'm not a fan of the reverse xmas tree, but such local coding style preferences are there for consistency for those who have to read the code base, lots of code is read en bloc and pattern recognition becomes a great help to skim a lot of code; the drawback is that it mandates new code in that specific format, ideally documented somewhere, but practical advice is to mimic the style in the same file however unusual it may feel.

> "always do minimal fixes, ...

As linux cares about backports to old stable kernels a minimal fix has a much higher chance to get applied without merge conflicts and there's a scripting machinery around that to minimize manual fixups be people only when necessary, fixing more bugs in one patch should be avoided unless it would be really awkward so it's a gray area but in general one fix per patch should be the default, what makes sense or not is subjective and opnions differ, in the end it's the maintainer who has to deal with the fallouts of that.

> "do not reformat code to keep alignment after changes, ...

Similar argument as above, for easier backports, but it depends on the change. Patches just fixing coding style should be avoided as it clutters git history and fixing coding style issues in the modified lines should be ok but not fixing surrounding code just because it's in the same file.

What you complain about is nothing new and I've had this discussions with several people over the years. Unfortunatelly documenting the practices also does not work, nobody reads that so it always starts with the first patch and customized 1:1 response.

Frequent contributors should know how to do it (but often they don't) and I personally cut a lot of slack in one-time contributions and fix a lot of things myself when committing patches.

"Notice: journal has been rotated since unit was started, output may be incomplete."

Time machine or crystal ball needed.

Fortunatelly, since 2015 I have "ForwardToSyslog=yes" in /etc/systemd/journald.conf so /var/log/messages has the answers.

3rd time on mastodon