madcow

There seems to be decent list of emulators you can choose from for Linux: * games-emulation/advancemame Available versions: ~0.106.1 ~1.2 {alsa fbcon oss sdl static svga truetype} Homepage: http://advancemame.sourceforge.net/ Description: GNU/Linux port of the MAME emulator with GUI menu* games-emulation/advancemenu Available versions: 2.5.0 ~2.6 {alsa debug fbcon ncurses oss sdl slang static svga truetype} Homepage: http://advancemame.sourceforge.net/menu-readme.html Description: Frontend for AdvanceMAME, MAME, MESS, RAINE and any other emulator* games-emulation/advancescan Available versions: ~1.14 1.16 Homepage: http://advancemame.sourceforge.net/scan-readme.html Description: A command line rom manager for MAME, MESS, AdvanceMAME, AdvanceMESS and Raine* games-emulation/atari800 Available versions: 2.2.1 {opengl readline sdl} Homepage: http://atari800.sourceforge.net/ Description: Atari 800 emulator* games-emulation/boycott-advance-sdl Available versions: *0.2.8^s Homepage: http://sdlemu.ngemu.com/basdl.php Description: A Gameboy Advance (GBA) emulator for Linux* games-emulation/caps Available versions: 20071115^s {doc} Homepage: http://www.softpres.org/ Description: Support library that allows third party applications access and use C.A.P.S. images* games-emulation/daphne Available versions: ~1.0 Homepage: http://www.daphne-emu.com/ Description: Laserdisc Arcade Game Emulator* games-emulation/dboxfe Available versions: ~0.1.3 Homepage: http://developer.berlios.de/projects/dboxfe/ Description: Creates and manages configuration files for DOSBox* games-emulation/desmume Available versions: ~0.9.8 ~0.9.9 Homepage: http://desmume.org/ Description: Nintendo DS emulator* games-emulation/dgen-sdl Available versions: 1.30 ~1.31 ~1.32 {joystick opengl} Homepage: http://dgen.sourceforge.net/ Description: A Linux/SDL-Port of the famous DGen MegaDrive/Genesis-Emulator* games-emulation/dolphin Available versions: ~3.5^m ~4.0 **9999 {alsa ao bluetooth doc ffmpeg +lzo openal opengl openmp portaudio pulseaudio} Homepage: https://www.dolphin-emu.org/ Description: Gamecube and Wii game emulator* games-emulation/dosbox Available versions: 0.74 **9999 {alsa debug hardened opengl} Homepage: http://dosbox.sourceforge.net/ Description: DOS emulator* games-emulation/emutos Available versions: 0.8.5 ~0.8.7 Homepage: http://emutos.sourceforge.net Description: a single-user single-tasking operating system for 32 bit Atari computer emulators* games-emulation/fakenes Available versions: ~0.5.8-r1 0.5.8-r2 {openal opengl zlib} Homepage: http://fakenes.sourceforge.net/ Description: portable, Open Source NES emulator which is written mostly in C* games-emulation/fbzx Available versions: 2.10.0 Homepage: http://www.rastersoft.com/fbzx.html Description: A Sinclair Spectrum emulator, designed to work at full screen using the FrameBuffer* games-emulation/fceux Available versions: 2.1.5 {+lua +opengl} Homepage: http://fceux.com/'>http://fceux.com/ Description: A portable Famicom/NES emulator, an evolution of the original FCE Ultra* games-emulation/gambatte Available versions: ~0.5.0_p20130601 ~0.5.0_p20131102 {qt4 +sdl} Homepage: http://sourceforge.net/projects/gambatte Description: An accuracy-focused Gameboy / Gameboy Color emulator* games-emulation/gcube Available versions: ~0.4-r1 Homepage: http://gcube.exemu.net/ Description: Gamecube emulator* games-emulation/generator Available versions: 0.35_p3 {+sdlaudio svga} Homepage: http://www.ghostwhitecrab.com/generator/ Description: Sega Genesis / Mega Drive emulator* games-emulation/gens Available versions: *2.15.5 Homepage: http://sourceforge.net/projects/gens/ Description: A Sega Genesis/CD/32X emulator* games-emulation/gfceux Available versions: 2.1.1 2.1.1-r1 {PYTHON_TARGETS="python2_6 python2_7"} Homepage: http://fceux.com Description: A graphical frontend for the FCEUX emulator* games-emulation/gngb Available versions: *20060309 {opengl} Homepage: http://m.peponas.free.fr/gngb/ Description: Gameboy / Gameboy Color emulator* games-emulation/gngeo Available versions: ~0.7 Homepage: http://m.peponas.free.fr/gngeo/ Description: A NeoGeo emulator* games-emulation/gnomeboyadvance Available versions: *0.1 Homepage: http://developer.berlios.de/projects/gnomeboyadvance/ Description: A GNOME Python frontend to VisualBoyAdvance* games-emulation/gnuboy Available versions: 1.0.3 {X fbcon sdl svga} Homepage: http://code.google.com/p/gnuboy/ Description: Gameboy emulator with multiple renderers* games-emulation/gxmame Available versions: 0.35_beta2 {joystick nls} Homepage: http://gxmame.sourceforge.net/ Description: frontend for XMame using the GTK library* games-emulation/handy Available versions: *0.82^s Homepage: http://sdlemu.ngemu.com/handysdl.php Description: A Atari Lynx emulator for Linux* games-emulation/hatari Available versions: 1.5.0 1.6.1 ~1.6.1-r1 1.6.2 {PYTHON_SINGLE_TARGET="python2_6 python2_7" PYTHON_TARGETS="python2_6 python2_7"} Homepage: http://hatari.berlios.de/ Description: Atari ST emulator* games-emulation/higan Available versions: 092 {+alsa ao openal opengl oss profile_accuracy +profile_balanced profile_performance pulseaudio qt4 +sdl xv} Homepage: http://byuu.org/higan/ https://code.google.com/p/higan/ Description: A Nintendo multi-system emulator formerly known as bsnes* games-emulation/hugo Available versions: *2.12 Homepage: http://www.zeograd.com/ Description: PC-Engine (Turbografx16) emulator for linux* games-emulation/kigb Available versions: *2.02^s Homepage: http://kigb.emuunlim.com Description: A Gameboy (GB, SGB, GBA) Emulator for Linux* games-emulation/lxdream Available versions: ~0.9.1-r2 {debug lirc profile pulseaudio sdl} Homepage: http://www.lxdream.org/ Description: An emulator for the Sega Dreamcast system* games-emulation/m64py Available versions: [M]~0.1.6 [M]~0.1.8 {PYTHON_TARGETS="python2_7"} Homepage: http://m64py.sourceforge.net/ Description: A frontend for Mupen64Plus* games-emulation/mamory Available versions: ~0.2.25 Homepage: http://mamory.sourceforge.net/ Description: ROM management tools and library* games-emulation/mastergear-bin Available versions: *2.0^s Homepage: http://fms.komkon.org/MG/ Description: SEGA Master System / Game Gear emulator* games-emulation/mednafen Available versions: 0.9.28 ~0.9.32 {alsa altivec cjk debugger jack nls} Homepage: http://mednafen.sourceforge.net/ Description: An advanced NES, GB/GBC/GBA, TurboGrafx 16/CD, NGPC and Lynx emulator* games-emulation/mekanix Available versions: *070^s Homepage: http://www.smspower.org/meka/ Description: SG-1000, SC-3000, SF-7000, SSC, SMS, GG, COLECO, and OMV emulator* games-emulation/mupen64plus Available versions: 1.5-r1 1.5-r2 [M]~2.0 {+audio-sdl +gtk +input-sdl libsamplerate lirc qt4 +rsp-hle sse +ui-console +ui-m64py +video-glide64mk2 +video-rice} Homepage: http://code.google.com/p/mupen64plus/ Description: A fork of Mupen64 Nintendo 64 emulator, meta-package* games-emulation/mupen64plus-audio-sdl Available versions: [M]~2.0 {libsamplerate oss speex} Homepage: http://code.google.com/p/mupen64plus/ Description: A fork of Mupen64 Nintendo 64 emulator, SDL audio plugin* games-emulation/mupen64plus-core Available versions: [M]~2.0(0/2) {lirc new-dynarec +osd sse} Homepage: http://code.google.com/p/mupen64plus/ Description: A fork of Mupen64 Nintendo 64 emulator, core library* games-emulation/mupen64plus-input-sdl Available versions: [M]~2.0 Homepage: http://code.google.com/p/mupen64plus/ Description: A fork of Mupen64 Nintendo 64 emulator, SDL input plugin* games-emulation/mupen64plus-rsp-hle Available versions: [M]~2.0 Homepage: http://code.google.com/p/mupen64plus/ Description: A fork of Mupen64 Nintendo 64 emulator, HLE RSP plugin* games-emulation/mupen64plus-ui-console Available versions: [M]~2.0 Homepage: http://code.google.com/p/mupen64plus/ Description: A fork of Mupen64 Nintendo 64 emulator, console UI* games-emulation/mupen64plus-video-glide64mk2 Available versions: [M]~2.0 {hires sse} Homepage: http://code.google.com/p/mupen64plus/ Description: A fork of Mupen64 Nintendo 64 emulator, glide64mk2 video plugin* games-emulation/mupen64plus-video-rice Available versions: [M]~2.0 {sse} Homepage: http://code.google.com/p/mupen64plus/ Description: A fork of Mupen64 Nintendo 64 emulator, rice video plugin* games-emulation/neopocott Available versions: *0.38b^s Homepage: http://sdlemu.ngemu.com/neopocottsdl.php Description: A NeoGeo Pocket emulator for Linux* games-emulation/nestopia Available versions: 1.40 Homepage: http://rbelmont.mameworld.info/?page_id=200 Description: NEStopia is a portable Nintendo Entertainment System emulator written in C++* games-emulation/nestra Available versions: ~0.66-r2 Homepage: http://nestra.linuxgames.com/ Description: NES emulation for Linux/x86* games-emulation/openmsx Available versions: 0.9.1 Homepage: http://openmsx.sourceforge.net/ Description: MSX emulator that aims for perfection* games-emulation/pcsxr Available versions: ~1.9.94^t {alsa cdio ffmpeg nls openal opengl oss pulseaudio +sdl} Homepage: http://pcsxr.codeplex.com Description: PCSX-Reloaded: a fork of PCSX, the discontinued Playstation emulator I'm not sure what GoG is but dropbox as in the cloud service works well in Linux.

