People can have various reasons for such look. It can be a symbol of non-conformity.
Official Rust spaces have a code of conduct that is inclusive and forbids discrimination, and this may attract people who otherwise wouldn’t feel comfortable to participate.
They are dlopened by the rustc process. You can totally mess with it: https://nitter.net/m_ou_se/status/1368632701448818691
I’d love static analysis that finds which functions may panic, which are guaranteed not to. On a related note, it’d be nice to be able to hoist panics out of loops and coalesce multiple consecutive assertions into one (llvm can’t do it, because partially done work is a side effect).
At least 69K, which is over half of all crates — https://lib.rs/quote is used almost exclusively for output of proc macros.
To generate the LLVM code correctly you need to run build.rs if there is any, and run proc macros which are natively compiled compiler plugins, currently running without any sandbox.
The final code isn’t run, but the build process of Cargo crates can involve running of arbitrary code.
The compilation process can be sandboxed as a whole, but if it runs arbitrary code, a malicious crate could take over the build process and falsify the LLVM output.
Yes, it’s Blink without the bits that Google doesn’t share (I wanted to be precise that nobody can compile actual Chrome from public sources, they can build Chromium which is almost but not quite the same)
Because it works everywhere, because it’s so old.
The next best option, a decade old WebP, is a mixed bag. In its best-compressing mode it will lower color resolution and add fringing like a JPEG. In its lossless mode it may be bigger than GIF.
If you have an option to use a proper video format, go for it. But often sites just allow upload of GIFs. If you send a newsletter you never know how primitive (Outlook) the client will be.
@-me if you have tips to share.
Vivaldi uses the same engine as Chromium, and the company has been founded by ex Opera developers.
Plus you can make certain sites always automatically open in their designated container, even if you followed a link. You can keep sites know for spying away from your logged in identity. You can have your banking and other important sites in another container for extra defense in depth.
I’m all for it, but I don’t see how I could do that with lib.rs in particular. The site already takes a swing at the anarcho-capitalist-flavored plutocracy.
I prefer data as is rather than having to double guess every search result
What’s the bad scenario you’re worried about here? What type of data you’re specifically worried about? Do you expect me to maliciously manipulate the data, or is even well-intentioned curation and use of heuristics somehow not acceptable?
My view on data cleanup is probably very different than other people’s, because I’ve spent a lot (likely too much) time with the crates’ data. The pure unadulterated source data is… bad. It’s very sparse (most crates don’t fill it in). It’s full of outdated information (set once and forgotten, wrong for forks). Some crates-io category slugs are pretty misleading, so tons of crates are miscategorized by their own authors: parsing is not for file parsers, database is not for databases. accessibility …I can’t even. Who put ogg parsers, gRPC, garrysmod, RFID readers in there?
There are tons of name-squatted crates, ferris guessing games, or just people’s baby steps in Rust. If you search on crates.io you often get the pure data of someone publishing a crate years ago and forgetting about it. This is pure, this is ranked objectively, this is curated and subjective.
crates-io shows you plainly only the license of the crate you’re looking at. lib.rs goes further and checks if the crate has any dependencies which are GPL, because if a crate says it’s MIT but has GPL deps, it actually is GPL.
crates-io shows you repository URL exactly as-is specified in the metadata, which could be inaccurate (in case of forks) or outright fake (someone else’s repo). lib.rs checks if the repository URL actually contains the crate or has the same owner as the crate, and will add a link to the true source code if the repo url is suspicious.
crates-io shows owners’ names from the free-form name field, so somebody malicious could pretend to be a well-known trusted user. lib.rs only allows display names for established/reputable accounts, and uses login name for new/untrusted accounts.
Do you have suggestions what the future of lib.rs should be?
The context here is that it was after I had a heated megathread in the bugtracker where multiple people were defending cryptocurrencies on their merits as money, decentralization tool, or an ideal to aspire to.
Burntsushi’s objection was different form these, in a subtle way, and I needed more explanation to understand the difference. His phrasing with “sneering” — to me — was not clear (I understood it as “don’t sneer at cryptocurrencies, because they don’t deserve to be sneered at” rather than “cryptocurrencies are bullshit, but you can’t say it so directly and rudely”).
Additionally, I did not want to invite another bugtracker megathread about cryptocurrencies, which is why I tested his patience asking for a statement, rather than merely linking to the bugtracker like he asked. I see it as an ask, perhaps negotiation. I don’t think that exchange deserves to be summed up as “crap”.
Anyway, I’m probably testing your patience too, so have a nice day!
(you’re replying to the guy who runs lib.rs and responded to burntshushi in that thread)
The initial request was just a question about removal, without getting into why, so it had no stance to misrepresent. The text I proposed was prefaced with “how about: …?”, and based on reasons I’ve been given previously by other people. That was a question whether that’s the right representation, not a statement. I made a wrong assumption, the text wasn’t right, so we found a different one that satisfied him.
Why do you say like crap? I took time to understand his position and reasons (which was helpful, because they were different reasons than requests before that). We’ve agreed on a way forward, and I have fulfilled his wish. It has been a bit frustrating for both of us, because it was in essence a conflict, but I think it’s been resolved in a civil way.
lib.rs author here.
The visible deprecation label was unintentional. I agree that labelling an actively maintained crate as unmaintained is wrong, regardless of what the crate is for. If I wanted to mess with the bitcoin page, there are plenty of true negative things that I could have said about bitcoin, and you know I wouldn’t be shy about it.
I do think that use of bitcoin during a climate crisis and an energy crisis is immoral. Bitcoin is like a button that gives you $1000 now, but kills someone else in the future. This is not something that deserves polite acceptance. Seriously, I beg you at least switch to proof-of-stake schemes if you must.
However, in this particular case I did not mean to label it as unmaintained, since that’s plainly incorrect. You’re right to be upset, and right to be suspicious about the incorrect label given my reputation as cryptocurrency hater. However, I’m still disappointed that the community reaction was immediate pitchforks and burn-the-site-down pile-on, followed by even more scrutiny and viewing my smallest actions in the worst possible light. Couldn’t you first ask if it was meant like this and wait for my response?
I’ve meant to downrank all crates using the bitcoin crate. Downranking of them is IMHO a fair game, since bitcoin-dependent crates are not relevant to my intended target audience.
Apart from that, I’ve also got some feedback that it’s not acceptable to change or augment any crate metadata at all. The site does change crate data en masse, but when it works right this is a feature. For example, it guesses categories when they’re missing or are likely invalid (everyone gets the “parsing” category wrong). The site has a ranking algorithm, which IMHO makes its search really helpful, noticeably better than crates.io’s. But by necessity it includes many ranking signals, which are imperfect, and the choice of the signals is inherently subjective (e.g. just sorting by downloads would be more transparent, but it’s still just a different subjective choice, and has its own downsides).
I’m open to feedback how to make it clearer that the site is unofficial, opinionated, and a mashup of data sources and heuristics. I don’t think there’s a point of running lib.rs without the data cleanups or ranking. This would reduce it to only mere redundant duplicate of crates.io. I want to make something clearly better, beyond what pure crates.io can do.
But there are 120K crates and growing, so this is a hard task. If I’m going to get a load crap for every buggy boolean, I don’t want to run the site. It exists for the community, and if the community thinks I’m a villain, then why should I bother.
https://crates.io/search?q=git (finds dead placeholder, no git2 in sight) vs https://lib.rs/search?q=git (finds git2 first)
https://crates.io/search?q=option (dead placeholder again, and every crate that contains “at your option” in license) vs https://lib.rs/search?q=option (finds Option helpers and cli parsers)
https://crates.io/search?q=database vs https://lib.rs/search?q=database
https://crates.io/search?q=error (7-year-old crate, podcast-api!?) vs https://lib.rs/search?q=error (anyhow + thiserror first)
https://crates.io/search?q=sedre (typo) vs https://lib.rs/search?q=sedre (did you mean serde?)
crates.io is fine when you know the name of the crate you want (navigation searches), but is full of noise for broader queries. It doesn’t eliminate namesquatted garbage nor obsolete crates. It searches all text including tangential boilerplate. It shows fewer results per page. OTOH lib.rs filters out the noise. It also understands words with multiple meanings and ensures all meanings are included (e.g. search for “http” knows to include “http client” and “http server” and asks you to clarify which meaning you wanted).
I maintain a long-term Rust + Node.js project, and the Node side is the painful one.
Node makes backwards-incompatible changes, and doesn’t have anything like the editions to keep old packages working. I can end up with some dependencies working only up to Node vX, and some other deps needing at least Node v(X+1).