Tuesday, March 29, 2011
Builds still stalled on major sync issue
Sorry to keep everybody waiting. There is indeed a major issue (being investigated now) with sync and/or local database storage that has prevented current builds from being usable. As soon as this is resolved, I expect to resume publishing builds again.
Friday, March 18, 2011
Build your own Cr-48... virtually.
While I pause for technical difficulties and try to diagnose why my Cr-48 builds are having strange sync/settings issues, this is a good time to point out that Hexxeh's Vanilla builds of Chromium OS are a good way to try out beta builds of Chrome OS on hardware other than the Google Cr-48 notebook. The Vanilla builds have hardware support for many netbooks and notebooks from 2009-2010 and newer.
Early this week, he also started releasing virtual machine images generated from the nightly builds. If you have VMware, VirtualBox, or other virtualization software compatible with their disk image formats, you can now download ready-to-run images for a VM.
If you're dying to try out Chrome OS on more hardware, or you weren't one of the lucky few to receive a Cr-48, I highly recommend checking out the work Hexxeh is doing. He deserves a hat tip here, since his work is what inspired me to start hacking on the Cr-48 and producing OS builds for it.
Early this week, he also started releasing virtual machine images generated from the nightly builds. If you have VMware, VirtualBox, or other virtualization software compatible with their disk image formats, you can now download ready-to-run images for a VM.
If you're dying to try out Chrome OS on more hardware, or you weren't one of the lucky few to receive a Cr-48, I highly recommend checking out the work Hexxeh is doing. He deserves a hat tip here, since his work is what inspired me to start hacking on the Cr-48 and producing OS builds for it.
Tuesday, March 8, 2011
New Cr-48 Chromium OS build: 0.11.246.2011_03_08
Today's build (I've stopped direct-linking so that users see the caveats on the downloads front page) is now available from the download page. The changes listed here are relative to the previous build.
Changes specific to my open-source builds:
Changes specific to my open-source builds:
- Nothing new to my mods in this release; a new build was created mainly to address some issues in the browser (the .227 build has some of the same bugs in the recently pulled Development channel official release).
- The issue preventing audio from being muted completely is fixed.
- More work on speech input has been implemented; recorded speech data is now streamed direct to the server rather than waiting until recording finishes, and uploading after the fact.
- URLs starting with file:// should now just show the filename in the title bar.
- Tap-to-click is now disabled by default on new logins/installs.
- The new app icons are now used by default. If you want to see the comparisons side-by side, look at the changelist, and click on the "View" link in the "Side-by-side diffs" column. These are, of course, the Chromium (blue-shade) versions; the Chrome (quad-color) logos are not part of the public source code for trademark reasons.
Notable changes for the rest of the OS from 0.11.227.2011_03_04 to 0.11.246.2011_03_08:
- The start of some automatic disk cleanup work has been added. The current implementation will clear the browser disk cache of all but the currently-logged-in user if the free disk space is less than 500MB.
- Some infrastructure for allowing Stage Video acceleration for Flash has been added. It doesn't do anything yet in my builds (as there's no Pepper-based Flash yet), but this is hopefully a sign of better things to come. The comments also imply some fixes to fullscreen<->non-fullscreen transition issues.
And this is only indirectly related to Chromium OS, but in a recent commit, the Cloud Print Proxy was added to about:flags for Linux (as well as Mac, which was added a little while ago). I haven't seen people talking about this elsewhere, so might as well mention it. This may appear when the official Chrome browser Development channel next updates, but no guarantees. In the meantime, armooo's cloud print proxy Python script still works well for me on Linux.
[Note: I gave this a whirl, and it's overall more stable than the .227 release, but there is an oddity with displaying webapps on the New Tab Page -- they don't show up at all until Apps is closed and expanded again, and the size of the view area is smaller than it should be.]
If you have any issues with this build, please let me know directly, or in the blog comments.
[Note: I gave this a whirl, and it's overall more stable than the .227 release, but there is an oddity with displaying webapps on the New Tab Page -- they don't show up at all until Apps is closed and expanded again, and the size of the view area is smaller than it should be.]
If you have any issues with this build, please let me know directly, or in the blog comments.
Saturday, March 5, 2011
So, Google Voice: SIP is actually coming? (...in some form)
[Update March 8: It seems this service is no longer working, starting yesterday evening. sigh. I was hoping to see the security bugs patched up, not for the service to be pulled down again like it was in early 2009. Please, Google Voice people, throw us a bone here and let us know what's really going on for once!]
[Update 2, March 8: Some folks such as Dan York can still use the SIP-to-GV calling feature as of this writing. I'm jealous. <grin>]
[Update, March 15: Aaaaaaand, we're back. It appears that most, if not all, GV numbers are accepting SIP calls again as noted below.]
[Update, March 16: And it's down again. I think the number of blogs covering this quiet feature of GV, and the quickness with which the up/down reports are coming in, demonstrates that there are a lot of users interested in GV integration with SIP. At this time, I would guess that this inbound calling feature will eventually become official, but the "when" is anyone's guess.]
On the heels of my frustration-induced post from yesterday about Gizmo5's demise (also covered by Engadget), I did some digging this morning and made a few discoveries.
I should have known better than to come to snap judgment. Granted, Google's communication of Gizmo5's shutdown was badly phrased — implying Gmail-only (or Gmail-compatible, i.e., libjingle) access to be the only future path — it seems there is more to come on the SIP interoperability front.
While today's discovery does not indicate official support for any SIP services yet, and doesn't address all of the points in my previous post, it hints at future SIP-compliant support. One front where Google needs serious improvement: communicating useful hints about upcoming, unreleased features to keep the tech-savvy folks interested when an in-use product is being shut down.
Over at Engadget, commenter mscdex reminded me of a hostname I had heard about late last year: sip.voice.google.com. When I first heard about it, I played with it for a while, and like other users (see post by xkashmirix), could not get it to do anything at all. This morning, something different happened. I first considered holding off on posting about this because it contains a bad security hole that was discovered when this functionality was unintentionally exposed in early 2009. But, no one else has mentioned it recently, so it's time to get the hole fixed for good.
Curious to try out sip.voice.google.com again, this morning I fired up Linphone. I tried registering with sip.voice.google.com using a couple dozen different forms of SIP address and my password (as well as an application-specific password with another Google Voice account secured by 2-step auth); none succeeded. I let that go for now, and thought that perhaps it would be possible to call into my Google Voice account via SIP. So, I switched Linphone to my Gizmo5 account, and assuming that "NPA" is my area code and "NXXXXXX" my 7-digit number, I tried combinations that I had attempted back in December without success:
sip:NPANXXXXXX@sip.voice.google.com ... error.
sip:1NPANXXXXXX@sip.voice.google.com ... error.
sip:+1NPANXXXXXX@sip.voice.google.com ... and my cell phone rang.
I was excited and answered the phone. Audio went through in both directions. It worked! So, I thought, I called from a Gizmo5 account linked to my Google Voice account; maybe that's why it worked. I tried calling my partner's Google Voice number, and... his cell phone rang.
Sure that this was because I was calling from Gizmo5, and not because this was generally available to the public, I set up a forwarding account with a free PSTN-to-VoIP gateway service very familiar to technical VoIP users. I called it from my cell phone. My Google Voice voicemail answered with the custom greeting I created for calls from my cell phone.
Not only did the call go through, but it also correctly passed Caller ID. Hm, maybe this is intended to be a publicly available service soon? I pressed star (*) during the voicemail greeting, and my heart sank. I was asked for my (4-digit) PIN.
The problem here is obvious to anyone knowledgeable about VoIP: a four-digit PIN does not take long to hack by machine, since redialing can be a very fast operation. It could be that some safeguards are in place that prevent machine hacks of the PIN (I'd have to try the hack to know for sure), but I've always felt a bit uneasy about only 4 digits guarding my voicemail and dial-out credit. Hope as I might, Google Voice has yet to release the ability to use more digits for a PIN, or even a setting to disallow telephone-based access to at least dial-out.
This also indicates that the previous issue noted at Voxzilla remains, meaning that all Google Voice users should immediately set all their forwarding phones' "Direct access to voicemail" option to NO (you know, for those of you who haven't already, after hearing about similar voicemail hacks used against, or even by celebrities). Doubly unfortunately, this setting is hidden by "Show advanced settings" in the forwarding phone setup, and last I checked, it still defaults to "Yes" for newly added mobile phones.
To sum it up: The good news is, you can now call Google Voice numbers directly from SIP using the pattern +1NPANXXXXXX@sip.voice.google.com. This is a major step forward. The bad news is, it makes known security hacks easier.
The three questions I raised in my previous post are still up in the air. While my specific desire (a SIP account as a forwarding phone) is known not to be working, it's possible that a standard SIP client could connect to sip.voice.google.com — if someone happens to figure out how to login to that [cough]ed thing.
Happy calling!
[Update 2, March 8: Some folks such as Dan York can still use the SIP-to-GV calling feature as of this writing. I'm jealous. <grin>]
[Update, March 15: Aaaaaaand, we're back. It appears that most, if not all, GV numbers are accepting SIP calls again as noted below.]
[Update, March 16: And it's down again. I think the number of blogs covering this quiet feature of GV, and the quickness with which the up/down reports are coming in, demonstrates that there are a lot of users interested in GV integration with SIP. At this time, I would guess that this inbound calling feature will eventually become official, but the "when" is anyone's guess.]
On the heels of my frustration-induced post from yesterday about Gizmo5's demise (also covered by Engadget), I did some digging this morning and made a few discoveries.
I should have known better than to come to snap judgment. Granted, Google's communication of Gizmo5's shutdown was badly phrased — implying Gmail-only (or Gmail-compatible, i.e., libjingle) access to be the only future path — it seems there is more to come on the SIP interoperability front.
While today's discovery does not indicate official support for any SIP services yet, and doesn't address all of the points in my previous post, it hints at future SIP-compliant support. One front where Google needs serious improvement: communicating useful hints about upcoming, unreleased features to keep the tech-savvy folks interested when an in-use product is being shut down.
Over at Engadget, commenter mscdex reminded me of a hostname I had heard about late last year: sip.voice.google.com. When I first heard about it, I played with it for a while, and like other users (see post by xkashmirix), could not get it to do anything at all. This morning, something different happened. I first considered holding off on posting about this because it contains a bad security hole that was discovered when this functionality was unintentionally exposed in early 2009. But, no one else has mentioned it recently, so it's time to get the hole fixed for good.
Curious to try out sip.voice.google.com again, this morning I fired up Linphone. I tried registering with sip.voice.google.com using a couple dozen different forms of SIP address and my password (as well as an application-specific password with another Google Voice account secured by 2-step auth); none succeeded. I let that go for now, and thought that perhaps it would be possible to call into my Google Voice account via SIP. So, I switched Linphone to my Gizmo5 account, and assuming that "NPA" is my area code and "NXXXXXX" my 7-digit number, I tried combinations that I had attempted back in December without success:
sip:NPANXXXXXX@sip.voice.google.com ... error.
sip:1NPANXXXXXX@sip.voice.google.com ... error.
sip:+1NPANXXXXXX@sip.voice.google.com ... and my cell phone rang.
I was excited and answered the phone. Audio went through in both directions. It worked! So, I thought, I called from a Gizmo5 account linked to my Google Voice account; maybe that's why it worked. I tried calling my partner's Google Voice number, and... his cell phone rang.
Sure that this was because I was calling from Gizmo5, and not because this was generally available to the public, I set up a forwarding account with a free PSTN-to-VoIP gateway service very familiar to technical VoIP users. I called it from my cell phone. My Google Voice voicemail answered with the custom greeting I created for calls from my cell phone.
Not only did the call go through, but it also correctly passed Caller ID. Hm, maybe this is intended to be a publicly available service soon? I pressed star (*) during the voicemail greeting, and my heart sank. I was asked for my (4-digit) PIN.
The problem here is obvious to anyone knowledgeable about VoIP: a four-digit PIN does not take long to hack by machine, since redialing can be a very fast operation. It could be that some safeguards are in place that prevent machine hacks of the PIN (I'd have to try the hack to know for sure), but I've always felt a bit uneasy about only 4 digits guarding my voicemail and dial-out credit. Hope as I might, Google Voice has yet to release the ability to use more digits for a PIN, or even a setting to disallow telephone-based access to at least dial-out.
This also indicates that the previous issue noted at Voxzilla remains, meaning that all Google Voice users should immediately set all their forwarding phones' "Direct access to voicemail" option to NO (you know, for those of you who haven't already, after hearing about similar voicemail hacks used against, or even by celebrities). Doubly unfortunately, this setting is hidden by "Show advanced settings" in the forwarding phone setup, and last I checked, it still defaults to "Yes" for newly added mobile phones.
To sum it up: The good news is, you can now call Google Voice numbers directly from SIP using the pattern +1NPANXXXXXX@sip.voice.google.com. This is a major step forward. The bad news is, it makes known security hacks easier.
The three questions I raised in my previous post are still up in the air. While my specific desire (a SIP account as a forwarding phone) is known not to be working, it's possible that a standard SIP client could connect to sip.voice.google.com — if someone happens to figure out how to login to that [cough]ed thing.
Happy calling!
Friday, March 4, 2011
Google to kill Gizmo5 on April 3, slamming the door on SIP interoperability?
[UPDATE: This adventure isn't over yet. It seems that a subset of SIP functionality is working right now.]
Yes, there are times when Google irritates me, too. I can hardly be considered a "fanboy". Today, they have done it again. I received an e-mail stating:
I have had a Gizmo5 account for a while, and it has been useful to integrate with Google Voice because it provided three things Google Voice did not, and still does not as of today:
Yes, there are times when Google irritates me, too. I can hardly be considered a "fanboy". Today, they have done it again. I received an e-mail stating:
Gizmo5 is writing to let you know that we will no longer be providing service starting on April 3, 2011. A week from today, March 11, 2011, you will no longer be able to add credit to your account.
Although the standalone Gizmo5 client will no longer be available, we have since launched the ability to call phones from within Gmail at even more affordable rates.
If you purchased calling credit and have a balance remaining in your account, you can request a refund by logging in to http://my.gizmo5.com. If you are in the United States, you can instead choose to transfer your credit to a Google Voice account, so it can be used for calling from Google Voice or Gmail. If you don’t have a Google Voice account, please create one so that we can transfer your credit.
Please request a call credit transfer or refund by April 3, 2011. If you don't request a call credit transfer or refund by this date, we will automatically refund your remaining call credit via the payment method you originally used to purchase the credit. Note that if you paid via Moneybookers or if the credit card on file has expired, we will not be able to automatically refund your unused credit, so please log in to initiate the refund process.
I have had a Gizmo5 account for a while, and it has been useful to integrate with Google Voice because it provided three things Google Voice did not, and still does not as of today:
- Use of an industry-standard SIP protocol client (phone or softphone).
- Calling to SIP destinations.
- Forwarding of calls to SIP destinations, such as a soft-PBX or a VoIP phone service (without using up PSTN minutes at the VoIP provider).
I didn't list the bass-ackwards Skype forwarding "feature" as it's always been rather broken, but it's interesting to note that Google is becoming more like Skype by moving to a semi-proprietary protocol (libjingle) as the only way to use standalone clients (1).
Calling to SIP destinations (2) is most useful when making international calls, but not a big loss by killing Gizmo5; there are other SIP-only services available.
The big loss is the removal of forwarding to SIP destinations (3). Google Voice has yet to introduce a SIP calling scheme, so we've been forced to route calls GVoice -> Gizmo5 -> SIP for a while. Not a big deal once it's set up, but losing this functionality essentially slams the door on standard SIP-based VoIP interoperability with Google Voice. This is very disappointing.
For more than two years, many Google Voice users have been waiting for SIP interoperability (and that's just the threads in the first few pages of searching the Google Voice help forum for "SIP"), but no news has been forthcoming. For a little while, interoperability with receiving calls from SIP phones existed, but that was quickly shut down, ostensibly because the 4-digit voicemail PIN would be easy to machine-hack. And now, it will no longer be possible to send calls to SIP phones without routing the call through the PSTN (the key enabling feature of Gizmo5 routing).
Google Voice folks, you're dropping the ball by killing Gizmo5 without replacing its functionality. I hope I'll be seeing an announcement about using SIP at least for forwarding phones in the future...?
New #winning Cr-48 Chromium OS build: 0.11.227.2011_03_04
Today's build is now available from the download page. The changes listed here are relative to the previous build. This winning release from duh.org comes to you with an extra dose of tiger blood!
I wasn't planning on doing a build for a while, but apparently I should know better than to walk away for too long. The addition of ad-hoc Wi-Fi support, making it possible to "tether" with older Android and other mobile devices without virtual access point ability, seemed important enough to trigger a new build. (And there's a couple other interesting commits to note in the list below.)
As of today, I have cleaned out the old 0.10.x numbered builds.
Changes specific to my open-source builds:
I wasn't planning on doing a build for a while, but apparently I should know better than to walk away for too long. The addition of ad-hoc Wi-Fi support, making it possible to "tether" with older Android and other mobile devices without virtual access point ability, seemed important enough to trigger a new build. (And there's a couple other interesting commits to note in the list below.)
As of today, I have cleaned out the old 0.10.x numbered builds.
Changes specific to my open-source builds:
- Added the Python "gdata" (Google data bindings) API by request.
- A bug in HTTP authentication is fixed.
- When removing a user from the device, the encrypted home directory is now fully removed.
- P2P Sockets API has been added.
- The Clear Browsing Data key shortcut has been changed to Ctrl-Shift-Backspace (was Ctrl-Shift-Delete, which on the Cr-48 is Ctrl-Shift-Alt-Backspace).
- Hints at future hardware-key authentication support showed up.
- A UI for EAP authentication has been added, but is not (from my testing with known-802.1x networks) available yet. Expect it to be enabled in a near-term future build.
- Speech input is enabled by default again.
- The "CrOS will never be on tablets" quasi-debate is over; a touchscreen UI for Chrome OS is in the process of being implemented right now (this part is for the on-screen touch keyboard).
- CSS styles in the Chrome settings pages were cleaned up a bit.
Notable changes for the rest of the OS from 0.11.218.2011_03_02 to 0.11.227.2011_03_04:
- Support for ad-hoc (IBSS) Wi-Fi networks has been added.
If you have any issues with this build, please let me know directly, or in the blog comments.
After additional testing of the previous build, and one from yesterday that was not published, this build has been blessed as "most stable" on the download page. Winning!
After additional testing of the previous build, and one from yesterday that was not published, this build has been blessed as "most stable" on the download page. Winning!
Wednesday, March 2, 2011
New Cr-48 Chromium OS build: 0.11.218.2011_03_02
Today's build is now available from the download page. The changes listed here are relative to the previous build.
Changes specific to my open-source builds:
Changes specific to my open-source builds:
- The Google Native Client ("NaCl") plugin is installed. However, due to part of an open issue, it's not yet functional just by flipping the relevant about:flags bit. See note at bottom of this post for how to try it out.
- From testing, the included VLC works... sort of. The good news is that it will play most files I've thrown at it so far (with the exception of AVIs with esoteric Windows-only codecs, of course). But given that it has no GUI, there are no key shortcuts to navigate within a clip, and volume level won't change unless a browser window is showing. There is a clunky CLI interface for VLC in the terminal from where it's run, but I plan to get one of its real GUIs (hopefully xosd) running in a future build.
- A hack added to work around an old WebKit bug has been removed, now that the issue was fixed in WebKit itself. This removes many spurious mouse move events that were slowing down pointer response time.
- Some cases where tabs were repainted, while still being started up, have been fixed. The commit notes suggest 10-20% reduction in tab repainting on new tabs, which should result in noticeable visual improvement.
- A bug preventing dragging to the bookmark bar is now fixed.
- Some bugs relating to crashes in the Guest login are fixed.
Notable changes for the rest of the OS from 0.11.215.2011_03_01 to 0.11.218.2011_03_02:
- No major changes of note.
If you have any issues with this build, please let me know directly, or in the comments!
This build is a candidate for being blessed as "most stable" on the download page. If it proves reasonably stable, there may not be another build for about a week while I deal with tedious personal tasks.
Using Native Client in this build
Currently, NaCl on Linux requires the --no-sandbox command line switch, in addition to enabling Native Client on the about:flags page. Even though the Native Client example gallery might indicate that NaCl is enabled, programs won't actually work right now without that extra switch.
In order to do this, you will need to edit a startup script to add the appropriate switch. First, (temporarily) remount the root partition read/write:
Now use your editor of choice (under sudo) to edit the file /sbin/session_manager_setup.sh. At the bottom of the file, there are many --switch lines; add one anywhere in the middle of them that reads:
Make sure the backslash is the very last character on the end of the line. Save the file, reboot, and you will see a warning about using the flag --no-sandbox (as it does disable security features). However, the Native Client examples should now run.
To revert the changes, run the mount command again, remove the --no-sandbox line from /sbin/session_manager_setup.sh, and reboot.
This build is a candidate for being blessed as "most stable" on the download page. If it proves reasonably stable, there may not be another build for about a week while I deal with tedious personal tasks.
Using Native Client in this build
Currently, NaCl on Linux requires the --no-sandbox command line switch, in addition to enabling Native Client on the about:flags page. Even though the Native Client example gallery might indicate that NaCl is enabled, programs won't actually work right now without that extra switch.
In order to do this, you will need to edit a startup script to add the appropriate switch. First, (temporarily) remount the root partition read/write:
sudo mount -o rw,remount /
Now use your editor of choice (under sudo) to edit the file /sbin/session_manager_setup.sh. At the bottom of the file, there are many --switch lines; add one anywhere in the middle of them that reads:
--no-sandbox \
Make sure the backslash is the very last character on the end of the line. Save the file, reboot, and you will see a warning about using the flag --no-sandbox (as it does disable security features). However, the Native Client examples should now run.
To revert the changes, run the mount command again, remove the --no-sandbox line from /sbin/session_manager_setup.sh, and reboot.
Tuesday, March 1, 2011
New Cr-48 Chromium OS build: 0.11.215.2011_03_01
Today's build is now available from the download page. There still seems to be an oddity with the login screen (on some boots, the login just hangs, requiring a shutdown and restart, where login then works).
Changes specific to my open-source builds:
Changes specific to my open-source builds:
- The ambient light sensor has been disabled completely (and correctly this time). Until a workaround is devised for the open light sensor issue, I'm forcing its sensitivity to zero to prevent unexpected major changes in backlight level.
- The Ctrl-Alt-T terminal (cros-term) font size has been changed from 12 to 14, to improve readability for many users. The screen is still 141x46 characters in size, plenty large for most users.
- The re-tuned trackpad config now provides a wider range of movement speeds at the highest two settings. (Previously the maximum speed was capped to the same value for all of the top three settings.)
- Surprise! The long-requested VLC is included... but don't get too excited yet. It's not building the browser plugin, so it's only command-line based. There's no GUI yet... at all (I think). And, I haven't even had a chance to kick the tires on it yet, so it could just as well blow up completely upon startup. The hope is to make it capable of playing less open/common formats, and make it available as a browser plugin in the future; but for now, it's as rough as things can get. (For those lusting to get it extricated into an add-on for official builds, sorry, there's just way too many library dependencies involved to make that feasible.)
- The change in the previous build to enforce same-origin policy on HTML5 media has been reverted as it broke Vimeo playback, among others.
Notable changes for the rest of the OS from 0.11.201.2011_02_26 to 0.11.215.2011_03_01:
- Flash has been updated officially to 10.2, obsoleting my previous hack.
If you have any issues with this build, please let me know directly, or in the comments!
(If you're not aching for these changes now, or don't feel like reflashing yet, just wait one more build... there's some more noticeable UI speed and trackpad improvements coming very soon, possibly tomorrow.)
(If you're not aching for these changes now, or don't feel like reflashing yet, just wait one more build... there's some more noticeable UI speed and trackpad improvements coming very soon, possibly tomorrow.)
Subscribe to:
Posts (Atom)