Alt.Binz creator puts on "nice guy" hat, releases all newer versions as FREEWARE!

[zot]

... just in case you didn't already know that. :lol:


http://www.altbinz.net/

[Hypatia]

i dont like it. i wouldnt use it even if it had perma-free status.
(i am a paid non-user)

its a resource hog.(at least in my case)

PS Besides.. it doesnt say that all new versions will be free. =) Just the current one 39.4.

[Stabber]

i guess there is hope for everyone, since he is changed ;)

[Hypatia]

Nah, its just PR.

Search is disabled in this free version =))

[Cabalo]

April's Fools ?

[mjmacky]

So to put out this question, the free Alt.binz that I've been using up until now is 0.25 I think. It works just fine for me and does everything I expect it to do without creating additional work for me, doesn't use too much of my resources either. What exactly would I gain from updating it to a newer version?

[Stabber]

So to put out this question, the free Alt.binz that I've been using up until now is 0.25 I think. It works just fine for me and does everything I expect it to do without creating additional work for me, doesn't use too much of my resources either. What exactly would I gain from updating it to a newer version?

Faster decoding and lose your skins and search engines .

Actually there is an ever newer "free" version over at usenet , 0.28.5 but the newest one 0.39.4 has much faster decoding

[zot]

So to put out this question, the free Alt.binz that I've been using up until now is 0.25 I think. It works just fine for me and does everything I expect it to do without creating additional work for me, doesn't use too much of my resources either. What exactly would I gain from updating it to a newer version?

You aren't supposed to ask that kind of question. In fact, to even think such thoughts is considered sacrilege. (don't you know that "new=better"?)

But I'm probably not the best person to ask, as you'd be getting advice from someone who keeps an ancient notebook PC with the old "square" screen because it fits on narrow desks (with enough room on the side for a mousepad or notebook to write on) without sacrificing display height, and with its glare-free screen (and flat-black case) can even be used outdoors (or even next to windows) on sunny days without the risks of momentary blindness that virtually all newer laptops are cursed with.

At least old software can be used for eternity, even if the hardware it runs on can't.



Faster decoding ... has much faster decoding
If you mean the Yenc-to-rar decoding, I'll say this:

Using the old Altbinz 0.25, on a decade-old computer, it will decode fast enough [just barely] to keep up with a 20 megabit/second download speed, which is the highest speed I've ever had the opportunity of using. (This is the same PC which gets maxed-out running the current version of SABnzbd ... at dialup speeds.)

On any modern computer, I'll extrapolate that Altbin v0.25's (supposedly-resource-hogging) Yenc decoding would not be a significant processor load on anything less than hyperfast download speeds.

But anyway, as a general rule, it seems that the more recent the software version, the more resource-hogging it will typically be. This is why people with old computers are usually [though not in every case] better off using old versions of software.

[JustDOSE]

weird.... when i download it just disappeared from the dl location, guess my antivirus didnt like the installer... but the zip dl'd and extracted fine........... wtf is going here =/

[Hypatia]

i gave it a try.. well. decoding still uses shitload of resources, mostly cpu( i monitored it) compared to very efficient in that department usenet explorer and sabnzbd deals with this much better too

[Stabber]

Those who actually paid for the latest version must feel silly for giving away their money , for some skins and search engines

[Hypatia]

well i suppose its more convenient to have them all at one place and it allows you to download things more easy and set individual download path right away before putting something into a download queue which i didnt find how to do without them. I had to change download folder only from downlaod queue window(had them imported paused)


Its a one-time payment. But what really puts me off in the first place is aggressive drm protection- altbinz connects to its server every time you launch it. Once it was unavailable... well you got the idea lol

[JustDOSE]

i gave it a try.. well. decoding still uses shitload of resources, mostly cpu( i monitored it) compared to very efficient in that department usenet explorer and sabnzbd deals with this much better too you should make a comparison of all major usenet clients to that affect........... like how much a client uses when downloading at ur top speed and with how many connections... make urself useful please

[Hypatia]

what could i use to log this kind of activity?

[mjmacky]

You aren't supposed to ask that kind of question. In fact, to even think such thoughts is considered sacrilege. (don't you know that "new=better"?)

