News for hackers. Stuff that matters.

retrocat

The research article is located here: <https://www.pnas.org/doi/full/10.1073/pnas.2101084119>; if you're interested in what "likely" means in this context, it may be beneficial to read through the article. My understanding is that the "likely" comes from it being an estimate using models, as the research article states.

> Substituting our empirically derived domestic emissions for those modeled in the RFS RIA would raise ethanol’s projected life cycle GHG emissions for 2022 to 115.7 g CO2e MJ−1—a value 24% above baseline gasoline (93.1 g CO2e MJ−1). The RIA estimate, however, includes improvements in feedstock and ethanol production efficiency that were projected to occur by 2022, such that the GHG intensity of ethanol produced at earlier time periods and over the life of the RFS to date is likely much higher [...].

My understanding is that they took the model used in the RFS RIA (when the RFS was first introduced), and plugged in what they've seen over the past few years to that model. Take that with what you will.

> And we're to assume that, without the production of fuel ethanol, the same land wouldn't be tilled and used for other crops?

With the increase in demand for corn for fuel usage, more fields are needed to plant the corn. Because the corn is for fuel, not food, food wouldn't have been planted in place of the corn had there not been fuel demand.

Re:When Rust Hurts on Wednesday February 15, 2023 @03:27PM (#34810084)
> We know that moving `Arc<Db>` will not change the location of the `Db` object, but there is no way to communicate this information to rustc.

There is! `std::pin`[0] does just this (and `Arc<T>` even implements `Unpin`, so the overall struct can be `Unpin` if everything else is `Unpin`). The page even includes a self-referential struct example, though it does use `unsafe`.

[0]: https://doc.rust-lang.org/std/pin/index.html

Re:Migrating from Warp to Axum on Wednesday November 23, 2022 @07:51PM (#33726533)
I created my own web framework (<https://docs.rs/under/latest/under/>) to address some of my own perceived issues with a lot of current rust web frameworks - typing issues being one of them. Personally, I don't like the idea of endpoints requiring `#[handler]` or other "magic" derives, or guards - I wanted something with an endpoint that takes a request, and returns a result with a response. I'm still working on it, though.
Re:SHA-3 Buffer Overflow on Thursday October 20, 2022 @07:13PM (#33282046)
Are you sure this is the same code that triggers the vulnerability? Is the double `update` in the post itself unimportant (i.e., first updating with a 1-byte string, then the 4,294,967,295-byte string)? As I don't think this does that.
I don't think that's what they're claiming at all. I think what they're claiming is that it's far easier for individuals to be corrupt if their CEO is similarly corrupt, which is a completely different claim.
Re:Rust stabilizes generic associated types on Wednesday September 14, 2022 @02:04AM (#32833773)
As far as I can tell, this can't actually work, because the return type of `fn next(&'a mut self)` should actually live for some lifetime `'b` that is shorter than `'a`, instead of at least as long as `'a`; mostly because `next` borrows `self` mutably.
Because filing that counter-notice requires you to provide personal information, in case the person who filed the original DMCA wants to serve you with a legal notice.

From https://www.copyright.gov/512/:

> [...] To be effective, a counter-notice must contain substantially the following information:

> (iv) the user’s name, address, and telephone number, and a statement that the subscriber consents to the jurisdiction of Federal District Court for the judicial district in which the address is located, or if the subscriber’s address is outside of the United States, for any judicial district in which the service provider may be found, and that the subscriber will accept service of process from the person who provided notification under subsection (c)(1)(C) or an agent of such person.

> I don't think a general non-persecution right exists.

Yes, and no; one can be criticized for membership of a social group, but when people take action against the social group, I believe that can start to step into the territory of hate crimes, but I don't know if I'd consider that implying a right.

> The key point is spofity has a right to offer Joe money to use their platforms. Employees who disagree based on politics and threaten to quit working is new. If the company decides to replace them I don't believe they are in a legal position to strike.

This, I agree with. My original post was about the morals of the move, both on Spotify's part, and the Employees' part, but I have very little doubt about the legal aspect of it.

Spotify can offer Joe Rogan money. The employees can protest this. Spotify can perform editorial control. The question is, should they?

Whether or not Spotify is a downgrade is not the point here; the point is that Joe Rogan has a platform that allows him to propagate his message to the mass, and that Spotify has a role in that. That is all. The same could be said if he was uploading videos to YouTube, or hosting a website. At some point, some company helped him disseminate the message he wanted to spread - in the case of hosting a website, for example, a hosting provider, or a domain name service, or an ISP. I think it's nonsensical and potentially dangerous to say an ISP is responsible for what Joe Rogan has said, but on the other end of the spectrum, YouTube or Spotify has to do some sort of filtering on the content they help disseminate. How should they decide, then?

The problem with the latter part of your comment is that it assumes that everyone lives on separate islands, and that what one person does has no impact on the other people around them. It does. It's alright to say that we shouldn't dictate peoples lives or businesses, but there's a point that that breaks down - if we can't dictate people's lives, why do we jail people?

I can somewhat understand the point of the employees here, but ultimately, I think it's a symptom of a larger problem - of easy propagation misinformation, with very little oversight. When someone makes a veritably false claim, like "they've arrested left-wing people for lighting those forest fires," it is incredibly difficult to retract that statement; and even now, retracting such statements doesn't change the impact the original statement had. People are still going to believe the original statement, regardless of its truth, or they won't see the correction - especially when, in this case, the original audio was not corrected, and the apology issued separately. The original could remain unchallenged in the original audio, and someone who doesn't know the context or follow the content creator may not know that the claim was false - assuming good faith. Or, the clip could be pulled out of context, with no apology or correction, to tout that statement, to push an agenda. So now, even with a veritably false claim, you can potentially demonize the "left-wing people" intentionally or not - and I would argue that the original intention does not matter.

Joe Rogan has been given a platform, and he needs to use it responsibly. I'm still on the fence over whether or not Spotify should enforce that he uses the platform responsibly. When do you draw the line? At what point does his right to use Spotify as a platform outweigh the consequences of using the platform irresponsibly, potentially - or indirectly - causing harm? Inviting guests that promote transphobic onto his platform seems innocent enough, but transphobia is a major issue contesting the country, even ignoring veritably false claims being made about transpeople, and people have died over this conflict. If the platform is used irresponsibly, and veritably false information is propagated by the guest on his platform, is Joe Rogan responsible for that? What if that misinformation is what causes someone to commit a crime against transpeople? At what point should Joe Rogan, the one who promoted misinformation on a platform he controls, and that many people listen to, be held responsible for the consequences of what (and how) he disseminates to the people? Does his right to say false things outweigh the right of others to live without fear or persecution?

I have yet to come up with an answer, because I don't know what the best solution is yet.

Re:You can't Rust that on Sunday April 01, 2018 @01:53AM (#16726959)
AtomicUsize is stable!
Re:100 days with Rust: a series of brick walls on Friday March 23, 2018 @05:34PM (#16662803)
I'm quite fond of error-chain (https://github.com/rust-lang-nursery/error-chain), which helps mitigate it somewhat. You can do things like:

    use error::{Error, ErrorKind, Result, ResultExt};
    
    fn some_func(v: &str) -> Result<u32> {
        v.parse::<u32>().chain_err(|| ErrorKind::ParseIntError)
    }
The purpose of `chain_err` here is to add on top of the previous error, to explain what you were trying to do, instead of passing up the previous error (in this case, `std::num::ParseIntError`).

If you don't like that, you can do something like this:

    use std::boxed::Box;
    use std::error::Error;

    fn some_func(v: &str) -> Result<u32, Box<Error>> {
        v.parse::<u32>().map_err(|e| Box::new(e))
    }
But then you'd have to box every error.
Re:Don't let TC39 use smoosh or smooshMap on Friday March 09, 2018 @03:25PM (#16554685)
TC39 is the standard body for ECMAScript, which JavaScript implements. smoosh was a proposed alternative name (see: https://github.com/tc39/proposal-flatMap/pull/56) for flatten (and smooshMap for flatMap) due to incompatibilities with older libraries (namely, Mootools).