metiulekm

@metiulekm@sh.itjust.works

This profile is from a federated server and may be incomplete. Browse more on the original instance.

metiulekm,

I like btdu which is essentially ncdu, but works in a way that is useful even if advanced btrfs features (CoW, compression etc.) are used.

metiulekm,

I am afraid you are still a bit misled; WireGuard is exactly what they use for the demo video. In general the underlying protocol does not matter, since the vulnerability is about telling the system to direct the packages to the attacker, completely bypassing the VPN.

metiulekm,

If so, why not rely on the Add Trait at the element level, which is responsible for the addition operator (see docs here)?

You made me curious and I found some discussion on the subject: github.com/rust-lang/rust/issues/27739. Short version is that you could do that if you had some other trait that would tell you what the zero value of the type is, so you know what is the sum of vec![]. Originally the standard library did just that, the trait was literally called Zero. But there were some issues with it and it has been removed in favor of the current design.

For example, this code doesn’t compile because a type needs to be specified, presumably type inference gets lost amongst all the generics?

Unfortunately with this design of the Sum trait it is impossible to guess the result type from the iterator type. For example, see godbolt.org/z/c8M7eshaM.

metiulekm, (edited )

<span style="font-weight:bold;color:#a71d5d;">pub trait </span><span style="color:#323232;">Sum<A = Self>: Sized {
</span><span style="color:#323232;">    </span><span style="font-weight:bold;color:#a71d5d;">fn </span><span style="font-weight:bold;color:#795da3;">sum</span><span style="color:#323232;"><I: Iterator<Item = A>>(iter: I) -> </span><span style="font-weight:bold;color:#a71d5d;">Self</span><span style="color:#323232;">;
</span><span style="color:#323232;">}
</span>

So I’d presume the A = Self followed by I: Iterator<Item = A> for the iterator binds the implementation pretty clearly to the type of the iterator’s elements.

Quite confusingly, the two =s have very different meaning here. The Item = A syntax just says that the iterator’s item type, which is set as the trait’s associated type, should be A. So, you could read this as “I should implement the Iterator trait, and the Item associated type of this implementation should be A”.

However, A = Self does not actually mean any requirement of A. Instead, it means that Self is the default value of A: that is, you can do impl Sum<i64> for i32 and then you will have Self equal to i32 and A equal to i64, but you can also do impl Sum for i32 and it will essentially be a shorthand for impl Sum<i32> for i32, giving you both Self and A equal to i32.

In the end, we have the relationship that the iterator item should be the same as A, but we do not have the relationship that Self should be the same as A. So, given this trait, the iterator item can actually be different to A.

Note that the standard library does actually have implementations where these two differ. For instance, it has impl<'a> Sum<&'a i32> for i32, giving you a possibility to sum the iterator of &i32 into i32. This is useful when you think about this: you might want to sum such an iterator without .copied() for some extra ergonomics, but you can’t just return &i32, there is nowhere to store the referenced i32. So, you need to return the i32 itself.

The definition is pretty clear here right? The generic here is Sum<Self::Item>, abbreviated to S … which AFAIU … means that the element type of the iterator — here Self::Item — is the type that has implemented Sum … and the type that will be returned.

In Sum<Self::Item>, Self::Item is the A parameter, and Sum<Self::Item>, or S, is the type that implements the trait (which is called Self in the definition of the Sum trait, but is different to the Self in the sum method definition). As above, A and S can be different.

It might be helpful to contrast this definition with a more usual one, where the trait does not have parameters:


<span style="font-weight:bold;color:#a71d5d;">fn </span><span style="font-weight:bold;color:#795da3;">some_function</span><span style="color:#323232;"><S>(…) -> …
</span><span style="color:#323232;">    </span><span style="font-weight:bold;color:#a71d5d;">where
</span><span style="color:#323232;">        S: SomeTrait,
</span><span style="color:#323232;">{…}
</span><span style="color:#323232;">
</span><span style="font-weight:bold;color:#a71d5d;">fn </span><span style="font-weight:bold;color:#795da3;">sum</span><span style="color:#323232;"><S>(…) -> …
</span><span style="color:#323232;">    </span><span style="font-weight:bold;color:#a71d5d;">where
</span><span style="color:#323232;">        S: Sum<</span><span style="font-weight:bold;color:#a71d5d;">Self::</span><span style="color:#323232;">Item>,
</span><span style="color:#323232;">{…}
</span>