I've been using lastpass for a while. No issues so far. I have a few important passwords such as the one time recovery for gmail and lastpass itself in an encrypted text file on dropbox. I use 2 factor auth where ever possible.

You can use the MS office webapp for free. Create a skydrive account and you will see options to create or upload documents.

Thank you very much for this guide! I did this just earlier and successfully flashed a newly ebayed 9211-8i to IT mode. I had done it in the past with a pair of M1015s but on a non-UEFI mobo and had completely forgotten where I found instructions. What could have been hours of research turned into just a few minutes of reading. Card works great with a Supermicro SAS expander and my ZFS pools are all accessible. Also Supermicro mobo FTW. Mine had a built-in UEFI shell which made this a 5 minute process.

I run 2x Gentoo KVM/storage nodes. I stuff more services into fewer VMs to save RAM for ZFS on Linux that also runs on each box. I probably should run separate storage and VM nodes but I prefer to run fewer physical systems at home. Router VM: - Routing for LAN-WAN - BIND - squid - unifi - freeradius - ddclient - icecast - murmur VPN VM: - OpenVPN - Routing for LAN-VPN - BIND slave (queries through VPN) - squid (for browsing through VPN) - rtorrent (the obligatory) These two VMs can migrate and run on either of the 2 host nodes. ..and the interesting bits: Windows gaming VM: This VM has dedicated access to the host graphics card via VGA passthrough. General hardware passthrough has been around for a while but VGA passthrough specifically is newish and starting to become more accessible. It still requires a few unofficial patches to get working but offers solid stability and performance under gaming load. Linux desktop VM: This is my everyday desktop machine for work/browsing/etc. Also has access to the host graphics card. Cannot be used simultaneously with the gaming VM as it needs dedicated access to the same graphics card.

