Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 388. (Read 5805537 times)

Both. For the network analogy, libusb would be libpcap - it adds some programmer-friendly abstractions on top of a raw socket. It's still working with low-level raw sockets, but in an abstracted way.

If Kano's lies were true, perhaps. But "30 year old serial I/O libs" is not quite right. While the interface may be 30 years old, the code behind it certainly isn't. Nor is there any need for a new interface. It's also a "library" builtin to the OS itself, so pretty much as little overhead as you can get.
On the other hand, libusb is designed for raw USB access, and non-native on at least Windows. But it does add a lot of abstraction which theoretically harms performance. It then goes and does the same things as the "30 year old serial I/O libs" using a non-standard interface. libusb is nice when there are no existing drivers, but totally the wrong tool for these specific devices. Unfortunately, libusb also lacks any support for asynchronous access on Windows too, which makes some device API improvements impractical - before I can move BFGMiner to a completely asynchronous model, I would need to first do some major improvements to the underlying libusb library itself.

Edit: Disclosure... there is one reason I can see using libusb could be beneficial: unfixed bugs in the OS/official OS drivers, or workarounds for buggy hardware. This is the case with Windows's ACM driver (used by ModMiner) - but easily worked around in software (as BFGMiner has done for a while). The chip used in the Icarus also had a bug that prevented it from working with certain USB hosts - this too, was easily worked around in software. But those are the only reasons I can see using libusb would make sense for a device using a serial interface, and they're already managed just fine without it.

You mean the current, supported, standard interface, instead of bypassing it to use a low-level interface that has no benefit whatsoever.

It's like writing your own TCP/IP stack instead of using the one included in the OS. Not only is it stupidly redundant, it also means you've lost support, driver updates, ease of use, forward compatibility with new hardware, and regular-user-mode access.

Well, if you consider the fact that shortly, when indeed GPU mining will be deprecated, that the crappy clone will ONLY be using the old termios serial IO libraries that were designed around 30 or more years ago, meanwhile, cgminer has been updated to use the libusb library to talk directly to the USB devices rather than via the old serial libraries that put an old interface in front of the USB devices and restrict access to most of the USB functionality ... yes it's quite clear that the clone is old technology and written using the serial library because the guy who wrote it was not only fail in programming ability he chose the simplest interface with the most restrictions coz he had no idea what he was doing ...

You missed the point. CGMiner is also deprecated software for deprecated technology (GPUs).

"Fork as BFGMiner"

Mmmmm ya Im gonna call Major Douche on this one

You forgot to click on that link one line above your FUD where YOU committed the changes with the words you wrote:
"Fork as BFGMiner"

Come on, all these lies you keep posting are rotting your brain, at least try to not also include the proof it's a lie, one line above what you type

No, I think he has way more problems than just Windows. 

There's your problem.

No, you and Con decided to fork the project because he was upset over the announcement of ASICs.
Yes, clearly-labelled alpha releases might be broken! That's to be expected. That's why they're alpha.

That is software that you posted on the public (crappy) bitcoin wiki on the avalon page for people to use ...
You have also ALREADY got in your clone miner the software for the BFL ASIC hardware that is COMPLETELY UNTESTED.
The hardware doesn't exists yet.
Everyone using your crappy clone miner has that completely UNTESTED code in it.
Your complete lack of testing your crappy code was one of the main issues that you used as an excuse to clone cgminer - when you wrote crappy untested changes to the icarus code that you NEVER tested on window - and it didn't work at all - it locked up cgminer - and you ranted about me overwriting your code that didn;t work ... then decided to clone cgminer and change the names and the donation address:
https://github.com/luke-jr/bfgminer/commit/b9df56511c7bd1a2e1f075e9c184c1a4b0f1ba20

I don't lie. Anyone with a clue can clearly see that an occurance of bricking a controller with a test build clearly marked as possibly having that effect, is not remotely the same thing as "BFGMiner ... brick mining hardware", nor does one person mentioning the result as such make it "well known". Too bad you're too busy trolling to have a clue.

Well I'm outta here again, time to take a break from these forums for my sanity till something hardware happens and/or the trolling stops..

And just to completely and simply prove that Luke-Jr lies and knows he is lying but has no issue with posting lies on this forum as he does REGULARLY - here is a direct link and quoted copy of the post in his thread that he knows about that says it bricks, and even Luke-Jr's warning about his software possibly bricking ... which it does:
https://bitcointalksearch.org/topic/m.1689104

How lucky am I? Is this an easter present from our friendly local christian to come trolling my thread again? It seems the forum mods are even on your side and refuse to accept your posts as trolls, nice to see lack of impartiality there. Let's see how long this post lasts.

As usual, this is a lie.

However, please note that BFGMiner is well known to brick mining hardware. Avoid it.
Stay with cgminer, it works on that hardware that the crappy BFGMiner clone bricks.

BFGMiner has w64-related bugs fixed and officially supported.