Note that you might have an intuition from some other languages that in case of polymorphism, the chosen function either depends on the type of one special parameter (like in many OOP languages, where everything is decided by the class of the called object), or of the parameter list as a whole (like in C++, where the compiler won’t let you define int f() and float f() at the same time, but will be fine with int f(int) and float f(float)). As you can see, in Rust, the return type also matters. A simpler example of this is the Default trait.

Regarding inference, some examples (Compiler Explorer link):


<span style="color:#323232;">vec![</span><span style="color:#0086b3;">1</span><span style="font-weight:bold;color:#a71d5d;">i32</span><span style="color:#323232;">].</span><span style="color:#62a35c;">into_iter</span><span style="color:#323232;">().</span><span style="color:#62a35c;">sum</span><span style="color:#323232;">();
</span><span style="font-style:italic;color:#969896;">// or: <_ as Sum<_>>::sum(vec![1i32].into_iter());
</span><span style="font-style:italic;color:#969896;">// error[E0283]: type annotations needed
</span><span style="font-style:italic;color:#969896;">// note: cannot satisfy `_: Sum<i32>`
</span>

Compiler knows that the iterator contains i32s, so it looks for something that implements Sum<i32>. But we don’t tell the compiler what to choose, and the compiler does not want to guess by itself.


<span style="color:#323232;">vec![</span><span style="color:#0086b3;">1</span><span style="font-weight:bold;color:#a71d5d;">i32</span><span style="color:#323232;">].</span><span style="color:#62a35c;">into_iter</span><span style="color:#323232;">().sum::<</span><span style="font-weight:bold;color:#a71d5d;">i32</span><span style="color:#323232;">>();
</span><span style="font-style:italic;color:#969896;">// or: <i32 as Sum<_>>::sum(vec![1i32].into_iter());
</span>

As above the compiler knows that it wants to call something that implements Sum<i32>, but now it only has to check that i32 is such type. It is, so the code compiles.


<span style="color:#323232;">vec![</span><span style="color:#0086b3;">1</span><span style="font-weight:bold;color:#a71d5d;">i32</span><span style="color:#323232;">].</span><span style="color:#62a35c;">iter</span><span style="color:#323232;">().sum::<</span><span style="font-weight:bold;color:#a71d5d;">i32</span><span style="color:#323232;">>();
</span><span style="font-style:italic;color:#969896;">// or: <i32 as Sum<_>>::sum(vec![1i32].iter());
</span>

Now we actually have a iterator of references, as we used .iter() instead of .into_iter(). But the code still compiles, since i32 also implements Sum<&i32>.


<span style="color:#323232;">vec![</span><span style="color:#0086b3;">1</span><span style="font-weight:bold;color:#a71d5d;">i64</span><span style="color:#323232;">].</span><span style="color:#62a35c;">into_iter</span><span style="color:#323232;">().sum::<</span><span style="font-weight:bold;color:#a71d5d;">i32</span><span style="color:#323232;">>();
</span><span style="font-style:italic;color:#969896;">// or: <i32 as Sum<_>>::sum(vec![1i64].into_iter());
</span><span style="font-style:italic;color:#969896;">// error[E0277]: a value of type `i32` cannot be made by summing an iterator over elements of type `i64`
</span><span style="font-style:italic;color:#969896;">// help: the trait `Sum<i64>` is not implemented for `i32`
</span>

Now the compiler can calculate itself that it want to call something that implements Sum<i64>. However, i32 does not actually implement it, hence the error. If it did, the code would compile correctly.


<span style="color:#323232;">vec![].</span><span style="color:#62a35c;">into_iter</span><span style="color:#323232;">().sum::<</span><span style="font-weight:bold;color:#a71d5d;">i32</span><span style="color:#323232;">>();
</span><span style="font-style:italic;color:#969896;">// or: <i32 as Sum<_>>::sum(vec![].into_iter());
</span><span style="font-style:italic;color:#969896;">// error[E0283]: type annotations needed
</span><span style="font-style:italic;color:#969896;">// (in the second case) note: multiple `impl`s satisfying `i32: Sum<_>` found in the `core` crate: impl Sum for i32; impl<'a> Sum<&'a i32> for i32;
</span>