Looks interesting. Thanks for the recommendation. I got distracted gaming far more than usual and still have most of last season to go though So much catching up to do..

You could try this too: http://weconspire.com/

I don't know what exactly determines device order (BIOS/hardware?) but it can change if a higher priority device is introduced. I don't think it will change if you don't add new devices or move things around to different ports. You can reference disks by ID which will never change. Show symlink mappings like this: ls -la /dev/disk/by-id/ This will probably work with most things.

Thanks for the detailed explanation. Use of color.. interesting. Never noticed.

Fonts may be an issue with Firefox and some java apps. Many websites use fonts not included with stock distros. Turning off the ability for pages to use custom fonts fixes much of this. I believe chrome does this by default. Java has a flag that can be enabled to fix their often ugly font rendering too.

Really? I think it could work via USB passthrough to the VM. You can either pick devices to pass in (i.e. the extra keyboard and mouse) by ID, or pass in the entire USB controller to dedicate a few physical ports to the VM. The part I'm thinking may not work so well is the gaming in a VM part. Most virtulization software will run an emulated GPU (if any) so you will get very low graphics performance. There are ways to have the VM access graphics hardware but it requires specific hardware, experimental software, and often a ton of effort to get working.

I believe Webmin does this. http://www.webmin.com/index.html

Gamer products and marketing. How long before we see gaming USB cables that reduce input lag? ..and also has embedded LEDs. Tablet/laptop convertibles. Most are done terribly IMO.

