Posts
38
Following
35
Followers
56
reading files, deleting files, I can go on
A document I compiled from feedback and community experience where things can go bad, not counting filesystem bugs: https://btrfs.readthedocs.io/en/latest/Hardware.html

There's a ZDnet article from 2010 "The universe hates your data" (https://www.zdnet.com/article/the-universe-hates-your-data/). There's only that much a filesystem can do.

Sometims I feel that btrfs is a decent faulty hardware detector that also happens to be a filesystem.
0
9
19
I'm backporting some patches to AMD GPU code and in some files, there's code that actually starts at column 80. drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
1
0
2
repeated
Saw a bit of a video where somebody did the 'Linus is mean but that is why Linux is good quality' thing that a lot of people believe and not sure my eyes could roll any further.

Like do you guys think Linus controls every bit of code going in?

Do you think the sweary emails he used to send are representative? And even at his worse, who did he send them to? And how often?

The desire to excuse arseholeness by people who quote memeable stuff with usually zero understanding of the discussion is just so fucking frustrating.

How about asking people actually involved in the kernel? There's a kind of bloody arrogance with it that somebody reads a couple of these (from *checks notes* 11 years ago) and speaks as if they're an authortiy.

You're fucking not, shut up.
1
2
4
For fun I've asked llama3.1:8B to evaluate my 6.12 pull request summary how likely it was written by AI (LLM, ChatGPT). It's a weaker model but I'm still not sure if I should be mad because of "I would assign a probability that it was written by an AI as 95%", or pleased by "I wouldn't rule out the possibility of a skilled human developer having written it.".

Anyway, llama3.1:70B says it's 20% written by AI. Both don't like formal tone and enumerated lists, while acknowledging technical and specific context of linux kernel where AI can "struggle".
1
1
3

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

0
0
1
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.
0
1
2
rc1 out in in time, as if nothing happened, as if ...
0
0
2
I too am excited about 30th anniversary of DOOM release, also kernel 6.6.6.
0
0
1
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
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
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
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
"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.
0
0
1
3rd time on mastodon
1
0
1
Show older