Open Source Software Community - it's about ethics in Code of Conducts

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
Phoronix: AMD Officially Confirms The End Of The AMDVLK Driver (archive)
To no real surprise given the happenings (or there the lack of) the past few months, AMD formally announced publicly today that their open-source AMDVLK driver has been discontinued in favor of the Mesa RADV driver for Vulkan needs on Linux.
Click to expand...

Phoronix: AOMedia To Release AV2 Video Codec At Year's End (archive)
The Alliance for Open Media announced today that they will be launching the next-generation AV2 video codec at the end of 2025.
Click to expand...
I am very excited to see how good we can get the Shrek (2001) film to look in 8 mebibytes.

It would also be nice if adoption was rapid enough to see HW decode alongside Zen 6, Nova Lake, RDNA5, Rubin, etc. AV2 is derivative of AV1, so... maybe.
 
Berlin is kinda like San Francisco in these degenerate tech bro regards, also just somehow even worse. Complete anus of a city. Avoid. If you ever come to germany, dear reader, avoid the former eastern bloc area (with a safety margin; look at an old map) and West Berlin. Salted earth. These areas never truly recovered from socialist rule and the people there are either degenerates or hicks or both. Just like WW2 refugees, try to go as far west (or even south) as possible. Don't get drawn in by the cheap prices (outside Berlin). The experience will be poor. We still pay an extra tax for reconstruction of that area. True story.

Also I'm pretty sure nvidia has some cryptographic firmware signature shenanigans going on to make sure that OSS drivers can never catch up to the proprietary ones. I might misremember though.
 
AmpleApricots said:
Also I'm pretty sure nvidia has some cryptographic firmware signature shenanigans going on to make sure that OSS drivers can never catch up to the proprietary ones. I might misremember though.
Click to expand...
for some newer generations the driver can just shit the firmware onto the card and be able to do a lot more than before
newer nouveau drivers are actually somewhat ok at talking to these cards and they can finally be reclocked from the incredibly slow boot clock speeds that have been plaguing nvidia cards for years
and recently nvk has been getting quite good, with support for modern vulkan standards
the next step seems to be making it more stable and improving efficiency in various places in the mesa stack which are slow because free nvidia has been a complete joke until recently

also, this "you have to upload firmware to the card to get it to work" is far from just an nvidia problem. amd cards won't work without their firmware, for instance
 
LinuxBSoD.webp
 
Verpa Teutonica Ingens said:
Brown hands made this edit.
Click to expand...
No, I made it. I threw it together in about 15 minutes, most of which was finding that image of Linus because I find it funny. I figured since I posted my "Honest Windows BSoD" image (Link) picture that I should post something from the other perspective. The idea is, and this is poorly conveyed in the final image, that BSoDs are basically useless because they typically give very non-specific error codes.
 
85CentSoda said:
No, I made it. I threw it together in about 15 minutes, most of which was finding that image of Linus because I find it funny. I figured since I posted my "Honest Windows BSoD" image (Link) picture that I should post something from the other perspective. The idea is, and this is poorly conveyed in the final image, that BSoDs are basically useless because they typically give very non-specific error codes.
Click to expand...
so your hands are brown
 
85CentSoda said:
The idea is, and this is poorly conveyed in the final image, that BSoDs are basically useless because they typically give very non-specific error codes.
Click to expand...
well the best way to do that is by shitting on the os most infamous for non-specific bsods with meaningless error codes
which you successfully did once, good job
85CentSoda said:
I should post something from the other perspective.
Click to expand...
you probably should have made one with that one systemd service that does bsod screens
iirc it's somewhat less informative than even windows
or maybe one of those gnome crash screens, those are funny too
or at least you could have found a real linux kernel panic to shoop
 
Last edited:
Cuckoman said:
There are a lot of places in the protocol stack where you have either unused or padding bytes or even outright optional fields that are sometimes even under the applications control.

For example in IPv4 you have the header option "Security" (rfc791 page17). Which for example takes 9 bytes of whatever random data you want to tag your IP packets with.
Now off to see if there is a suitable setsockopt() call where we can provide the 9 byte "security label" a.k.a. the string "NIGGER "

