Bzip2 To See Revival Under New Maintainership, Experimental Porting To Rust

[jjkk]

Relying on stuff that is commonly distributed in binary form does not make a system able to build things "from scratch".

It's still better to rely on a binary toolchain to jumpstart instead than having to deal with stupid build systems.

In all your trolling efforts you are speaking from the point of view of an end-user. And people arguing here are trying to say that the packages are not appearing in your favorite distro magically. Someone actually goes through varying grades of pain to prepare them.

Rust people sometimes seem to me just like plain noobs who know only their beloved toy and believe that the world ends there. All they do is repeat their mantras "reliable", "secure", "productive" and so on without displaying tiny bit of understanding of the terms or giving any meaningful example.

Rust is just a tool. It does not give any magical advantages against C or C++ to a person who does not understand what is he doing and trying to achieve. Just why not play nice and understand that someone has to deal with the unnecessary hipster toy. That may actually draw more attention of sane people. Right now it seems they are just forcing it furiously.

[oleid]

In all your trolling efforts you are speaking from the point of view of an end-user. And people arguing here are trying to say that the packages are not appearing in your favorite distro magically. Someone actually goes through varying grades of pain to prepare them.

That's the same for autotools direct or indirect dependencies, namely bash.

Even lfs contains python, so e.g. Meson would be no problem. http://www.linuxfromscratch.org/lfs/...chapter05.html

Rust is just a tool. It does not give any magical advantages against C or C++ to a person who does not understand what is he doing and trying to achieve.

Such a person shouldn't be programming anyway. But if they do, they'd come tothe conclusion, that rustc is a good tutor. I learnt, that if my Ansatz of realizing something in rust results in overly complex code, there is probably something wrong with it. The same Ansatz would have been easier in c++, howeve, would still have been bad design.

[oleid]

And no, you can not reproduce Rust without extending this bare minimum by a binary build of itself.

You cannot build a modern gcc8 with an ancient gcc. I've tried. And failed.

Considering rust, a gcc backend is planned. So maybe a future bootstrap environment of yours will contain 'grustc', or however it will be called.

By the way, nobody is stopping you from using rustc from a plain makefile. No need for cargo.

[jjkk]

You cannot build a modern gcc8 with an ancient gcc. I've tried. And failed.

Oh, well. I can. I have tried. And succeed. Many times. And since you did not specify "ancient" it is just your word against mine.

If that is really a case, you still have a possibility to build any version between ancient and target and use it as a bootstrap. It is not hard to automate but the outcome is reproducible, deterministic build. You will get same binary for same source code every time and a manageable means to track down problematic changes. To do the same with Rust you have to make extra moves and I am still not convinced they are not avoidable. Especially caching locally some specific branches of git repos.

Considering rust, a gcc backend is planned. So maybe a future bootstrap environment of yours will contain 'grustc', or however it will be called.

That would be great. Who knows, only time will show what tools are usable and popular. Once again: not against any tools or new languages. But that attitude of pushing and forcing "the new best thing in the whole world" just repels people from using it.

[birdie]

multithreaded bzip2 decompresses a lot faster.

Care to show proofs?

On my 4 cores PC LZMA2 decompresses up to 10 times faster than pbzip2.

[hotaru]

Care to show proofs?

On my 4 cores PC LZMA2 decompresses up to 10 times faster than pbzip2.

no, I don't really care enough to bother running the benchmarks again, but on my 16 and 32 core Xeon machines, multithreaded bzip2 (with lbzip2, I haven't tested pbzip2) is much faster than LZ4, which is itself much faster than LZMA2.

[birdie]

no, I don't really care enough to bother running the benchmarks again, but on my 16 and 32 core Xeon machines, multithreaded bzip2 (with lbzip2, I haven't tested pbzip2) is much faster than LZ4, which is itself much faster than LZMA2.

Yeah, great, another Phoronix reader with utterly ridiculous HW is trying to prove his point for the rest of us, plebs, running run-of-the-mill HW. You know maybe on Amazon/Google cloud parallel bzip2 will be even faster, but who on Earth cares? No one cares about your ridiculous use cases.

[birdie]

I'm already arguing with a super-duper PowerPC user in another thread. Looks like Phoronix attracts people who love to show off.

[hotaru]

Yeah, great, another Phoronix reader with utterly ridiculous HW is trying to prove his point for the rest of us, plebs, running run-of-the-mill HW. You know maybe on Amazon/Google cloud parallel bzip2 will be even faster, but who on Earth cares? No one cares about your ridiculous use cases.

the 16 core machine cost less than $300. you probably paid more for your quad core, and your ridiculous clock speeds mean that it doesn't matter which algorithm you use. lots of slow cores are much cheaper and less power hungry than your few ridiculously fast ones.

[birdie]

the 16 core machine cost less than $300. you probably paid more for your quad core, and your ridiculous clock speeds mean that it doesn't matter which algorithm you use. lots of slow cores are much cheaper and less power hungry than your few ridiculously fast ones.

Lol. Are you referring to my Intel Core i5 2500 which can bought on eBay for $50?