About 55TB usable between the two boxes.

2x Gentoo storage/KVM nodes. One of these boxes also runs my desktop machine as a VM. The host has a dedicated graphics card that is passed to this VM. Otherwise, the two servers are roughly the same. Each box runs ZFS on Linux for storage and NFS exports. Each has the same network configuration - br0 on the LAN VLAN, br1 on the WAN VLAN Ideally I would have data replicated from one box to the other but that is not happening now - they have different data due to overall lack of storage space. It would cost around $1-2k more to make this happen I have 2 VMs that run on either server and can migrate around as needed for increased availability. Most functions live on these VMs: Routing for WAN and LAN network DHCP BIND rtorrent MPD and icecast Unifi WAP controller and freeradius Squid

Virtualbox is good for running desktop guest OSes on a desktop host OS but for hosting servers on a server, KVM makes more sense. Docker is another than is starting get more attention and I'm probably going to be trying it soon. It is not full hardware virtualization but will allow you to run Linux in containers much like OpenVZ and LXC. It should be lighter on resources if you only need Linux VMs.

Something to watch out for is that some 3 Gbps raid controllers (particularly LSI) do not support drives larger than ~2.2 TB. This limitation has nothing to do with the 3 Gbps but simply indicates a generation of hardware that may not support larger drives.

Yes it is sensors. The drive temp output is a custom script. Yes, I'm using ZFS on Linux. I monitor logs occasionally but have not seen any storage related issues. That's not to say there won't be issues if I put it through higher load. I'm not really making it work so hard in a home environment. I'm using version 0.6.2 on kernel 3.10