But I'm probably not the best person to ask, as you'd be getting advice from someone who keeps an ancient notebook PC with the old "square" screen because it fits on narrow desks (with enough room on the side for a mousepad or notebook to write on) without sacrificing display height, and with its glare-free screen (and flat-black case) can even be used outdoors (or even next to windows) on sunny days without the risks of momentary blindness that virtually all newer laptops are cursed with.

At least old software can be used for eternity, even if the hardware it runs on can't.



Faster decoding ... has much faster decoding
If you mean the Yenc-to-rar decoding, I'll say this:

Using the old Altbinz 0.25, on a decade-old computer, it will decode fast enough [just barely] to keep up with a 20 megabit/second download speed, which is the highest speed I've ever had the opportunity of using. (This is the same PC which gets maxed-out running the current version of SABnzbd ... at dialup speeds.)

On any modern computer, I'll extrapolate that Altbin v0.25's (supposedly-resource-hogging) Yenc decoding would not be a significant processor load on anything less than hyperfast download speeds.

But anyway, as a general rule, it seems that the more recent the software version, the more resource-hogging it will typically be. This is why people with old computers are usually [though not in every case] better off using old versions of software.

I've got a 40 Mbit connection, though I've never really monitored the process so closely to see if the Yenc decoding "keeps up". Am I supposed to sit and watch my downloads? I know that I would usually queue up all my stuff at about the same time and make a sandwich or do some other thing, and when I get back all of it is done. Let me know if I've been doing it wrong.

Thanks for the info, if I ever feel the need to uproot my current installation, I'll know I have the option for a newer, faster, better bloated Alt-ernative.

[Hypatia]

well i didnt watch closely =), i just have process explorer in tray and i see clearly high spikes of activity related to altbinz when it decodes stuff. Too much of an activity(cpu-based) to be honest.

[Stabber]

How much difference in cpu is there between alt.binz and usenet explorer?

[JustDOSE]

dude this new ver runs way less ram then the previous version.. just disable all the extras, why would u leave most of the useless tabs and buttons and functions running then say its a resource hog... just like ff, its only expensive if you have massive amounts of addons, although ff does open shitloads of plugin.exe's just to clear the history, not get of subject.

love this new version

[Hypatia]

what extras? how the f disabling or enabling extras can possibly affect decoding speed and how much CPU decoding process utilizes?

in terms of decoding its one of the worst piece of code ive seen

[zot]

Your CPU utilization graph will look like a series of mesas - each mesa representing a text-to-binary decoding cycle- and the faster your download speed, the closer together these mesas get. When the valleys between mesas disappear (which for this decade-old laptop was @ about 20 megabit/sec download speed) then the decoding starts getting backlogged, which besides suffering from the usual problems of a maxed-out processor, it means the PC is at that point running at its fastest effective download speed, regardless of the actual line speed.

There are also ways to set thread priority/CPU utilization so Alt.Binz's decoding spikes don't cause delays with other running processes. My main concern would be how fast is a newsreader allowed to download before maxing out the processor continuously. So for me right now, it's not a big issue. But if I had a gigabit internet connection (and anything less than a "super"-computer) alt.binz would obviously be totally unsuitable.

Just as a casual observation, it seemed to me that most other news clients I've tried, such as Grabit, BNR, NNTPgrab, Xnews, and others used at least as much CPU as Altbinz, though I've never done a formal comparison. (Usenet Explorer is exceptional - kind of like the µTorrent of news clients.) One problem is that news clients have traditionally written downloaded articles to HDD, then turned around and read them back off HDD when decoding (rather than just holding the 15 or 50 MB worth of articles in memory) so that the excess read/write redundancy adds to decoding. I'm not sure if altbinz's settings allow changing this, but I think i remember that function being added a year or so ago.

[mjmacky]

what extras? how the f disabling or enabling extras can possibly affect decoding speed and how much CPU decoding process utilizes?

in terms of decoding its one of the worst piece of code ive seen

You can just chalk that up with JustDOSE just not having a clue.


Your CPU utilization graph will look like a series of mesas - each mesa representing a text-to-binary decoding cycle- and the faster your download speed, the closer together these mesas get. When the valleys between mesas disappear (which for this decade-old laptop was @ about 20 megabit/sec download speed) then the decoding starts getting backlogged, which besides suffering from the usual problems of a maxed-out processor, it means the PC is at that point running at its fastest effective download speed, regardless of the actual line speed.