Now the situation is reversed. The compiler knows the return type, so it knows that i32 should implement some Sum<_>. But it doesn’t know the iterator element type, and so it doesn’t know if it should choose the owned value, or the reference version. Note that the wording is different, the compiler wants to guess, but it can’t, as there are multiple possible choices. But if there is only one choice, the compiler does guess it:


<span style="font-weight:bold;color:#a71d5d;">struct </span><span style="color:#323232;">X {}
</span><span style="font-weight:bold;color:#a71d5d;">impl </span><span style="color:#323232;">Sum </span><span style="font-weight:bold;color:#a71d5d;">for </span><span style="color:#323232;">X {
</span><span style="color:#323232;">    </span><span style="font-weight:bold;color:#a71d5d;">fn </span><span style="font-weight:bold;color:#795da3;">sum</span><span style="color:#323232;"><I: Iterator<Item = X>>(</span><span style="font-weight:bold;color:#a71d5d;">_</span><span style="color:#323232;">: I) -> </span><span style="font-weight:bold;color:#a71d5d;">Self </span><span style="color:#323232;">{ </span><span style="font-weight:bold;color:#a71d5d;">Self</span><span style="color:#323232;">{} }
</span><span style="color:#323232;">}
</span><span style="color:#323232;">vec![].</span><span style="color:#62a35c;">into_iter</span><span style="color:#323232;">().sum::<X>();
</span><span style="font-style:italic;color:#969896;">// or: <X as Sum<_>>::sum(vec![].into_iter());
</span>

builds correctly. I am not sure about the reason for the difference (I feel like it’s related to forward compatibility and the fact that outside the standard library I can do impl Sum<i32> for MyType but not impl Sum<MyType> for i32, but I don’t really know).

Hope that helps :3

EDIT:

I’d also caught mentions of the whole zero thing being behind the design. Which is funny because once you get down to the implementation for the numeric types, zero seems (I’m not on top of macro syntax) to be just a parameter of the macro, which then gets undefined in the call of the macro, so I have to presume it defaults to 0 somehow??. In short, the zero has to be provided in the implementation of sum for a specific type. Which I suppose is flexible. Though in this case I can’t discern what the zero is for the integer types (it’s explicitly 0.0 for floats).

Ah, I read this, thought about this, and forgot about this almost immediately. I know almost nothing about macros, but if I understand correctly, the zero is in line 92, here:


<span style="color:#323232;">    (</span><span style="font-weight:bold;color:#a71d5d;">$</span><span style="color:#323232;">($a:ty)</span><span style="font-weight:bold;color:#a71d5d;">*</span><span style="color:#323232;">) </span><span style="font-weight:bold;color:#a71d5d;">=> </span><span style="color:#323232;">(
</span><span style="color:#323232;">        integer_sum_product!(</span><span style="font-weight:bold;color:#a71d5d;">@</span><span style="color:#323232;">impls </span><span style="color:#0086b3;">0</span><span style="color:#323232;">, </span><span style="color:#0086b3;">1</span><span style="color:#323232;">,
</span><span style="color:#323232;">                #[stable(feature </span><span style="font-weight:bold;color:#a71d5d;">= </span><span style="color:#183691;">"iter_arith_traits"</span><span style="color:#323232;">, since </span><span style="font-weight:bold;color:#a71d5d;">= </span><span style="color:#183691;">"1.12.0"</span><span style="color:#323232;">)],
</span><span style="color:#323232;">                </span><span style="font-weight:bold;color:#a71d5d;">$</span><span style="color:#323232;">($a)</span><span style="font-weight:bold;color:#a71d5d;">*</span><span style="color:#323232;">);
</span><span style="color:#323232;">        integer_sum_product!(</span><span style="font-weight:bold;color:#a71d5d;">@</span><span style="color:#323232;">impls Wrapping(</span><span style="color:#0086b3;">0</span><span style="color:#323232;">), Wrapping(</span><span style="color:#0086b3;">1</span><span style="color:#323232;">),
</span><span style="color:#323232;">                #[stable(feature </span><span style="font-weight:bold;color:#a71d5d;">= </span><span style="color:#183691;">"wrapping_iter_arith"</span><span style="color:#323232;">, since </span><span style="font-weight:bold;color:#a71d5d;">= </span><span style="color:#183691;">"1.14.0"</span><span style="color:#323232;">)],
</span><span style="color:#323232;">                </span><span style="font-weight:bold;color:#a71d5d;">$</span><span style="color:#323232;">(Wrapping<$a>)</span><span style="font-weight:bold;color:#a71d5d;">*</span><span style="color:#323232;">);
</span><span style="color:#323232;">    );
</span>