I'm using all stock fans and letting the motherboard control fan speed and it is barely audible in a silent room... through a wall Seriously, I would not want to be in the same room as this server for any length of time, but a single wall or door will pretty much block all noise. Below are some temps and fan speed data I have at this time. I don't have the same configuration of drives as in my last post as I am shuffling drives and data around for a second machine I will be building soon to finally set up a 1:1 backup of all data. All drives are pretty much idle. I can post temps during a ZFS scrub when I have that going at a later time. coretemp-isa-0000Adapter: ISA adapterPhysical id 0: +33.0°C (high = +74.0°C, crit = +94.0°C)Core 0: +29.0°C (high = +74.0°C, crit = +94.0°C)Core 1: +28.0°C (high = +74.0°C, crit = +94.0°C)Core 2: +33.0°C (high = +74.0°C, crit = +94.0°C)Core 3: +29.0°C (high = +74.0°C, crit = +94.0°C)nct6776-isa-0a30Adapter: ISA adapterVcore: +0.78 V (min = +0.60 V, max = +1.49 V)in1: +1.83 V (min = +1.62 V, max = +1.99 V)AVCC: +3.36 V (min = +2.96 V, max = +3.63 V)+3.3V: +3.36 V (min = +2.96 V, max = +3.63 V)in4: +1.54 V (min = +1.35 V, max = +1.65 V)in5: +1.27 V (min = +1.13 V, max = +1.38 V)3VSB: +3.34 V (min = +2.96 V, max = +3.63 V)Vbat: +3.18 V (min = +2.96 V, max = +3.63 V)fan1: 2738 RPM (min = 300 RPM)fan2: 2566 RPM (min = 300 RPM)fan3: 1355 RPM (min = 300 RPM)fan4: 3000 RPM (min = 300 RPM)fan5: 2662 RPM (min = 300 RPM)SYSTIN: +33.0°C (high = +75.0°C, hyst = +70.0°C) sensor = thermistorCPUTIN: +30.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistorAUXTIN: +2.0°C sensor = thermistorPECI Agent 0: +38.5°C (high = +95.0°C, hyst = +92.0°C)cpu0_vid: +0.000 Vintrusion0: ALARMintrusion1: ALARM2013.12.23.19:31:47 /dev/sda: SAMSUNG HD204UI: 29°C2013.12.23.19:31:47 /dev/sdb: SAMSUNG HD204UI: 30°C2013.12.23.19:31:46 /dev/sdc: ST2000DL004 HD204UI: 30°C or °F2013.12.23.19:31:47 /dev/sdd: SAMSUNG HD204UI: 30°C2013.12.23.19:31:47 /dev/sde: SAMSUNG HD204UI: 29°C2013.12.23.19:31:47 /dev/sdf: SAMSUNG HD204UI: 28°C2013.12.23.19:31:46 /dev/sdg: ST4000DM000-1F2168: 31°C or °F2013.12.23.19:31:46 /dev/sdh: ST4000DM000-1F2168: 32°C or °F2013.12.23.19:31:46 /dev/sdi: ST4000DM000-1F2168: 32°C or °F2013.12.23.19:31:46 /dev/sdj: ST4000DM000-1F2168: 30°C or °F2013.12.23.19:31:47 /dev/sdk: ST4000DM000-1F2168: 31°C or °F2013.12.23.19:31:47 /dev/sdl: ST4000DM000-1F2168: 31°C or °F2013.12.23.19:31:46 /dev/sdm: ST4000DM000-1F2168: 31°C or °F2013.12.23.19:31:46 /dev/sdn: ST4000DM000-1F2168: 30°C or °F2013.12.23.19:31:46 /dev/sdo: ST4000DM000-1F2168: 30°C or °F2013.12.23.19:31:46 /dev/sdp: ST4000DM000-1F2168: 29°C or °F Note that the noise level I described is at the fan speeds noted above. If you let the fans spin up much higher they will very much be audible through a wall or door. It is possible to lock down the PWM values of all fans to any value in software using the Supermicro MB I have though. Works in Linux and I'm assuming Windows would allow you to do it too. I just haven't felt the need to do so.

You can configure DNS to translate internal-10-10-0-5.example.com to 10.10.0.5 or anything you want and make it available externally but routers wouldn't know how to get to 10.* addresses from outside. EC2 nodes get an internal and external address. You can use the internal address for node to node but must use the external address to get to it from outside.

Streaming is based on Nvidia's hardware encoder right? Shield is a good example of how it will perform then. Surprisingly good according to reviews I've seen.

Its a pointless thread now where people try hard to convince themselves that what they use is the best. Those who are actually interested in Linux should be going out trying it rather than reading this.

There is sort of a workaround through virtualization. Recently it became possible to reliably pass consumer graphics cards to VM guests with full hardware access. You can run a Windows guest with a graphics card solely for streaming. It doesn't need any monitors hooked up and can be managed through RDP. The host machine could still be doing other things using on board graphics or another dedicated graphics card if you have multiple. You could also have a steam OS guest on the same machine that would receive the stream for "playing locally". Latency should be low going from one VM to another on the same hardware. The machine can have multiple streaming guests if you have more graphics cards. It's like GRID but built out of cheap (relatively) components. I have the virtualization piece working so the rest of it is something I'll be playing with once steam OS is released.

So I'm a Linux admin and not a Windows admin so I admit that I'm a little biased and I don't know as much about Windows operation but from my experience, finding the keys I am looking for in the registry has never been easy. Is this not typically the case? Also given that documentation is typically focused on GUI operation, I think often times the settings file and registry entries are up to the user to figure out. In general I feel that just as the GUI operation is not well integrated into Linux, the CLI operation is not well integrated into Windows. Edit: For those wanting to switch to Linux but keep Windows for games, here is one option with detailed instructions: https://bbs.archlinux.org/viewtopic.php?pid=1270311 It will pass a graphics card to a VM so that the guest has full access to the hardware. I got it working a few days ago and I can confirm it is a solid solution. I've done a few hours of gaming and I haven't seen any issues or even any errors logged. *You do need a motherboard and CPU that supports VT-d*

Is there an assumption going on here that a GUI with check boxes is universally preferred over a text file configuration? There are many people such as myself that prefer text file configurations for reasons such as transparency, portability, ease of automation/deployment scripting, ease of recovery of broken or otherwise unbootable systems, etc. I love that *nix software generally do this.