http://fossforce.com/2011/08/top-10-things-linux-users-dont-understand/
The post itself is not that interesting and kind of dumb. But the comments sections are much more interesting. The best comment is from "linuxlover" on August 12th, 2011 at 11:05 am.
I use both Windows and Linux and kind of neutral. Windows has many problems. Linux has many problems as well. Linux has many advantages. Windows has many advantages as well.
********* Quote "linuxlover" *****************
Advantages of Linux
1. App bugs will get fixed when a new student takes over from the one that graduated and got a job.
2. The packaging chaos will get fixed, since the Darwinian process works (only needs a few million years).
3. The desktop chaos will get fixed for the same reason.
4. Linux distros will stop competing with each-other and start focusing on Microsoft.
5. Ubuntu’s 80,000 open bugs will make them releasing when ready instead of every 6 months.
6. Instead of dozens of half-finished programs for a given application, there will be 1-2 really excellent ones.
7. Unity may get modified to be effective for monitors over 800 pixels.
8. Compiz may get fixed for high-speed window updates.
9. A serious standards body will develop and enforce sensible standards (packaging, desktop, libraries, binary API, GUI API).
10. If you are having problems, you can choose from hundreds of distros that will have different problems.
I actually use and enjoy Linux, but let’s face the problems honestly.
**********************************************
Saturday, August 13, 2011
OpenOCD 0.5.0 release Windows binary download
OpenOCD 0.5.0 has been released. Here is the News.
Source zip archive or tar ball can be downloaded from SourceForge.
Windows binaries (32bit and 64bit, cross build under Linux with MinGW-w64 project's compiler) can be downloaded from Freddie Chopin's website.
You can also use my test build which is native Windows build using 32bit MinGW.org toolchain.
Take note due to GPL licensing reasons, these Windows binaries are linked against libusb-win32 and libftdi and not the proprietary FTDI D2xx library.
Source zip archive or tar ball can be downloaded from SourceForge.
Windows binaries (32bit and 64bit, cross build under Linux with MinGW-w64 project's compiler) can be downloaded from Freddie Chopin's website.
You can also use my test build which is native Windows build using 32bit MinGW.org toolchain.
Take note due to GPL licensing reasons, these Windows binaries are linked against libusb-win32 and libftdi and not the proprietary FTDI D2xx library.
Tuesday, August 2, 2011
USB CDC-ACM is really meant for USB Modem
Many users use USB CDC-ACM for virtual com port usage. It
is supported under Windows by the usbser.sys driver and
also works under Linux and Mac OS X and probably other OS
as well.
In reality, CDC-ACM is really meant for modems.
http://www.usb.org/developers/devclass_docs/usbcdc11.pdf
"3.6.2 Abstract Control Model
With an Abstract Control Model, the USB device understands standard
V.25ter (AT) commands. The device contains a Datapump and micro-controller
that handles the AT commands and relay controls. The device uses both a
Data Class interface and a Communication Class interface."
Microsoft states that usbser.sys is really meant for
USB modems.
http://social.msdn.microsoft.com/Forums/en-ZA/wdk/thread/993f5ce0-3ed1-45a9-a9fa-5d02626164d6
"usbser.sys is only good enough of a virtual serial port implementation to
enable it to be used as a modem".
Apple even insists that it is for network device (a USB modem is
a networking device) and insists to bring up the network configure
dialog. Here is an heated debate thread in Apple USB mailing list.
http://lists.apple.com/archives/usb/2011/Jun/msg00009.html
And Linux will issue a warning about a USB CDC-ACM device
if it is not a modem.
http://lxr.linux.no/#linux+v3.0/drivers/usb/class/cdc-acm.c
917 case USB_CDC_CALL_MANAGEMENT_TYPE:
918 call_management_function = buffer[3];
919 call_interface_num = buffer[4];
920 if ( (quirks & NOT_A_MODEM) == 0 &&
(call_management_function & 3) != 3)
921 dev_err(&intf->dev, "This device
cannot do calls on its own. It is not a modem.\n");
922 break;
is supported under Windows by the usbser.sys driver and
also works under Linux and Mac OS X and probably other OS
as well.
In reality, CDC-ACM is really meant for modems.
http://www.usb.org/developers/devclass_docs/usbcdc11.pdf
"3.6.2 Abstract Control Model
With an Abstract Control Model, the USB device understands standard
V.25ter (AT) commands. The device contains a Datapump and micro-controller
that handles the AT commands and relay controls. The device uses both a
Data Class interface and a Communication Class interface."
Microsoft states that usbser.sys is really meant for
USB modems.
http://social.msdn.microsoft.com/Forums/en-ZA/wdk/thread/993f5ce0-3ed1-45a9-a9fa-5d02626164d6
"usbser.sys is only good enough of a virtual serial port implementation to
enable it to be used as a modem".
Apple even insists that it is for network device (a USB modem is
a networking device) and insists to bring up the network configure
dialog. Here is an heated debate thread in Apple USB mailing list.
http://lists.apple.com/archives/usb/2011/Jun/msg00009.html
And Linux will issue a warning about a USB CDC-ACM device
if it is not a modem.
http://lxr.linux.no/#linux+v3.0/drivers/usb/class/cdc-acm.c
917 case USB_CDC_CALL_MANAGEMENT_TYPE:
918 call_management_function = buffer[3];
919 call_interface_num = buffer[4];
920 if ( (quirks & NOT_A_MODEM) == 0 &&
(call_management_function & 3) != 3)
921 dev_err(&intf->dev, "This device
cannot do calls on its own. It is not a modem.\n");
922 break;
Sunday, July 24, 2011
libftdi 0.19 and libftdi-1.0 git MinGW binaries download
Here are the unofficial libftdi-0.19 and libftdi-1.0 binaries download.
http://code.google.com/p/picusb/downloads/list
They are cross-built under Linux with MinGW and MinGW-w64. So if you have some difficulties getting them to be built under Windows, you may want to try out the binaries I built.
http://code.google.com/p/picusb/downloads/list
They are cross-built under Linux with MinGW and MinGW-w64. So if you have some difficulties getting them to be built under Windows, you may want to try out the binaries I built.
Sunday, July 10, 2011
Arch Linux Gnome 3 with Nvidia Driver Problem Workaround
I have some problems with Gnome 3 (Gnome Shell) with the Nvidia 3. The main thing is that sometimes texts will get corrupted when you scroll down a website under Firefox. It can take some efforts to to click some links in Firefox for some websites (like the links below any LinuxToday articles). The first link is there, but when you scroll down and try to click it, it disappeas and the text below that becomes corrupted. Most likely it is an Nvidia driver problem but I have updated to the latest version from Arch. And I do not have such a problem under Ubuntu 11.04 with Unity.
In the end the workaround provided in Arch Forum works, press ALT+F2 and type "r" and then everything is fine.
Quote from that Arch Forum article:
"Have you tried Alt+F2 to open a command prompt then entering r ? I think I get the same thing you get when I come out of suspend and r at the command prompt resets the Gnome Shell and fixes the problem. I'm also using the closed source Nvidia driver."
Notes added on 17 July 2011: it still does not work well, still has the garbled text problem. So I just switched to the Fall Back mode by default.
Notes added on 21 July 2011: it seems that the latest NVidia driver improved on the issue (275.19-1 version) but I still see text corruption when scrolling with a mouse under Firefox and Gnome 3.
In the end the workaround provided in Arch Forum works, press ALT+F2 and type "r" and then everything is fine.
Quote from that Arch Forum article:
"Have you tried Alt+F2 to open a command prompt then entering r ? I think I get the same thing you get when I come out of suspend and r at the command prompt resets the Gnome Shell and fixes the problem. I'm also using the closed source Nvidia driver."
Notes added on 17 July 2011: it still does not work well, still has the garbled text problem. So I just switched to the Fall Back mode by default.
Notes added on 21 July 2011: it seems that the latest NVidia driver improved on the issue (275.19-1 version) but I still see text corruption when scrolling with a mouse under Firefox and Gnome 3.
Sunday, May 1, 2011
Gnome 3 and Gnome Shell First Impression
I just updated my Arch Linux installation and it has Gnome 3 by default. I followed the Arch Wiki about Gnome 3 for the installation and it went smooth.
As for the first impression, it is at least much better than Ubuntu Unity interface. For one thing, it does not have the annoying Global Menu. However, I still prefer the old Gnome 2 interface. Anyway, the new interface is at least tolerable, not like Ubuntu Unity. I think I can get used to it soon even though I still miss the Gnome Panel Applets.
I tend to think Unity is one way for Ubuntu to differentiate it from other Linux distros, let's wait and see if that really pans out well for Ubuntu or not.
Notes added on 17 July 2011: however, the problem is with the Nvidia driver. Gnome 3 just does not work well with the Nvidia driver right now under Arch Linux. So I have to switch back to the Fall Back mode.
As for the first impression, it is at least much better than Ubuntu Unity interface. For one thing, it does not have the annoying Global Menu. However, I still prefer the old Gnome 2 interface. Anyway, the new interface is at least tolerable, not like Ubuntu Unity. I think I can get used to it soon even though I still miss the Gnome Panel Applets.
I tend to think Unity is one way for Ubuntu to differentiate it from other Linux distros, let's wait and see if that really pans out well for Ubuntu or not.
Notes added on 17 July 2011: however, the problem is with the Nvidia driver. Gnome 3 just does not work well with the Nvidia driver right now under Arch Linux. So I have to switch back to the Fall Back mode.
Friday, April 29, 2011
Ubuntu 11.04 -- Unity Interface is not usable
I have just updated my Ubuntu 10.10 installation to 11.04. To be honest, I do not like the new Unity interface. I would say the old Gnome interface is much easier to use. Windows 7 is also way better. I might be able to get used to it in the future, but for now I will go back to the classic desktop and wait for Ubuntu to fix the Unity interface.
Major problems:
1) The launcher is basically useless, the autohide works too well so that it does not come out when I need it from time to time.
2) Software center is getting better but I still prefer Synaptic. Anyway, Synaptic is still there.
3) There is no "Show Desktop" icon. This is not that bad but still I prefer to have it.
4) I miss the gnome-panel applets.
5) I do not like the global menu. This is the most annoying feature. I do not have a Mac and I am not used to this "feature".
6) I do not quite like Dash, I prefer the old Gnome menu system where I can access the applications with less mouse clicks.
Anything I like about Unity? Nothing!
I think Unity will be like KDE 4 when it was first launched (I still do not install KDE now) and it will take some time for Ubuntu to fix it. Maybe Ubuntu Unity can get usable next year, say 12.04.
Anyway, there seems to be a good guide for those who want to use Unity.
http://castrojo.tumblr.com/post/4795149014/the-power-users-guide-to-unity
Edits on 1 May 2011:
After disable the global menu and fix the launcher to never hide and add some common application to the Launcher, the Unity Interface is at least tolerable again.
Still need to find a way to move the maximize/minize/close buttons to the right when application is maximized. When it is not maximized, the buttons are on the right which is fine, but they move to the left when the application is maximized. This is quite annoying.
Notes on 17 July 2011:
Enabled the global menu for a while and still does not like it very much, but it can be tolerable now. And I keep the maximize/minimize/close button to the default left side now.
So Unity interface is usable now, but still not that good.
Major problems:
1) The launcher is basically useless, the autohide works too well so that it does not come out when I need it from time to time.
2) Software center is getting better but I still prefer Synaptic. Anyway, Synaptic is still there.
3) There is no "Show Desktop" icon. This is not that bad but still I prefer to have it.
4) I miss the gnome-panel applets.
5) I do not like the global menu. This is the most annoying feature. I do not have a Mac and I am not used to this "feature".
6) I do not quite like Dash, I prefer the old Gnome menu system where I can access the applications with less mouse clicks.
Anything I like about Unity? Nothing!
I think Unity will be like KDE 4 when it was first launched (I still do not install KDE now) and it will take some time for Ubuntu to fix it. Maybe Ubuntu Unity can get usable next year, say 12.04.
Anyway, there seems to be a good guide for those who want to use Unity.
http://castrojo.tumblr.com/post/4795149014/the-power-users-guide-to-unity
Edits on 1 May 2011:
After disable the global menu and fix the launcher to never hide and add some common application to the Launcher, the Unity Interface is at least tolerable again.
Still need to find a way to move the maximize/minize/close buttons to the right when application is maximized. When it is not maximized, the buttons are on the right which is fine, but they move to the left when the application is maximized. This is quite annoying.
Notes on 17 July 2011:
Enabled the global menu for a while and still does not like it very much, but it can be tolerable now. And I keep the maximize/minimize/close button to the default left side now.
So Unity interface is usable now, but still not that good.
Thursday, April 28, 2011
OpenUSB is alive again
After a long gap, Michael Lewis just announced the release
of OpenUSB 1.1.1.
Website: http://sourceforge.net/projects/openusb.
Highlights of the release:
1) Removed the HAL/DBUS dependency for hotplug events.
2) Improved kernel version checking for the bulk continuation flag.
3) Improved support for zero byte transfers
4) Changed the maximum control transfer size to 4096
According to Michale, these changes are primarily in response to making OpenUSB compatible with the latest distributions.
Compared to libusb-1.0, OpenUSB is not used by many projects. However, it does have two advantages compated to libusb-1.0. It also claims to have better multi-threading support.
1) Hotplug support
2) Solaris support
libusb-1.0 is more widely used and the Windows backend will bring even more users for libusb-1.0. However, it is also good to see that OpenUSB is still alive. If Windows support for OpenUSB is done within a reasonable timeframe, then it would be even better.
of OpenUSB 1.1.1.
Website: http://sourceforge.net/projects/openusb.
Highlights of the release:
1) Removed the HAL/DBUS dependency for hotplug events.
2) Improved kernel version checking for the bulk continuation flag.
3) Improved support for zero byte transfers
4) Changed the maximum control transfer size to 4096
According to Michale, these changes are primarily in response to making OpenUSB compatible with the latest distributions.
Compared to libusb-1.0, OpenUSB is not used by many projects. However, it does have two advantages compated to libusb-1.0. It also claims to have better multi-threading support.
1) Hotplug support
2) Solaris support
libusb-1.0 is more widely used and the Windows backend will bring even more users for libusb-1.0. However, it is also good to see that OpenUSB is still alive. If Windows support for OpenUSB is done within a reasonable timeframe, then it would be even better.
Wednesday, April 27, 2011
Python and USB HID Device
(This is my post to pyusb mailing list on 27-April-2011)
Just a summary for the situation.
Firstly you may want to see if you really want to use
a generic HID device, in most cases, you can use
a custom device and then use libusb0.sys or winusb.sys
as the driver under Windows and then use pyusb with it.
Using a custom device will also make it possible to use
pyusb under Mac OS X. Recent Mac OS X makes it
very difficult (or impossible) to detach the kernel HID driver.
In that case, it is not possible to use libusb (0.1 or 1.0)
and thus pyusb with the device.
So if you really want to use pyusb and care about
cross-platfrom, then you should forget about generic
HID device and use a custom device instead.
If you really need to use HID device, there are a few
options.
1) If you only cares about Linux, then you can use
pyusb with no issues. libusb under Linux can detach
the kernel HID driver.
2) If you only care about Windows, you may want
to look at pywinusb.
http://code.google.com/p/pywinusb/
3) If you really want to use pyusb under Windows with the
HID device, you can use libusb-win32 filter driver for
that particular HID device. Please use the latest
libusb-win32 for this purpose. And take note this is
not a recommended solution.
4) If you want to have cross-platform support for the
HID device, then you need to look at HIDAPI and
use the python binding for it. Take note the python
binding for HIDAPI is not mature yet.
http://libusb.6.n5.nabble.com/Opinion-HID-and-Windows-back-end-td3716872.html
http://comments.gmane.org/gmane.comp.python.pyusb.user/749
5) Another option under Windows is to use the HID branch
of the libusb-pbatard git repo or older version of libusb-pbatard
(up to pbr332). This is not recommended as the official stand
of libusb-1.0 admin is not to support HID native backend under
Windows.
Just a summary for the situation.
Firstly you may want to see if you really want to use
a generic HID device, in most cases, you can use
a custom device and then use libusb0.sys or winusb.sys
as the driver under Windows and then use pyusb with it.
Using a custom device will also make it possible to use
pyusb under Mac OS X. Recent Mac OS X makes it
very difficult (or impossible) to detach the kernel HID driver.
In that case, it is not possible to use libusb (0.1 or 1.0)
and thus pyusb with the device.
So if you really want to use pyusb and care about
cross-platfrom, then you should forget about generic
HID device and use a custom device instead.
If you really need to use HID device, there are a few
options.
1) If you only cares about Linux, then you can use
pyusb with no issues. libusb under Linux can detach
the kernel HID driver.
2) If you only care about Windows, you may want
to look at pywinusb.
http://code.google.com/p/pywinusb/
3) If you really want to use pyusb under Windows with the
HID device, you can use libusb-win32 filter driver for
that particular HID device. Please use the latest
libusb-win32 for this purpose. And take note this is
not a recommended solution.
4) If you want to have cross-platform support for the
HID device, then you need to look at HIDAPI and
use the python binding for it. Take note the python
binding for HIDAPI is not mature yet.
http://libusb.6.n5.nabble.com/Opinion-HID-and-Windows-back-end-td3716872.html
http://comments.gmane.org/gmane.comp.python.pyusb.user/749
5) Another option under Windows is to use the HID branch
of the libusb-pbatard git repo or older version of libusb-pbatard
(up to pbr332). This is not recommended as the official stand
of libusb-1.0 admin is not to support HID native backend under
Windows.
Saturday, April 16, 2011
libftdi and OpenOCD binary download
libftdi-0.18 and libftdi-1.0 binaries and OpenOCD git binaries download
http://code.google.com/p/picusb/downloads/list
I have uploaded some Windows (32bit and 64bit) binary of libftdi and OpenOCD to my Google Code picusb page. Most of them are cross-built under Linux with MinGW and MinGW-w64. So if you have some difficulties getting them to be built under Windows, you may want to try out the binaries I built.
http://code.google.com/p/picusb/downloads/list
I have uploaded some Windows (32bit and 64bit) binary of libftdi and OpenOCD to my Google Code picusb page. Most of them are cross-built under Linux with MinGW and MinGW-w64. So if you have some difficulties getting them to be built under Windows, you may want to try out the binaries I built.
Updated Microchip USB Links and Microchip Stack Anomaly list
PIC USB related web sites
http://www.microchip.com/forums/m123533.aspx
PIC USB Firmware Framework Confirmed and Potential Anomalies
http://www.microchip.com/forums/m275422.aspx
The above links should help the users of Microchip USB PICs.
http://www.microchip.com/forums/m123533.aspx
PIC USB Firmware Framework Confirmed and Potential Anomalies
http://www.microchip.com/forums/m275422.aspx
The above links should help the users of Microchip USB PICs.
Subscribe to:
Posts (Atom)