There are also ways to set thread priority/CPU utilization so Alt.Binz's decoding spikes don't cause delays with other running processes. My main concern would be how fast is a newsreader allowed to download before maxing out the processor continuously. So for me right now, it's not a big issue. But if I had a gigabit internet connection (and anything less than a "super"-computer) alt.binz would obviously be totally unsuitable.

Just as a casual observation, it seemed to me that most other news clients I've tried, such as Grabit, BNR, NNTPgrab, Xnews, and others used at least as much CPU as Altbinz, though I've never done a formal comparison. (Usenet Explorer is exceptional - kind of like the µTorrent of news clients.) One problem is that news clients have traditionally written downloaded articles to HDD, then turned around and read them back off HDD when decoding (rather than just holding the 15 or 50 MB worth of articles in memory) so that the excess read/write redundancy adds to decoding. I'm not sure if altbinz's settings allow changing this, but I think i remember that function being added a year or so ago.

Sounds like you have an Arizona yearning. I can't be absolutely positive, but it feels like you've embedded a Usenet Explorer endorsement in there. I can't for the life of me recall why I swore off UE in the past without ever trying it. It was something someone said in particular... hmmm... damn.

[zot]

I was comparing altbinz vs. UE, and indeed UE has a fraction of the processor load at the same download speed, maybe somewhere around 15%-25% of what altbinz consumes. Altbinz still uses a 'old school'(actually 2nd generation) method (that UE also used a few revisions ago) of writing downloaded articles to disk, then decoding them into rars when enough finish to complete a rar -- while UE creates an eDonkey/Bittorrent-like dummy file at the start of the download - one for every rar- then slowly fills it in with (decoded) articles as they download. This is one big difference between them as far as their download mechanism goes.

It seemed that many of the "first generation" binary newsreaders used a rather queer one-connection-per-rar method that allowed for fast initial download, but then caused computer lockup because all the articles composing each of the rar files would finish at about the same time, so all these rars would decode at about the same time, pegging out the processor. As well as the many other problems that one-connection-per-rar created, I never understood why any newsreader developer back then chose to process binaries this way. (as well as why the Newsflash Plus developer even today insists on this method)

But then emerged Altbinz and the '2nd' generation usenet download clients (not quite newsreaders w/o header support) at least would complete a full rar before starting on the next one, so decodes would overlap throughout the download. I could not notice any visual (eyes on graph) improvement in resource efficiency between the old and new altbinz (if anything it was the opposite) and article decoding still resulted in a hefty processor hit. A difference in settings (default vs. tweaked-years-ago) could have been at least partly responsible for the apparent hunger of v39.4. This was running XP, on a 10 year old laptop that doesn't even handle a lot of recent Java or Python applications very well.

[heiska]

I was comparing altbinz vs. UE, and indeed UE has a fraction of the processor load at the same download speed, maybe somewhere around 15%-25% of what altbinz consumes. Altbinz still uses a 'old school'(actually 2nd generation) method (that UE also used a few revisions ago) of writing downloaded articles to disk, then decoding them into rars when enough finish to complete a rar -- while UE creates an eDonkey/Bittorrent-like dummy file at the start of the download - one for every rar- then slowly fills it in with (decoded) articles as they download. This is one big difference between them as far as their download mechanism goes.

It seemed that many of the "first generation" binary newsreaders used a rather queer one-connection-per-rar method that allowed for fast initial download, but then caused computer lockup because all the articles composing each of the rar files would finish at about the same time, so all these rars would decode at about the same time, pegging out the processor. As well as the many other problems that one-connection-per-rar created, I never understood why any newsreader developer back then chose to process binaries this way. (as well as why the Newsflash Plus developer even today insists on this method)

But then emerged Altbinz and the '2nd' generation usenet download clients (not quite newsreaders w/o header support) at least would complete a full rar before starting on the next one, so decodes would overlap throughout the download. I could not notice any visual (eyes on graph) improvement in resource efficiency between the old and new altbinz (if anything it was the opposite) and article decoding still resulted in a hefty processor hit. A difference in settings (default vs. tweaked-years-ago) could have been at least partly responsible for the apparent hunger of v39.4. This was running XP, on a 10 year old laptop that doesn't even handle a lot of recent Java or Python applications very well.

That was an interesting read. Do you know how Sabnzbd handles the downloading process? It feels very efficient CPU-usage wise on my old laptop, albeit it's a Python app.