I’ve just recently installed Virtualbox on my Ubuntu machine and decided to set up a Windows 7 VM. Once everything was complete it was time to enable shared folders so I could transfer some files to and from the VM. Only 1 problem… I can’t find them?!
After a bit of looking around on the web I finally found a random user comment on a random blog that hinted at where they “might” be so I decided to put this article up for any future VB + Win7 users that are just as confused as I was. Some people were suggesting installing FTP servers to the Windows install and even using Web services like Dropbox to move the files from the host machine to the VM. :/
First things first… create your folder on your system.
mkdir ~/VMShare
Add said folder to your VB shared folders list.
Once that is done you’ll open up your Win7 Network view.
Start > Computer > Network (in the left window pane)
And clicking on VBOXSVR will list your shared folders.
Now you’re sharing files easily.
Note: You’ll need to have the Virtualbox Guest Additions package installed in the VM for this to work properly.
I installed UNR in version 9.10 and immediately disabled the netbook launcher for the classic desktop. This was easy in 9.10 thanks to a setting in the system preferences called “Desktop Mode Switcher”. It was great, it was easy… and now it’s gone.
For whatever reason in 10.04 they decided to get rid of this handy little tool. I had to purge some nautilus config files and all of a sudden, I was back to UNR launcher. I couldn’t find my trusty switcher so I started looking around the web… people are going through 5-12 steps to get around this thing, many without full success. I’m writing this in the hopes that _YOU_ the person reading this finds it before you go through 12 steps of tweaking config files.
Step 1: Remove the netbook-launcher
sudo aptitude remove netbook-launcher
Step 2: Install regular ubuntu-desktop
sudo aptitude install ubuntu-desktop
Step 3: Restart Gnome
sudo service gdm restart
Step 4: Login using Gnome as your session
Done and done… hope this saves someone from a headache.
Add these lines to your /etc/inputrc to enable the functionality.
"\e[A": history-search-backward
"\e[B": history-search-forward
Thanks Reddit and Archwiki!
(http://wiki.archlinux.org/index.php/Bash)
p.s. this functionality is included in your inputrc file by default on Ubuntu 10.4 and can be used by uncommenting the lines (41 & 42), but rather than arrows it uses Page Up and Page Down.
If you haven’t tried Google Chrome on *nix yet I highly recommend it.
If you’re using a simple str_replace() call in PHP and getting a strange Fatal error that doesn’t make a whole lot of sense to you I have a hunch as to why.
Fatal example:
$file_name = str_replace('findit', 'replaceit', $haystack, 1);
In PHP 5.0.5 some changes were made to how PHP handles variables, functions, and references. This broke a lot of older code but also introduced some vague and questionable fatal errors. They meant well by doing this by essentially requiring parameters be passed via reference. I’m assuming this was to prevent PHP from copying large pieces of data to work on them and thus helping memory performance overall. Luckily there is a simple fix, just declare your variable to be passed inline.
Working example:
$file_name = str_replace('findit', 'replaceit', $haystack, $count = 1);
Note: if you’re working with a large data set in a loop I would highly recommend setting the reference outside of the loop and avoid this inline method.
Client side cache is both a friend and an enemy. As many web designers and developers have learned in the past what it saves you in bandwidth is worth more than it’s share of headaches. With that said one of it’s major headaches is old files on end users computers being used and breaking functionality. This can be felt in layout as well as code (e.g. undefined function ‘do_important_stuff()’) if you’re newly modified files never make it to your end users.
There is an old trick that’s been around for a good while and helped this a bit, an old annoying and version tracking pain in the ass trick. You would change your file names with each major revision (core.v1.js or member.v1.css) which would cause browsers on the client side to request and store the file thinking it was new. From a design aspect it wasn’t to bad, from the version control aspect it wasn’t to bad, and from the implementation aspect it wasn’t to bad… but it was annoying.
Trying to move away from this you’d more than likely discover the GET variable hack. Basically appending useless garble to the end of your file name (file.css?garble=1351341) would ensure your end users browser fetch the file from your server. This was usually done with a variable in your source or more often than not a Unix time stamp. A concern with this method arose in your bandwidth bill if you did it wrong. Most people would just append the time stamp, and since it changes everyone second every single page load would cause yet another extra and pointless call to the server for the same old unmodified file. As if that wasn’t already fugly and possibly expensive (depending on your traffic) it didn’t work in some versions of IE.
During a discussion on better ways to handle JavaScript cache busting with our head software engineer I came up with a fairly simple idea that I hadn’t thought of before… let the file bust it’s own damn cache! Basically using PHP and file system mtimes we should be able to not only make this problem null and void but we can fix it once and never look back.
Using a couple quick functions in PHP and a simple rewrite rule placed on the server we were up and running in no time. Some code snippets and explanations will follow.
PHP include function:
function javascript_include($file_name = null){
if (empty($file_name)){
return false;
}
$file = WWW_WEB_DIR.'/js/'.$file_name;
$timestamp = 0;
if ($file_exists($file)) {
$timestamp = filemtime($file);
} else {
return false;
}
$script_url = "/js/$timestamp/$file_name";
return "<script type=\"text/javascript\" src=\"$script_url\"></script>\n”;
}
Using PHP function:
<?=javascript_include('site_core.js')?>
Resulting output:
<script type="text/javascript" src="/js/135134134/site_core.js"></script>
Rewrite rule:
RewriteRule (.*)/[0-9]+/(.*\.js)$ $1/$2 [PT]
Summary:
So there you have it, completely automated and effective cache busting. This works because browsers universally see the change in the directory structure and automatically assume it’s a new file causing an initial fetch of the file and caching it. If you publish changes to that file the mtime on the file system of the server will be updated, therefore the next request to include said file will have a different directory structure.
Hope this helps others dealing with caching headaches.
Working in Flex and/or Flash you often run into the same problem many times and forget the easy and common sense answer. Security sandbox violations for me is one of those cases.
Googling for answers is usually fruitless and starts talking about server side crossdomain.xml policy files and meta data. These are important in the long run but what about when they’re in place and you’re just testing new client side code. Well I’ve done this a few times now and EVERY time I do it I completely forget the quick and easy work around. So if you’ve looked into the crossdomain.xml tutorials and everything is ship shape but you still can’t test from your local machine I suggest doing the following.
1. right click on any .swf file
2. choose “Settings…”
3. Privacy Tab
4. “Advanced…” button
this will load up an Adobe page that allows you to change and tweak global settings in Flash player that can only be done so there. It’s pretty clutch.
5. click “Global Security Settings Panel” on the left side menu
6. click “Edit Locations…”
7. click “Add Locations…”
8. in the prompt window that comes up put /
9. click confirm
10. change radio button to “Always allow”
Wahlah… your local .swf files are now null and void as far as cross domain sandbox rules are concerned in the world of Flash player.
What you’ve essentially done here is tell Flash Player to ignore security rules for any files in your root files system. If you’re security minded and run a lot of .swf files that you don’t trust locally I wouldn’t recommend this setting as it completely overrides security measures put in place to protect you. You can also use the “browse” functionality to pick specific files which realistically is much safer from a security stand point. I myself don’t worry about it because I don’t store any .swf files locally when it boils down to it.