The intention seems to be to take a list of types (i8 i16 i32 i64 i128 isize u8 u16 u32 u64 u128 usize), and then for each type to generate both the regular and Wrapping version, each time calling into the path you have seen before. For floats there is no Wrapping version, so this time 0.0 is really the only kind of zero that can appear.

metiulekm,

I really need to try out Mercury one day. When we did a project in Prolog at uni, it felt cool, but also incredibly dynamic in a bad way. There were a few times when we misspelled some clause, which normally would be an error, but in our case it just meant falsehood. We then spent waaay to much time searching for these. I can’t help but think that Mercury would be as fun as Prolog, but less annoying.

I actually use from time to time the Bower email client, which is written in Mercury.

metiulekm,

My understanding is that all issues are patched in the mentioned releases, the config flag is not needed for that.

The config flag has been added because supporting clients with different endianness is undertested and most people will never use it. So if it is going to generate vulnerabilities, it makes sense to be able to disable it easily, and to disable it by default on next major release. Indeed XWayland had it disabled by default already, so only the fourth issue (ProcRenderAddGlyphs) is relevant there if that default is not changed.

metiulekm,

I’m betting there’s probably something that generates the key from a vastly smaller player input, i.e what gameobjects you interacted with, in what order, or what did you press/place somwhere. But that also means that the entropy is probably in the bruteforcable range, and once you find the function that decrypts the secrets, it should be pretty easy to find the function that generates the key, and the inputs it takes.

When handling passwords, it is standard practice to use an intentionally costly (in CPU, memory, or both) algorithm to derive the encryption key from the password. Maybe the dev can reuse this? The resulting delay could easily be masked with some animation.

metiulekm,

Ultimately you can configure these however you want. On my 5600X, I easily got one full execution of scrypt to last 34.6 seconds (–logN 27 -r 1 -p 1 in the example CLI), and one full execution of bcrypt to last 47.5 seconds (rounds=20 and the bcrypt Python library).

This kind of configuration (ok, not this long, but definitely around 1 second per execution) is very common in things like password managers or full disk encryption.

metiulekm,

I got curious and decided to check this out. This value was set to the current one in 2009: github.com/…/341c87bf346f57748230628c5ad6ee692192… The reasoning makes sense, but I guess is not really relevant to our situation, and according to the newest version of the comment 2^16 is not a hard limit anymore.

What if I'm not very convincing? (lemmy.blahaj.zone)

This is an excerpt from my math models textbook. It’s about Lagrange Polynomials which is a technique that lets you fit a polynomial to a set of any number of unique points (x_1,y_1) … (x_n,y_n) so long as all your x-values are different (otherwise it wouldn’t be a function, and couldn’t be a polynomial). The polynomial...

metiulekm,

I feel like the sentence also means “it’s kinda obvious when you think about it, so we won’t explain, but it’s actually important, so you probably should make sure you agree”.

metiulekm,

Regarding /etc/skel being an empty directory, note that it is one of the few places outside /home where you can actually expect hidden files :) On my Arch it contains Bash dotfiles, for example.

metiulekm,

Random guess: your GPU is managed by logind and bound to your session. When your session ends, logind takes away the permissions. This kind of makes sense, if somebody else were to physically login on your PC, they should get (probably exclusive) access to the GPU.

