Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)C
Posts
0
Comments
522
Joined
3 yr. ago

  • Energy consumption limit. Every AI product has a consumption limit of X GJ. After that, the server just shuts off.

    The limit should be high enough to not discourage research that would make generative AI more energy efficient, but it should be low enough that commercial users would be paying a heavy price for their waste of energy usage.

    Additionally, data usage consent for generative AI should be opt-in. Not opt-out.

  • I don't think Microsoft invented scrapping. Or LLM training.

    Also, GitHub doesn't have an issue with Microsoft scraping its data. They can just directly access whatever data they want. And rate-limiting non logged in accounts won't affect Microsoft's LLM training at all.

    I'm not defending a monopolist because of monopolist actions. First of all because GitHub doesn't have any kind of monopoly. There are plenty of git forges. And second of all. How does this make their position on the market stronger? If anything, it makes it weaker.

  • No. I cannot find the flaws in my reasoning. Because you are not attacking my reasoning, you are saying that i am on the side of the bad people, and the bad people are bad, and you are opposed to the bad people, therefore you are right.

    The world is more than black or white. GitHub rate-limiting non-logged-in users makes sense, and is the expected result in the age of web scrapping LLM training.

    Yes, the parent company of GitHub also does web scrapped for the purpose of training LLMs. I don't see what that has to do with defending themselves from other scrappers.

  • It's not the same making API costs unbearable for a social media user and limiting the rate non-logged-in users.

    You can still use GitHub without being logged in. You can still use GitHub without almost any limit on a free account.

    You cannot even use reddit on a third party app with an account with reddit gold.

  • Or we just realize that GitHub without logging in is a service we are getting for free. And when there's something free, there's someone trying to exploit it. Using GitHub while logged in is also free and has none of these limits, while allowing them to much easier block exploiters.

  • Firefox is not chromium based. You can install unlock origin and have no ads.

  • There's a reason just in time manufacturing took over the world. Storage is expensive.

  • Or. You could just pay them more. Which would be politically way easier.

  • Just make a file system that maps each file name to 2 files. The 0 file and the 1 file.

    Now with just a filename and 1 bit, you can have any file! The file is just 1 bit. It's the filesystems that needs more than that.

  • The problem might be the arc mutex. mpsc are already clone, send and sync. When you clone an arc mutex T, you are cloning the arc. But mpsc probably needs to be cloned itself to work properly.

  • The only thing I know about this pope is what I've gathered from Lemmy comments. According to those:

    He's homophobic and anti-trumpism in the aspect of immigrants.

    I think that's a pretty average catholic. Homophobia and helping the poor.

    Neither progressive nor fascist.

  • It may be true that there's no better one. Which doesn't mean that it's good.

    I have tried both clion and VSCode. I can't think of many more IDEs other than Visual Studio (which I haven't tried). I don't think there's many other options.

    Clion is much faster than VSCode's C/C++ extension. For example go to definition is instant while VSCode can take 10+ seconds each time, and it doesn't cache results. However, that's the only good thing I can say about Clion.

    At work I use VSCode. Why? Because it works. CLion worked for like 6 months, and then it just refused to lead the cmake project, becoming absolutely useless.

  • Not that it was much good to begin with, but enshittification is coming

  • Technically, this may sound pedantic. You are not passing neither arrays nor tuples as generic parameter types.

    What you are doing is passing an array to a function.

    The type of the array is [i32;5]. Every value has a type.

    By passing the array to a function, you are allowing the compiler to infer what function you are calling, since that function is generic. Using the type of the parameter you passed to it.

    You can only pass values to function parameters. And you can only pass types as generic type parameters.

    Well in this case it's a little different, since it looks like you are passing a value (5) to a generic type parameter (LENGTH), but the const part of const LENGTH means that it's a value generic for a type, not a type generic for a type, which is the usual thing.

    EDIT: additionally, the : usize part tells you what type exactly the const parameter for the type has to be.

    Note that you can't have non-const values as type parameters. Since types are defined at compile time.

    EDIT 2: since type inference just fills some boilerplate for you. If we do that boilerplate manually it's easier to see what parameters go where.

    When you do Buffer::from([0,1,2,3,4,5]) what you are really doing is: Buffer<i32, 5>::from([0,1,2,3,4,5)]. In fact, if you put that, the code will compile exactly the same. Now if you put a 6 instead, it won't compile since the type of the buffer and the type of the array you are passing are not the same.

  • You don't need to know at all what optimizations will happen. I said that as an example of a thing that you know in compile time but not in run time.

    To tell or not whether a type will be inferred is determined by you. If you tell the compiler the type, it will never be inferred. If you don't tell the compiler the type, it will try to infer it. If it tries to infer the type but it fails, it will throw a compiler error and it won't finish building the binary.

    The compiler will only successfully infer a type if it has enough information at compile time to know with certainty what type it is. Of course, the compiler is not perfect, so it is possible in complex situations for it to fail even though it theoretically could.

    Examples where inferring will succeed:

     rust
        
    
    fn copy<T>(in: T) -> T {
        return in;
    }
    
    fn main() {
        let a = 47; //here a is of type i32, this was not inferred, it's just the default type of integer literals
        let b = copy(a); // here the compiler knows that a is i32, therefore it should call copy<i32>. Due to the type signature of copy<i32>, the type of b is inferred to be i32
    
        let c: u16 = 25; // here instead of the default, we manually specify that the type of c is u16
        let d = copy(c); // this is the same as b, but instead of calling copy<i32>, copy<u16> is called. Therefore d is inferred to be u16
    
        let e = 60; // at first, this looks like a, and it should be  the default of i32
        let f: i64 = copy(e); // here, since f is specified to be i64, copy<i64> is called. Therefore e instead of being the default of i32, it is overridden since inference has preference over the default. e is inferred to be i64.
    }
    
      

    Examples where inference will fail

     rust
        
    
    trait Default {
       fn default() -> Self
    }
    
    impl Default for i32 {
        fn default() -> i32 { return 0 }
    }
    
    impl Default for i8 {
        fn default() -> i8 { return 0}
    }
    
    fn main() {
        let a: i32 = 8;
        let b = copy(a);
        let c: u8 = copy(b);
        // What type should be inferred to? If it calls copy<i32> because a is i32, then it can't call copy<u8> later to initialize c. And if it calls copy<u8> instead, it can't receive a as an argument since a is i32. Results in compiler error
    
        let d = Default::default();
        // What type is d? both i32 and i8 implement the Default trait, each with its own return type.
        // let d: i32 = Default::default(); would compile correctly.
    }
    
      

    These situations might be obvious, but inference works as a chain, sometimes hundreds of types are inferred in a single function call. So you should know the basics to diagnose these kinds of problems.

  • Since deadcream already told you the reason. I'm gonna explain a more generic way.

    There are 2 important times: compilation time and run time.

    At compilation time, everything that is constant, is known to the compiler, or can be calculated by it.

    At run time, everything* is known.

    Types have to be generated at compilation time**. This means that generics have to be also known at compilation time.

    In this case. Both the "T" type of the buffer and its size "LENGTH" are generic, so they must be known at compile time. Compile time usually doesn't know about vales of variables, except if those variables are "const". Then it is known. A value literal is the same as a const variable.

    So here, you provide a value literal ([0,1,2,3,4]) which is a fixed array, that is, both its "T" type (i32 by default) and length (5) are known at compile time. Buffer has all the information it needs to become a real type instead of a generic one. In this case, the type will be Buffer<i32, 5>

    Things that are optimized out at compile time are not known at runtime, but yes at compile time. For example:

     
        
    const A: i32 = 5;
    const B: i32 = 5+1;
    
    fn main() {
        dbg!(B)
    }
    
      

    Since A is never used (except to calculate B, which is const), A is probably optimized out. However, since B is used, there probably is a 6 somewhere in memory. Notice how I say probably since optimizations are optional. Or more optimizations may even remove the 6, and convert it to an ASCII "6" to be printed out.

    **While this is always true trait objects (like Box

    <dyn ToString>

    ) can act like some kind of runtime type, if you need that functionality.

  • Because then you can't change your password. Since you would have to decrypt all the hard drives that use windows with that account, and then encrypt them again with the new one.

    This also means that if you forget your password you are fucked.

    • Office 365
    • Google docs
    • Libre office
    • Confluence

    All of those answer the questions. Sure, libre office for example relies on everyone knowing what MS office is, but it still does a good job of explaining.

    Again, I don't know exactly what your product does, but my guess is that confluence is the one that's more similar.

    Don't need to look at your competitors though. Go to any product with a multi-million marketing budget and you'll see how they answer the basic questions in a similar manner.

    Edit:

    Of course if you look at what their product page looked like before the AI bullshit ate the brains out of the tech CEOs, you would find better examples.

  • That's whataboutism.

    There are many factors for the housing crisis.

    That doesn't mean that you can only solve one of the factors.