Microsoft hates it when its customers wish to install Linux or other operating systems on its PCs. A Redditor has expressed concern over his inability to install Linux on a Yoga 900 ISK2 Ultrabook
Source: Warning: Microsoft Doesn’t Want You To Install Linux On Its “Signature PCs” (Fossbytes)
The privacy world is peeved at Apple again. It’s emerged that anyone who uses the Spotlight feature in either Mac OS X Yosemite or iOS 8 will have their location and search data passed to Apple servers. The same data will also be sent to Microsoft …..
Full article here:
Spotlight: Privacy Advocates Furious As Apple Feature Siphons Off Location Data of Yosemite And iOS 8 Users (Forbes)
Related:
Apple’s Mac computers can automatically collect your location information (Washington Post)
How to Stop Apple From Snooping on Your OS X Yosemite Searches (Wired)
fix macosx
The Consumerist is just waking up to a fact that many of us Google Voice users realized a long time ago: There is virtually no such thing as customer support at Google Voice. For example, they still haven’t fixed the bug that even if you disable call screening, it’s still turned on if the calls are delivered via Google Chat, and that’s been a problem for at least three or four years now. Nor have they come up with a way to change the amount of time the call rings at the destination before Google snatches it back and sends it to Google Voice’s voicemail (approximately 25 seconds is just too short in some situations).
The Consumerist article doesn’t touch on either of those specific issues, but at least they’re beginning to understand that the complete lack of effective support at Google Voice can really be a problem:
Google Voice Customers Cry Out For Help, No One At Google Hears Them (The Consumerist via the Wayback Machine)
Yes, I know it’s a free service and some will say you get what you pay for, and I guess that will fly as long as the service remains free, but when they charge for a service (such as the number port mentioned in the article) then they should at least have an effective way to address issues and complaints about the services people have paid for (and perhaps not received)!
This falls into the category of “notes I am posting for myself so I don’t lose them”. A Logitech C910 Webcam works under Mac OS X (more or less — some users have had more success than others), but the Logitech Webcam Software is buggy and Logitech seems to be in no big hurry to fix it, as can be attested to by the many posts in their Webcams forum complaining about problems using the device with a Mac. I followed all the instructions in this thread (which was actually for OS X 10.6 but I was grasping at straws) but nothing helped – after I uninstalled and reinstalled the Webcam software, it would run fine ONCE and then after that, every time I’d try to run it again, it would crash immediately after opening. This was not always the case, but perhaps something was broken during an upgrade.
I figured out that if I go into /Users/username/Library/Preferences/ and remove the files com.logishrd.LWS.plist and com.logishrd.LWS.plist.lockfile it would then not crash on the next run attempt. So, Logitech’s software is buggy because the mere presence of these files should not cause the software to crash. Note this is with the lws220.dmg software so if they ever release a newer version it just might fix the problem.
I suppose you could write an AppleScript to delete the two offending files and then launch the Logitech Webcam Software, but I have not got around to that yet (I An Not A Programmer). My question is, why doesn’t Logitech fix their damn software instead of leaving OS X users hanging, waiting for a solution? People have been complaining about these issues for at least a year and a half now!
We recently changed out a case on a computer power supply. The new case is metal whereas the old one was plastic, and as I was plugging in a USB cable from a USB hub I got a shock. Not only that, when I accidentally touched it to the bottom of the computer’s case, the computer power supply completely shut down and would not restart until I physically removed the power cord and plugged it back in. Since this hub had worked just fine with the old case, it led me to wonder what the issue was. I put a voltmeter on the shell of the USB cable and measured about 50 volts AC to ground!
To make a long story short, I have four external USB drives plugged into that hub and they are all Western Digital. Every single external hard drive had AC voltage on its USB cable shell (when disconnected from the hub), whereas no other devices had more than a volt or two.
That led me to disconnect the power supplies from each of the hard drives, at which point I made a, um, shocking discovery!
I measured the voltage from the power supply DC plugs to ground. For this test I plugged them into an outlet on a totally different circuit from the one I plug my computers into, since a friend has suggested that the outlets might be miswired (hot and neutral reversed). I tested for that possibility and that was not the case, but it was still easier to take them out to the kitchen for this test. I photographed the results for three of them but a fourth gave similar results. I’m sorry that the pictures are a bit blurry but if I’d used flash it would have washed out the LED display so the exposure times were a bit longer than I would have liked, given that my hand isn’t all that steady.
EDIT: For a few hours after I first posted this, I had image #1 duplicated as #3. Sorry about that.
A few observations I noted while testing the voltage:
It didn’t matter which way the AC plug was inserted into the socket – the voltage was the same or very nearly the same (within a couple of volts) either way.
It didn’t matter whether I measured to the center or the shell of the DC plug – the voltage was exactly the same either way (this makes me think the leakage might be through a capacitor or capacitors, since otherwise there would be a DC short).
Whatever voltage I measured at the power supply found its way to the USB plug shell once the power supply was connected to the hard drive.
I measured this on FOUR different power supplies, all ones that came with Western Digital hard drives of various sizes. On three I got the 44 volt reading and on one I got 57 volts.
If it were just one or two power supplies doing this, I’d suspect a flaw in that power supply. But since every single one of them is doing it, I have to think it is something inherent in the design of the switching power supplies used with external hard drives. For some reason this never caused any problem with my old computer or case but this new one (new case) can get really strange if you connect or disconnect the USB hub while it is running and the power cable is connected. I just hate the fact that there is this much stray AC but it must be a problem specific to the hard drive power supplies so I don’t think there is anything I can do about it.
I don’t know of any way to correct this problem, or even if it really is a problem. But I REALLY don’t like it!
By the way, I don’t mean to impugn Western Digital specifically, it’s just that right now all four of the external drives connected to this particular computer are WD’s. I do NOT know whether or not this problem affects power supplies that come with other makes of hard drives (if anyone wants to test yours and post the results in a comment, I’d appreciate it, but please don’t unless you have worked with electricity enough to know how to do the test safely, since I will not be responsible if you fry yourself or your equipment because you didn’t know how to do the test!).
This article was originally posted in June, 2010.
I recently had the experience of trying to help someone make a Sangoma USBfxo device (model U100) work on a server that runs FreePBX and Asterisk. The advertised features of this device are as follows:
The first thing I would note is that although you don’t have to open up the computer, it’s definitely not “plug and play.” At the very least you have to install driver software, and on an Asterisk server you will also need to install and configure DADHI or ZAPTEL (unless this has already been done). Depending on your level of expertise, this might be easy, or quite daunting. I would certainly take issue with the claim of “easy installation” although I can understand how a true Linux geek might consider it a walk in the park. It wasn’t so much that there were any major hitches in the installation as that it was time consuming and required quite a bit of mental effort to figure out what needed to be done — someone who has just set up a PBX using a “load and go” distribution like Elastix, PBX in a Flash, AsteriskNOW, Trixbox, etc. might not find it all that easy to get this thing working.
The major issue we had was with the performance. We initially discovered that it was “clipping” speech severely, causing audio artifacts that are difficult to describe in print, but unpleasant to hear. We got in touch with Sangoma customer support and finally traced the problem to the built in hardware echo cancellation. By disabling the hardware echo cancellation, the speech was clear, but of course we then had mild echo. Enabling echo cancellation in Zaptel fixed that on a temporary basis, but about a week later Sangoma customer support e-mailed us and suggested that we try OSLEC, the open source echo canceler. We might have actually done that had we not discovered another issue in the meantime, that made us decide we didn’t want to mess with this unit anymore.
This new issue was that initially, it did not pick up incoming caller ID on incoming calls. We discovered that this could be fixed by changing the gain settings in Zaptel, but even when we did that it still wasn’t 100% reliable (I’d say it worked about 90% of the time). And, the downside of that was that we had to reduce the incoming gain, so that it was harder to hear callers.
We’ve used Sipura SPA-3000’s before for this same function, although they are only single line units (they have one FXS port and one FXO port) and have never had any of these issues. The main reason we tried the USBfxo was because we wanted two FXO ports, and also liked the idea that it was powered off the USB cable, and didn’t require us to have yet another device with a “wall wart” to plug in. But the difficulties with Caller ID, volume levels, and the fact that Sangoma had apparently given up on getting the hardware echo cancellation to work without distorting the audio led us to get frustrated with this device fairly quickly. The non-techies that had to make and receive calls that went through this device were not very understanding of the issues, especially since the SPA-3000’s (now superseded by the Linksys SPA-3102, which is essentially an updated version of the Sipura SPA-3000) had always worked much more reliably. We finally gave in and found another Sipura SPA-3000 on eBay and put it into service, and within a relatively short time (part of which was spent locating and installing updated firmware) it was working like a champ. Unlike the Sangoma, it detects the Caller ID 100% of the time, and we can tweak the transmit and receive gain to comfortable levels.
My personal opinion is that Sangoma should be ashamed to put their name on the USBfxo. The hardware echo cancellation, in a word, sucks. And one of the big reasons you’d buy a brand like Sangoma in the first place is because of the supposedly superior echo cancellation. Echo cancellation is supposed to cancel echo, not make it sound like your words are clipped. My guess is that the hardware echo cancellation is far too aggressive and they don’t give you any way to “tune” it — you can either enable or disable it, but that’s all. The USBfxo is a great idea, but it needs to go back to the drawing board. Sangoma’s motto (shown on their Wiki pages, etc.) is “Because it must work!”, but apparently that motto does not imply that it must work well!
Also, a note to Sangoma customer service — next time a customer is dropping hints that they’d like you to take your defective unit back and send a replacement, you might want to be a bit more responsive to that request. We were willing to work with you up to a point but the message came through loud and clear that you really didn’t want to replace this dog of a device unless you absolutely had to. We didn’t sign up to be beta testers, we just wanted the damn thing to work. Given Sangoma’s (perhaps undeserved) reputation we really thought you’d be more agreeable to making sure that we got a unit that worked, not making us try a bunch of different things and then ultimately told to try OSLEC, effectively giving up hope that the hardware echo cancellation would ever work properly.
Another suggestion to Sangoma (or any other manufacturer that may be listening) — most of us who did not cut our teeth on Linux would probably prefer not to have to mess with ZAPTEL or DADHI. The nice thing about the Linksys/Sipura devices is that they sit out on the network and appear as just another SIP-based device, and in FreePBX you configure them pretty much as you would any other SIP trunk. I’m not saying that installing any of these devices is the proverbial “piece of cake”, especially if you have never done it before, but when you have to start installing and configuring drivers, that goes outside of the realm of what I would consider easy to install. What someone really needs to come out with is an inexpensive four to six-port SIP based FXO device that sits out on your local network, like the SPA-3000/3102.
If you are in need of one or two FXO ports for your Asterisk server, my advice would be to first try one or two Sipura SPA-3000 or Linksys SPA-3102 devices (following these instructions if you are a FreePBX user) — if those do not work the way you’d like, you can always resell them on eBay and then try a more expensive solution. If your server doesn’t have card slots (as is increasingly the case, as users turn to small computers like the Acer Aspire Revo to use as small, power-efficient PBX’s) then your choices are limited to external devices such as the aformentioned units. However, if your system can accept internal cards, then you can buy cards that provide FXO ports from several manufacturers, including Digium and Sangoma (if you need eight or more FXO ports than I believe there are other external options, but they are quite a bit more pricey and I have not really investigated them, so I won’t comment on them at this point. However, if any manufacturer would care to send a review sample, I’d be more than happy to give it a try!). 😉
The one caveat I will add is that not every device will work on every line. If you have a very long line from a traditional telephone company, your requirements (and experience with a particular device) may be quite different from someone who is sitting 500 feet from the central office, or someone who’s trying to take the output of a cable company’s VoIP adapter and pipe it over to the FXO card or device using twenty feet of copper wire. Just because the Sipura devices have worked better for us does not mean they will for you. I’m guessing that some people have purchased the exact same Sangoma device that we tried and were able to get it working well enough for their needs, but I just cannot recommend this device — at least not until Sangoma fixes the echo cancellation, and makes it read the incoming Caller ID reliably 100% of the time, preferably without having to change the incoming gain in DADHI or ZAPTEL.
EDIT: For more comments/opinions on this device (and on this review), see this thread on the PBX in a Flash forum.
If you bought a Sharp LC-42SB45U TV, perhaps because it was on a super great (and very lightly advertised) deal at Wal-Mart back in November, and then later tried to hook up a home theater PC to it, you may have been disappointed to discover that unlike most flat screen digital TV’s it doesn’t have a “pixel-to-pixel” or similar 1:1 pixel mapping mode. The result is that when you hook up a computer to one of the HDMI ports, there is a serious overscan problem — for example, if you are running Ubuntu Linux (or some other version of Linux) you won’t see the top or bottom menu bars, because they are outside the visible screen area. If you use XBMC or Boxee, you can go into that program’s settings menu and apply overscan correction from within the program, but most other programs and video players don’t offer an overscan correction option.
The problem is not that there’s no “Dot by Dot” setting in the Sharp TV — it’s just that it’s a (very) hidden option, and as far as I know, there is nothing you can do using the buttons on the TV or on the remote to make it appear (I’d be very happy to be proven wrong on this point; if there is some sort of hidden remote control key sequence that can make the Dot by Dot option always appear, I wish someone would spill the beans so we can fix this issue the right way). But with one small tweak in a Linux configuration file, you can make it appear, like so:
My first approach to this came at a cost: I read that if you could send the Sharp a non-standard vertical sync frequency (refresh rate) a bit below the normal 60 Hz, the alternate View Mode would appear. That did work, and in my non-scientific testing, I found that 59.55 Hz was about the cutoff point. Anything above that, and you get the normal menu of View Mode options when you press the View Mode button on the remote. Anything at about that or below, and you get the View Mode options menu shown above. However, this was certainly less than ideal because of the non-standard refresh rate. I got started on that path after reading a forum post that suggested a custom ModeLine in your /etc/X11/xorg.conf file to give you a 1816×1026 display. While this will work to fix the overscan, it also cuts down on the pixels available to programs, and makes things not quite as sharp (no pun intended) as they should be.
Now, the idea of using a custom ModeLine in your /etc/X11/xorg.conf file is not a bad idea, and the above-referenced post did contain some good information (especially about disabling some unwanted Ubuntu packages that might cause your xorg.conf to be ignored). So I tried the xorg.conf shown in that post, except I used the original ModeLine shown (which is correct for the Sharp LC-42SB45U as long as you don’t mind the overscan). I then read in another forum post (on a different site) that someone had found that the Dot by Dot option would appear if the refresh rate were set to 59 Hz rather than 60 Hz. However they were doing that on a Windows machine, not a Linux box, if I recall correctly.
But again, that had the disadvantage of a non-standard refresh rate. I’ve read on several sites that the ideal refresh rate is 59.94 Hz (it’s very close to 60 Hz and is exactly twice the ATSC 1920×1080 progressive scan frequency of 29.97 Hz) so my goal was to get as close to that as possible. I then read that someone had actually accomplished this on a Windows box by changing the timing to something called “CVT reduced blank” (the procedure on a Windows box is to bring up the NVIDIA Control Panel, then click on Change Resolution, then Add Resolution, then Create Custom Resolution, then in the “Timing” section find the “Standard” drop-down box and select CVT reduced blank. Make sure the other settings look sane, click the Test button and go from there. Mac OS X users can do something similar using a program called SwitchResX — see Brian Semiglia’s comment in the Comments section for a link to instructions. The reason this doesn’t work under Linux is that the Linux version of the NVIDIA Control Panel doesn’t offer this level of functionality, and also, some might encounter this issue even if not using NVIDIA graphics). So my goal was to find a ModeLine that would do the CVT reduced blank but not use a non-standard screen size nor refresh rate. After searching the web, playing around with an online Calculator for video timings which I saved to a local drive and then hacked a bit to display four decimal points of precision on some key values, and generally spending more time than I intended, I came up with a working ModeLine.
First, let’s look at the original 1920×1080 ModeLine from the above-linked forum post:
ModeLine "1920x1080" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
If you change the pixel clock frequency value in a ModeLine (the 148.50 in the line shown above) you change the refresh rate, and if you change certain other values you change the other timings. I cheated a bit and used Google to search for a working ModeLine that provided 1920×1080 at 59.94 progressive scan, and found one that was very close (59.93, actually) so I tweaked the refresh to give me exactly 59.94. This is the final ModeLine I came up with:
Modeline "1920x1080" 138.5141 1920 1968 2000 2080 1080 1083 1088 1111 +hsync +vsync
Okay, so you may think it ridiculous to specify the pixel clock frequency out to four decimal places, but hey, it works! So, this is what I’m now using for an xorg.conf file (by the way, if any of the ModeLines in this article are truncated on your display, just keep in mind that the last two values in each line are +hsync +vsync — if you copy and paste any of the long ModeLines, hopefully you’ll get the complete line). Bear in mind that I’m using this with an Acer Aspire Revo, so some of these lines are specific to the NVIDIA graphics chipset, but the principle of changing the ModeLine probably should work with this model Sharp TV even if some other graphics chipset is used on the computer:
# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig: version 1.0 (buildmeister@builder75) Tue Dec 8 21:04:28 PST 2009
Section "ServerLayout"
Identifier "Layout0"
Screen 0 "Screen0"
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
EndSection
Section "Files"
EndSection
Section "InputDevice"
# generated from default
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/psaux"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection
Section "InputDevice"
# generated from default
Identifier "Keyboard0"
Driver "kbd"
EndSection
Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName "Unknown"
HorizSync 15.0 - 75.0
VertRefresh 55.0 - 76.0
ModeLine "1920x1080" 138.5141 1920 1968 2000 2080 1080 1083 1088 1111 +hsync +vsync
Option "ExactModeTimingsDVI" "TRUE"
Option "DPMS"
EndSection
Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
Option "ModeValidation" "NoEdidModes"
Option "HWCursor" "false"
Option "DynamicTwinView" "false"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Modes "1920x1080"
Depth 24
EndSubSection
EndSection
Section "Extensions"
Option "Composite" "Disable"
EndSection
This seems to work well on a Acer Aspire Revo running Ubuntu Karmic Koala (EDIT: and I’ve also used it under Maverick Meerkat), though I imagine it would work with other Linux distributions that use an xorg.conf file (including XBMC Live), however as far as I know this trick only works with the Sharp LC-42SB45U TV and no other model. With this xorg.conf I don’t have to tweak the overscan settings in XBMC or Boxee at all. It works for me, but it may or may not work for you. Standard disclaimers apply – I’m not telling you to do this on your setup, and if you break something, you own all the pieces, but from me you’ll get nothing more than perhaps a bit of sympathy. Don’t even think of doing this if you are not willing to assume any and all risks.
EDIT: If you don’t want to go through all the hassle I went through to calculate the correct ModeLine, you can run the cvt program with the -r option from the Linux command prompt, like this:
cvt -r 1920 1080
That’s for a 1920 x 1080 display. On my system this generated the following output:
# 1920x1080 59.93 Hz (CVT 2.07M9-R) hsync: 66.59 kHz; pclk: 138.50 MHz Modeline "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync
You’ll notice this is nearly identical to the ModeLine I generated (the vsync is the opposite, though — don’t know if that would be an issue). What I’ve read is that you paste the generated ModeLine into your xorg.conf file and make sure you also have the line
Option "ExactModeTimingsDVI" "TRUE"
in your xorg.conf (to force it to use your generated ModeLine) and that may be all you need. Certainly simpler than how I did it, but I didn’t know about the cvt program. (End EDIT).
By the way, if you want to hack that Calculator for video timings, just save the HTML page to your local hard drive, open it in a text editor and look for this section (it’s very close to the top):
function TwoDecimal(number) {
number=((Math.round(number*100)/100));
return number;
}
Change that second line to
number=((Math.round(number*10000)/10000));
Then load the page into your favorite browser (with JavaScript enabled). That will display a couple extra decimal points on some of the critical values.
Anyone under the age of 40 may not remember the name, but at one time Crosley was one of the big names in radio receivers and early black-and-white televisions. Even though the original Crosley Corporation no longer exists, the brand name was purchased and is now used by Crosley Radio, a company that makes reproductions of products that are stuck in our collective memories – perhaps from finding them in our grandparents’ attics, or seeing them in old movies and TV shows.
Of course, these are only reproductions, and often not exact reproductions due to advances in technology. Such is the case with their line of telephone reproductions. No matter how much you might desire a perfect reproduction of an older model, the fact is that nowadays it’s not really practical to have a phone without touch tone dialing. But that doesn’t mean you can’t come awfully close.
The phones come in a small choice of colors that varies depending on the model – for example, you might want basic black in a wall or desk phone…
… but, it would hardly make sense to offer a black Princess phone.
I’m sure these reproductions aren’t perfect. For example, a real model 354 wall phone as made by Western Electric (in the USA) or Northern Electric (in Canada) has slots on the sides so that the ringer could be heard a bit more clearly. No slots on the phone in the above photo, but since it probably doesn’t contain a real mechanical ringer anyway, those slots would not serve any purpose and would just catch dust. Also, the phones come with an earpiece volume control, something the originals usually did not have.
Want to buy one? Check out Amazon’s selection of Crosley phones (Amazon affiliate link).
I don’t know how well these actually work as phones (I’ve never actually used one, just happened across their web site), but I’d assume they work as well as other modern phones, and they sure look nice, especially that red 302 desk set reproduction. Crosley Radio (the new company) also makes reproductions of other nostalgic items, such as cathedral style radios and jukeboxes (which play CD’s, not “stacks of wax”), so you may want to download a catalog. So if you are stuck for a Father’s Day gift, and if Dad is into old stuff, set him up with a VoIP service and then plug one of these beauties into it. Of course, you can still find the real thing on fleabay, but unfortunately those old mechanical dials (besides having a tendency to lock up after all these years) won’t work with modern VoIP service.
Speaking of which, I wonder why no one sells a dial conversion separately – something that would replace the mechanical dials in those old Western/Northern Electric 300 series phones, and similar phones that used the same size dial (and there were many such back in the day). If they can do it in these reproduction phones, why can’t you purchase the dials separately and put them in the genuine item? Or would that be something no one (except me) would consider doing to one of those old phones? I somehow doubt that – for a while, people were making table lamps out of old candlestick phones, so I don’t think that replacing the old rotary dial with a touch tone unit would be that big a deal, unless you were looking for a museum piece. But, that’s just me.
Recent Comments