I wrote cargo-esr[1], an alternative tool for searching crates, with the purpose of narrowing down good choices.
Feedback welcome.
43 karma · joined August 1, 2015
https://github.com/MoSal
https://github.com/saldl/saldlFeedback welcome.
That's true. But put your self in the mind of a C developer looking at Rust code for the first time:
if a || b {
println!("True");
}
Then:
thread::spawn(|| println!("Hello from a thread!"););
----
IIRC, there are also cases where you have to write `& &` instead of `&&` to not confuse the compiler. That's a design/practical issue.
Both those issues would have been avoided if literal `and`/`or` were used.
I find it interesting how the only thing that momentarily confused me, as a C developer, about Rust syntax, was caused by Rust authors not wanting to syntactically deviate too much from C.
I only knew(and liked) C reasonably well before Rust. And nothing felt obscure when I started learning it.
I can only remember not getting what `||` meant (in the context of defining a closure without args). The positional meaning of `||` and `&&` is the only thing, I can recall right now, that can be considered obscure syntactically (for C developers at least) . They should have gone with literal `and`/`or` for the operators IMHO.
I can add an option to saldl[1] to use a new connection with each chunk. But I'm not sure there are real world examples where this would help.
Why is this interpreted as a relative path?
cd /etc
curl file://resolv.confUnfortunately, that's why ,IMHO, GNUnet didn't succeed. To build a successful product/network, you need to be practical, and you need to make useful features/services available as early as possible (without compromising security of course). Designing with pluggability and forward-compatibility in mind helps in this regard.
Academic perfectionism, however, can delay your product/network launch indefinitely. And that's what seems to have happened with GNUnet.
More and more people are starting to rely on "archive.is" as it handles Web 2.0 content without issue. But I'm concerned about the survivability of that survice, and whether it can handle big growth.
It wasn't optimal for the swarm. Yet, the user didn't really get what he/she wanted.
Supposedly long seed intervals will not help the swarm in that case.
A few leechers breaking "rarest-first" might not cause much harm. But if most leechers become streamers, torrents will lose their efficiency in distributing less-popular content.
Transmission implemented a "streaming" feature once, that didn't actually stream. It just stopped fetching pieces "with the same rarity" randomly. They still got too much heat for adding that not very usefull feature. And they reverted the commits soon after.
No client can get this right, always. aria2c is not more reliable. It's just choosing to take the filename from the redirect URL. It appears to be the right thing to do in this case. But it would fail if the start URL was actually the one that had the right filename.
Hosts can use the Content-Disposition header if they want to make sure all (capable) clients get the right filename.
In saldl, I implemented `--filename-from-redirect` to handle your use-case. But It's not set by default.
For example, `--mirror-url` was implemented. So, it is now possible to download from two sources concurrently.
> Wget supports the Public Suffix List for handling cookie domains, curl does not.
This is outdated info. (lib)curl can be built with libpsl support since 7.46.0.
I think the spammer is trying to make a point! For starters, there seems to be no rate limit applied.
If only @resurrect-save-zsh-history was implemented.
iptraf-ng: bandwidth usage by port.
lsof: list open files(including network files).