EDIT: Yeah, someone just needs to write a small LD_PRELOAD that intercepts the call to socket and adds the appropriate calls to :
setsockopt(sock, IPPROTO_IP, IP_OPTIONS, ...
adding the Security option contatining the string NIGGER should do the trick.
Click to expand...
Linux does not support the security option. But linux DOES support the record route option, and that option can provide a lot more space for slurs if you need it.
And you can preload it with data already in the buffer!

===
C: 
#include <netinet/ip.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <dlfcn.h>

int (*real_socket)(int domain, int type, int protocol);

int socket(int domain, int type, int protocol)
{
    int s;

    if (real_socket == NULL) {
        real_socket = dlsym(RTLD_NEXT, "socket");
    }

    s = real_socket(domain, type, protocol);
    if (domain == AF_INET) {
        unsigned char opt[] = { 7, 15, 12,
                            'N','I','G','G','E','R',0,0,0,0,0,0,
                            0};
        setsockopt(s, IPPROTO_IP, IP_OPTIONS,
                           &opt[0], sizeof(opt)));
    }
    return s;
}
===

Compile with :
gcc socket.c -shared -fPIC -o socket.so

Make any program based using LD_PRELOAD
LD_PRELOAD=./socket.so telnet 8.8.8.8

Use wireshark and be amazed at how based your computer now is.


This way you can store up to 40 bytes of free form text in the header before you reach the max limit on how big the ip header can be.
 
Last edited:
Cuckoman said:
Linux does not support the security option
Click to expand...
that's why you need to insert n-bombs into tcp packets directly in the cpu microcode; you just can't rely on having this kind of thing in userspace. also ld_preload won't always work so this isn't foolproof (it doesn't make every packet based! the horror!)
Cuckoman said:
[unholy formatting]
Click to expand...
try some [code="C"][/code] tags
Cuckoman said:
Make any program based using LD_PRELOAD
LD_PRELOAD=./socket.so telnet 8.8.8.8
Click to expand...
that will show them

also why does this program include <sys/syscall.h>
or <netinet/ip.h> for that matter
 
Last edited:
XL xQgg?QcQCaTYDMjqoDnYpG said:
View attachment 7926818
Click to expand...
What "modern needs"? The tools we have work fine and to my knowledge the Rust rewrite is not supposed to change functionality, so what magic Rust does even bring here?
The test environment is not a place for obviously broken tools. Performance problems or the inability to handle large files are inexcusable when a better alternative already exists. None of these issues are "edge cases".

Looking at the repo the readme states this:
uutils coreutils is a cross-platform reimplementation of the GNU coreutils in Rust. While all programs have been implemented, some options might be missing or different behavior might be experienced.
Click to expand...
Putting this kind of garbage in the test environment makes people distrustful towards the new version and just wastes everyone's time. Why should anyone give the new tools the benefit of the doubt when the people working on these can't even be arsed to finish the job?
 
It'll be interesting to see how they approach arbitrary directory traversal, e.g. for things like 'rm -rf'.

It's a legitimately difficult problem because of PATH_MAX. You can only pass so long of a string to open, unlink, stat, etc before you start getting ENAMETOOLONG, but it's possible to create files nested arbitrarily deep in the filesystem using things likefor(int i = 0; i < 99999999; i++) { mkdir("a"); chdir("a"); }.

So at some point you either have to use chdir or the openat, unlinkat, etc variants. But you can only have so many file descriptors open at once before you start getting EMFILE, so that's not going to scale arbitrarily far either.

And of course using the convenient but naive recursive traversal makes it very easy to make the stack arbitrarily long and corrupt whatever's past it.

GNU's rm uses fts to do the traversal, specifically the gnulib implementation. This tries to solve the problem by using the ".." entries for returning to the parent of a directory, but this has the issue that the directory could be moved between when we enter it and when we exit it. gnulib's fts approaches this by remembering the inode for each file as it goes down and verifying that they match as it goes up. This doesn't technically guarantee that it's the same file, though, as the inode could have been reused.

In short, POSIX has given you a super raw deal: you basically have to do a graph traversal in O(1) node pointers without trusting that the graph edges won't randomly change on you.

So I'm quite curious how well the people wanting to relitigate this kind of problem in Rust "just because" are actually familiar with it. Given that it's MIT licensed, they are presumably not doing a close copy of the GPL GNU coreutils or the GPL gnulib code, so it wouldn't surprise me if they fail to learn from history.

Of course, I could just read their code and answer this for myself, but that would require me to read and understand rust (or rather, one of the 34 rusts packaged in guix alone - the implementation is the standard, after all), which sounds like a colossal waste of time.

Reminder that Ada is one of the only languages with an international standard (not just some draft) that you can freely redistribute, because it was made with taxpayer funding from TRUE AMERICAN PATRIOTS and contains TRVTH like type Gender is (M, F); on page 59 of the Ada95 reference manual. Accept no substitutes.
 
You must log in or register to reply here.
Back
Top Bottom