kdave
kdave
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. 🔢
0
1
2
kdave
kdave
I'll shed some tears for removing ia64 from linux, but well it's about time.
Show content
Also let us not forget about *cough*sparc, alpha, hppa*cough*
0
0
1
kdave
kdave
@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.
2
0
0
@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.
1
0
2
@brauner I haven't found anything else than https://github.com/mafintosh/fuse-block-device which is a bit hacky
0
0
0
kdave
kdave
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.
0
3
4
wikipedia.org##.mw-page-container:style(max-width: 100% !important)
wikipedia.org##.mw-content-container:style(max-width: 100% !important)
wikipedia.org##.mw-content-container:style(max-width: 100% !important)
0
0
0
@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.
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.
0
0
0
kdave
kdave
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.
0
2
3
@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.
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.
0
0
2
kdave
kdave
"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.
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.
0
0
1