Not sure if this is even a good idea since I have never researched this, but maybe you can just write some udev rules to ensure that your user always has permissions to access the device?

metiulekm,

Actually there probably is one. I thought that the classic way of managing permission by the video group is gone, but in all my installs (Arch and NixOS) the GPU devices (/dev/video* EDIT: /dev/dri/card*, the previous one is your webcam) are still owned by root:video. Maybe just adding your user to video group will work? Arch Wiki even suggests this in this case:

There are some notable exceptions which require adding a user to some of these groups: for example if you want to allow users to access the device even when they are not logged in.

metiulekm,

Interesting. For me, it’s only the /dev/dri/render* device that is owned by the render group, but this device is world-RW anyway. Still, I guess you can add the user to the render group too? I did find some info that Debian uses that group this way, though I have never used Debian myself, so can’t verify that.

metiulekm,

No idea then :( AFAIK the logind mechanism I mentioned originally is based only on permissions, but I had never really needed to look into it further.

metiulekm,

Have you tried etckeeper? I haven’t, but it’s supposed to be an improvement over just using git in this usecase.

metiulekm,

In Poland:

  • driver’s permits are not a thing. In general, it’s illegal to drive without a professional instructor (with parents, for example) before getting a driving license, though a lot of people, especially in the countryside, will still do so,
  • you can only drive after turning 18. You can start the course a few months earlier, but you can only take the final exam after you turn 18 (there exists a category that allows you to drive after turning 16, but it’s limited and IME extremely unpopular),
  • you need to go to a paid course, which includes theory classes and at least 30 hours of driving with the instructor,
  • most people drive in a car owned by the instructor or the driving school, as the car must have another pair of brakes for the instructor,
  • you need to pass a theoretical and a practical exam in one of the centers (Wojewódzki ośrodek ruchu drogowego),
  • the theoretical exam is just closed questions. You need to get 68 out of 74 points, but (AFAIK, this has changed over time) all the questions are known, so people will just cram them,
  • the practical exam is first some maneuvers on the center grounds, and then a ride around the city. The exam is rather objective and is failed if you do any big mistake or fail any exercise twice,
  • the exams are not easy. The data I found is for each WORD, but in general I feel like the pass rate is around 50% for the practical exam and 70% for theory. It’s not incommon for somebody to only pass their practical exam on like 5th attempt,
  • there were supposed to be some restrictions for new drivers, but they had been discussed for a long time, even back when I passed my license before the pandemic, and I have no idea if they ever actually came into force,
  • some people think that the system is super flawed. Here’s some discussion by the Supreme Audit Office in Polish: https://www.nik.gov.pl/aktualnosci/system-szkolenia-kandydatow-na-kierowcow.html,
  • costwise, it’s apparently like 4000 zł for the course right now. Exams are paid per attempt, 50 zł for the theory and 200 zł for practice. 1 euro is 4.33 zł as of writing, but you need to take into account the difference in purchasing power and it’s probably not much cheaper than Germany even if you pass both exams the first time.
metiulekm,

Interesting. I looked this up and I think that in Poland, the wait time in let’s say Warsaw peaked at like 2 months during pandemic, but is around 2 weeks now.

Many people living in big cities will have their exams in smaller WORDs anyway, as the pass rates tend to be higher there (not a surprise, less traffic means an easier exam). Apparently in some WORDs you can even get a new attempt the same day after failing one.

metiulekm,

I really love watching ARAMSE and Brian Quan, they have a lot of knowledge about coffee and are very entertaining at the same time.

I also enjoy watching The Real Sprometheus. He is more focused on espresso hardware, which is a topic that doesn’t really interest me that much, but I still find his videos interesting.

metiulekm,

Phoenotopia: Awakening – an amazing metroidvania-related game. Relatively more popular than the other games I list, but is honestly one of my favorite games of all time.

Vision: Soft Reset – a metroidvania, but you can travel backwards and forwards in time and this really matters for gameplay.

Bombe – Minesweeper, but instead of solving the puzzles manually, you create rules (“if there is a cell with the number N and there are N empty cells around it, mark them all as mines”) which the game applies automatically.

SOLAS 128 – a puzzle game where you redirect signals in a huge machine, just a great experience if you like puzzle games.

metiulekm,

As a data point, I have a Green Cell battery in my X220. I have bought the battery on July 24, 2022 and I have been using my X220 regularly but lightly. The battery was marketed as 6600 mAh at 10.8 V. As of writing, the OS reports design capacity of 73.26 Wh and current capacity of 60.6 Wh:


<span style="color:#323232;">POWER_SUPPLY_NAME=BAT0
</span><span style="color:#323232;">POWER_SUPPLY_TYPE=Battery
</span><span style="color:#323232;">POWER_SUPPLY_STATUS=Discharging
</span><span style="color:#323232;">POWER_SUPPLY_PRESENT=1
</span><span style="color:#323232;">POWER_SUPPLY_TECHNOLOGY=Li-ion
</span><span style="color:#323232;">POWER_SUPPLY_CYCLE_COUNT=0
</span><span style="color:#323232;">POWER_SUPPLY_VOLTAGE_MIN_DESIGN=11100000
</span><span style="color:#323232;">POWER_SUPPLY_VOLTAGE_NOW=11783000
</span><span style="color:#323232;">POWER_SUPPLY_POWER_NOW=28726000
</span><span style="color:#323232;">POWER_SUPPLY_ENERGY_FULL_DESIGN=73260000
</span><span style="color:#323232;">POWER_SUPPLY_ENERGY_FULL=60600000
</span><span style="color:#323232;">POWER_SUPPLY_ENERGY_NOW=54960000
</span><span style="color:#323232;">POWER_SUPPLY_CAPACITY=90
</span><span style="color:#323232;">POWER_SUPPLY_CAPACITY_LEVEL=Normal
</span><span style="color:#323232;">POWER_SUPPLY_MODEL_NAME=45N1023
</span><span style="color:#323232;">POWER_SUPPLY_MANUFACTURER=SANYO
</span><span style="color:#323232;">POWER_SUPPLY_SERIAL_NUMBER= 9001
</span>

Is anyone here using their hardware TPM chips for credentials?

I’m curious about the possible uses of the hardware Trusted Protection Module for automatic login or transfer encryption. I’m not really looking to solve anything or pry. I’m just curious about the use cases as I’m exploring network attached storage and to a lesser extent self hosting. I see a lot of places where public...

metiulekm,

The bootloader is stored unencrypted on your disk. Therefore it is trivial to modify, the other person just needs to power down your PC, take the hard drive out, mount it on their own PC and modify stuff. This is the Evil Maid attack the other person talked about.

metiulekm,

The paper is linked in the reference section at the bottom :) Direct link: www.nature.com/articles/s41586-023-06668-3

