I recently got my hands on a nice Fortinet router that fell off the back of a truck. Getting access to it was way harder than it should have been. Here’s how you do it.
1) Install FortiExplorer. Connect the usb cable to the router and go to the web view. First just try ‘admin’ and no password. If that fails, you’ve gotta reset it.
3) Download a firmware from the Fortinet ftp server: ftp://pftpintl:F0rt1intl@support.fortinet.com
4) Upload the firmware to the router.
5) Unplug the power. Plug it back in and wait for the router to boot up.
6) Use a pen to hold the reset button for about 5 seconds within 30 seconds of the router booting up.
7) At this point I was unable to access the web view. Maybe try rebooting again and see if it works. If it does, you’re done.
8) Install the new firmware that you uploaded in step 4. Reboot and login with ‘admin’ and no password.
I posted my troubles on the network engineering stack exchange site and got a helpful yet dickish reply.
Through a little trial and error I’ve made it work. This probably isn’t the only way, but it worked for me.
1) Install Windows on the beginning of the disk.
2) Install Ubuntu in a subsequent partition. Resize Windows with gparted if you need to.
3) At this point, only Ubuntu will be in the grub menu. Boot the Ubuntu install cd/usb again and install Boot-Repair. See the instructions under “2nd option”: https://help.ubuntu.com/community/Boot-Repair
4) Run boot repair with the default settings. Pray to something holy. Reboot.
And finally, go into the Ubuntu update settings and check only the box for security releases. Updating everything is a recipe for disaster. If your system works, don’t mess with it unless you want to spend a Saturday during ACL troubleshooting nvidia drivers and an xorg.conf.
Over the weekend I got impatient waiting for my Chromecast to arrive so I built netbook-web-streamer. It’s a node.js app that loads URLs in an iframe on a remote PC that’s plugged into your large speakers. I use it to listen to playlists on songza and individual songs from youtube.
To play a song, enter it in the form on the homepage, or click the bookmarklet when you’re on a page you want the remote PC to load.
How this works
There are 3 routes `’/’`, `’/loadUrl’`, and `’/audio’`.
`/` is the homepage. From there you can send xhr GET requests to `/loadUrl` with a `&url` param. The node.js view then broadcasts a socket.io event to a client that has loaded `/audio`. The event handler on the client takes the url value from the message and loads it in an iframe.
The only complication is that youtube forbids running videos on the main site in an iframe by sending an x-frame-options header. The workaround is to extract the video id from the url and turn it into an embed url.
I built an animated gif photobooth for the Indeed July 2013 hackathon.
We got some good shots.
If you just want to run the app, the source is on GitHub: https://github.com/NickCarneiro/gifbooth. There’s no public demo because the code isn’t terribly secure and the images it produces are about 3mb each. But don’t let that stop you from playing with it.
If you want to implement something like this on your own, avoid Flash-based libraries like “jquery-webcam-plugin” or “scriptcam”. They’re a waste of time. New versions of Chrome let you do everything you want through Canvas and WebRTC’s Stream API.
I put some jQuery on top of their code to capture a bunch of frames in quick succession and POST the base-64 encoded data urls to a Flask backend. The Flask view waits until it receives every frame in the set and stitches them together with ImageMagick.
The ImageMagick part is key. PIL and Pillow are huge timesucks for something this simple. ffmpeg is a nightmare. I dare you to look at its man page. If you ever want to create gifs, just use ImageMagick. It’s by far the easiest option.
Anyway, there are a few big issues with this project that are symptomatic of a hackathon. First, it takes a few CPU-intensive milliseconds in between image captures to load the canvas into a data url. This holds up the one and only thread, temporarily locking up the UI and preventing you from having a buttery smooth framerate. You could probably fix this with Web Workers. The other problem is that uploading 15 base64 strings containing medium-sized images takes longer than sending binary data like you would for a `multipart/form-data` file upload. You could get around this by writing the images to files with the File API and then uploading them from disk. And finally, the batches of images are grouped only by millisecond timestamp, so a unique identifier should be added if you want to get this ready for prime time.
By default, git diff only spits out three lines of context above and below your changes. However, it’s possible to include the entire file. Generate a patch of some changes with full context:
git diff --no-prefix -U1000 > /tmp/mydiff.patch
If you’ve already committed your changes, you can use git show with the same syntax:
git show --no-prefix -U1000 > /tmp/mydiff.patch
These are useful for pre-commit code reviews in Crucible. You can just upload the resulting patch file.
The –no-prefix option gets rid of the “/a/” and “/b/” destination prefixes that show up by default.
The -U flag specifies lines of context. You might need to increase this if there are more than 1000 lines between your changes.
If you don’t want to type all that out, add an alias in your ~/.gitconfig file.
code-review = diff -p --no-prefix -U1000
Then you can just do:
git code-review > /tmp/mydiff.patch