Please help a Linux newbie tryout gaming Ubuntu!

Hello, I have a Lenovo y500 i7-3630qm, 750m sli, 8 gb ram, and 1 tb hdd. I have always been a windows guy, but I'm trying out Ubuntu as a dual install. If Linux impresses me, I'll completely switch, but I'm a student and a gamer so let me present my questions.
1. How can adjust advanced power management settings to lengthen battery life?
2. How can I adjust brightness? It won't let me.
3. I love the whole Assassin's Creed series. I am currently installing wine and I have all of the discs, but no disc drive. Can I download Uplay or other Windows digital download games through Wine or another program? Also, how do I go about installing games through WIne or another Linux program? I will use Steam when I can, but a lot of my games are on discs.
4. What are the Linux equivalent to a gamebooster, bandicam or fraps, benchmark programs, photoshop, movie maker, media player, and any other common apps?
I'm excited to try this out, I've heard it is more resource effeicient than Windows and that through Steam it will out perform Windows! Also, it has a great UI and lots of open source software. Please feel free to post any suggestions or ideas to help get me started. I'm open to anything in this thread!
Thanks and God Bless,
Drew

 

Does anyone know how to switch sli on and off in Ubuntu?

 

1. Partially this is kernel mode settings. You can read up on those and possibly compile your own kernel eventually, but newer kernels end up pretty low anyway. Usually it's about enabling a different schema for scheduling and raising the overall battery drain that happens. But it's also mode-switches and module inserts dependent on hardware. There's a specific one for lenovo laptops(tp_smapi). Also, certain acpi calls included. Finally, choice of window manager, managing and turning off hardware you're not using (powertop is a start. My current favourite window manager is cinnamon, for just ease of use and simplicity, but with the composite manager control: 3d, desktop flipping, window redraw priority set to only visible windows, etc).

2. This is either part of the tp_smapi or the nvidia driver, depending on the kernel switches/detection order, which then your desktop environment will have to pick up on. The breakage between these two is probably what's causing the delay in getting it to work right away. But as long as the backlight "device" is present, you can edit the /sys/class/backlight/---- files and set the backlight level that way. But with a properly installed driver and so on, this should be set to a default name, and handled by the desktop environment and sent to keys, switches, sliders, etc.

3. Wine is not a windows emulator, but a virtual environment running the windows library calls. In theory, it should - and that is actually what happens in certain cases - be able to run flawlessly .... provided that all libraries are present. The problem with getting certain games to run is that they provide parts of the library batch, and don't actually document the required ones. While over again relying on internal library versions that call "unknown", or undeclared libraries directly (or assume they exist from preload). This is what makes this difficult, and why often installers hang, but the actual game works perfectly fine, for example. Other well known problem is that the drm solutions rely on 3rd party software inserts, that are not documented or declared, but only installed through certificates in ways that normal user-software cannot be. This will likely never run on wine.

Some games run easily, and run well, though. But it often takes some effort to get it to run at all. A much more tenable solution is to push developers to consciously create multiplatform targets when creating projects. Not to have ports, but to have a toolchain targeting several platforms. Many new and good games actually have this, and some of them (by no means all) are available on Steam. Buy those. That's the way to change any of that.

For older games, have a look at winehq. They have lists of games people are able to run. I often play Nexus: The Jupiter Incident, for example (the drm-free version from gog.com). And that version runs better under wine than it does under windows. Just as an example. I also don't lock the entire system while running the game, etc. So it's not like it's a "second choice" here. It's more of an ups and downs kind of proposition.

4. Most commonly used software tends to exist in the package well. But I wouldn't recommend going about trying to find replacement for specific programs. Try finding something that does the task you wish to accomplish. Search for that, and you could end up finding many alternatives. For example, I needed a small text-editor with simple line, paragraph and page controls. Something similar to textpad in windows, just a bit more stylish, and with support for more formats. And there are several like that. In and out of the standard package well. Some developers provide binary versions of their software as well. It's not recommended to rely on that, with lack of integration and so on being the main problem. But sometimes it's possible to find good commercial software that way. Also, good commercial software can be had in pre-made packages for well-known distros. So there's that. Frame-capture programs can be anything from streaming in vlc to "recordmydesktop" and a manual encode via ffmpeg, etc. Video-editors - not seen too many that will beat the typical ones in Windows, but some exist, and they are getting better. Gimp can replace Photoshop to some extent.

But note that finding an identical program is likely not going to happen. And if you require that, you require a double boot and you're essentially temping

First thing you should do is getting comfortable with switching around desktop environments, though. Just to get a feel of how the system is put together. That there's a kernel and a low level environment. That the desktop environment runs on top of. Which then you run programs in. And that these programs can run in more or less all environments provided the right libraries are available and loaded, etc. That we're not actually dealing with integration between user-programs and the system-level. But rather "something" that shows you "programs", resting on a kernel. Understanding this kind of thing is at least a little bit useful when starting out. I.e., the problem is not choosing gnome or Kde, but what's running below and in it.