How do I increase tmpfs size correctly?

I have reinstalled my Fedora 38 on an old laptop with only 4gigs of RAM, problem is it allocated only 2gb of tmpfs, and so far it caused me a ton of problems, it runs out of space pretty quickly, especially when installing big size sw, I’ve read you can modify the size of it by changing the entry in fstab, but I couldn’t...

metiulekm,

Not a Fedora user, but according to www.freedesktop.org/wiki/…/APIFileSystems/ adding a new fstab entry with the correct option should just work. They even give changing the size of /tmp as an example usecase :)

metiulekm,

If I understand correctly, the study looked at people over time, so what is investigated is the behavior of mentally healthy people and what happens to them in the future.

It’s still not perfect, since they used a date of diagnosis as a proxy for people becoming depressed. This is actually mentioned as one of the limitations in the study (in the second to last paragraph of the Discussion section).

  • All
  • Subscribed
  • Moderated
  • Favorites
  • megavids
  • osvaldo12
  • DreamBathrooms
  • mdbf
  • InstantRegret
  • ngwrru68w68
  • magazineikmin
  • everett
  • thenastyranch
  • Youngstown
  • slotface
  • cisconetworking
  • kavyap
  • ethstaker
  • JUstTest
  • modclub
  • GTA5RPClips
  • khanakhh
  • tacticalgear
  • Durango
  • rosin
  • normalnudes
  • Leos
  • provamag3
  • tester
  • cubers
  • anitta
  • lostlight
  • All magazines