LinuxMCE Forums
General => Feature requests & roadmap => Topic started by: Armor Gnome on August 17, 2012, 02:32:40 am
-
This is just an observation, but from it there may be room to strip down some installer components and improve the disk-less creation process. This actually may be part of the design and a wanted feature so I will leave some options open in my suggestions for that case.
I entered KDE on a media director to see if I could adjust some nvidia settings using their x_config_prog. What I found was a pretty large application list installed, considerably more than is installed on the core machine during DVD install. Five or Six media players (additional to LMCE flavor, such as amarock and dragon), a lot of office applications and other features you would expect from a 10.04 install with KDE desktop. It seemed a little excessive to me on a diskless MD that most users probably never access. Perhaps by stripping down a lot of these packages, install times and load times could be improved?
Questions:
Is this "full" desktop a design feature? Are these components present so that the MD can optionally function as a desktop?
Did I by going to KDE desktop on that MD load or unpack applications that otherwise would not have fully installed on that MD?
As I start loading more and more Media Directors to my setup I am (unreasonably) concerned about the growing core install location. Although it may sound controlling and like I want to manage things LMCE can do by itself I would like to move to tiny fast drives in raid on a core machine with all media files stored on a NAS. Because of that desire I have a few other questions about the way diskless devices are managed on the core. This will help me understand what might be necessary to formally suggest any new install features.
Where I used to imagine diskless images like .iso files stored on a remote machine, I now better understand that installers are files and folders with commands that spawn more files, folders and commands.
Are the /lib files shared among MDs or are they duplicated on the core for each MD?
Is there a reason these /pluto/diskless folders couldn't be stored on a NAS?
Is there room for development work on the Diskless_Create.sh? I would be willing to take a look at slimming down some components where possible.
Would anyone benefit from a prompt on the MD creation process pre-AV wizard that asks "Would you like add desktop functionality?", "will this be a designated media only location?" or even
"Would you like this location to function as audio only?"
I think the MD creation process works wonderfully and am not reporting a buggy feature, I am just looking for ways to add a customizable experience while remaining as automagical as possible.
-
Yes,... A full desktop resides within the MD netboot setup. Has, at least since 0810. (I dabbled until my Intel chipsets became too much a bar).
At this time I recommend leaving it... Not that your point isn't well taken, but there are useful utilities and programs that can be made (forced?!) to run on a full KDE capable system... Think; games, communication apps, games, social networking crap, ... and Oh Yeah! games.
That said,... To dump nepomuk, stingi and akonadi server like they were plutonium? Amen.
There can also stand to be MD tweaking, if one was inclined to do so,... Like, changing swappiness, optimizing network latency, etc. ... But that's a whole additional wish list... and requires a crapload of empirical testing (I'm up for it,... but not at this exact moment in my life).
-
Feel free to trim things down. You will need to look at UbuntuDiskless, and the package database that we have in the web admin to see how this is happening.
Once again, I have said repeatedly in the past that the "desktop" feature is an absolute hell of inconsistency that can never be fixed correctly. There is no reason to have a desktop on the TV. None. Zero. No argument. There isn't one. No. Nuh uh.
-Thom
-
I agree, A desktop is not needed to run apps in Linux.
-
I like the option to go to the desktop. Why? Because each PC in the household can function as a media director, and still have access to whatever computing needs need to be done.
-
It appears we are pretty down the middle for use of MD desktop environments. Thank you for your opinions, especially from the developers who commented as I always appreciate that level of input to get a grasp on the goal or focus of LinuxMCE.
I personally feel strongly about the ability to choose the type of LinuxMCE experience you want, as long as 99.9% of processes go on without requiring user input. As the current MD creation process goes all a user needs to do is set a PC to network boot from BIOS and turn it on. No other input is necessary until the AV wizard starts, we even have a pretty splash screen so you don't have to see the text.
I have just started looking through the code necessary for these diskless creations and although I haven't found the exact loader yet for the desktop items I do have a suggestion. Yes, I know my formating is not loader formal but I am expressing function here without eye glazing anyone with code examples.
timeout 5
default 0
-run diskless_setup as is
-init= as is
-run nodesktop_diskless setup
-init = newly altered by me
-run custom_diskless
-advanced option for things like putting the image on a NAS, audio only MD, etc
This is simple enough that users who choose to alter the MD creation process can, and those who like everything done for them can still turn it on and watch it go and the entire process is only 5 seconds longer.
I hope to compile my first installer this weekend for another project. Depending on how that goes and how comfortable I am with the process, I will grab some lmce sc and see if I can put together some testable scripts.
*Edit, just re-read tschak909's post and will check out the package database in web-admin. The code I was looking at was coming from wiki>sourcecode>lmce site.
-
I like the option to go to the desktop. Why? Because each PC in the household can function as a media director, and still have access to whatever computing needs need to be done.
My vote is with Posde on this...
Plus, realize that any apps that you use that are desktop oriented, like Hulu, the Firefox web interface (Web Admin Control) & game emulators will need at least a basic DE to display and/or operate properly. Ma=ny apps lack menu options to exit, and such, and rely on the DE for that.
Without at least something of a DE operating, you'll lose much of that. For example, if Firefox can't function properly (and I'm not saying it can't be made to, some other way), you're forced to use the Web admin on a non LinuxMCE machine attached to the internal network.
I agree that there's no need for a full fleshed out environment (word processing, desktop widgets, etc), but sometimes you need to use a program or utility. Of course, it could be possible to replace the existing UI with separate QT app components running on a slimmed down KDE desktop (not to say it should be).
I assume KDE was chosen to provide a full QT environment in the first place,... no?! Whether that was the reason, or some other, there is probably some underlying reason it was picked, because of something it provides.
There definitely should be some discussion on this. It IS possible to start a second X11 session on another console and run the desktop there, as an option (it is also a good way to run games that tax the system under a DE).
-
I can understand your vote on this JaseP. But your reasoning for it is blatantly inaccurate.
(1) xfwm4 is the window manager, and Orbiter is a window controller under that system. You do not need a DE for this.
(2) Firefox was never meant to be the default web browser, it will be replaced. But even with this, Orbiter can manipulate the window, even if it needs to be slightly bug fixed.
(3) The game emulations to run under the Game Player in LinuxMCE will NOT require a desktop environment, because they have either been patched to not need one, or have a method of communicating their state effectively.
As for why it was picked, it was simply tacked on because Paul Webber wanted a desktop. There was no thought to it, no design. KDE was chosen because at the time, the combination was the only one that properly would interact with Orbiter's unique compositing requirements. This is no longer the case. Orbiter does not use Qt, neither did much of anything else for that matter.
Any sort of desktop work can be done elsewhere, and the TV is _NOT_ the place for it. This is a geek cop out.
-Thom
-
Thanks for the background info, Thom,... It helps to clarify a lot of things.
Just a couple of personal preferences, which turn to questions...
It's nice to have certain utilities/programs;
- A terminal window (preferably with translucency, so you can see underneath to web pages, PDFs, etc.)
- A graphical text editor (so you don't have to go out to a terminal & use vi or nano)
- A basic web browser
- A small handful of nice, native Linux games
- Some other native Linux apps (Skype?! etc?! ... depending on preferences)
Which brings up the questions;
- Will dumping the KDE desktop, entirely, affect any of this in any way? I assume not, since xfwm4 is being used, and could supply the necessary wm controls.
- Will editing xfwm4 preferences with the xfce settings manager allow a user to make any changes in appearance/behavior/etc in LinuxMCE? (Since xfwm4 is part of xfce)
- Would any/all native apps/games need a wrapper to be able to use inputs (games controllers, etc.)?
- Could a second X11 session (to run certain demanding apps/games) be started/stopped by the DCE router, by only listening for a particular keyboard combo, but passing all other inputs along to the X11 session and app? (just a theoretical question, for now)
-
Good day folks!
Having been thinking about this for quite some time (but not having the full understanding of the LMCE architecture to implement it) I think both camps could be satisfied with the concept of 'roles' for net-booted devices. My thoughts were along the lines of:
- MD
- Workstation (or laptop)
- Workstation w/MD
- Workstation w/orbiter
Imagine this: when a device is net-booted for the first time, the wizard asks what role this machine will be fulfilling (with some helpful text around it explaining what each does). Then, the applicable software packages are applied onto the base OS to full-fill the role. We're implementing a similar approach at work for server builds, using Puppet http://puppetlabs.com/puppet/puppet-open-source/, which is a configuration and compliance management tool. It uses a component called Facter http://www.puppetlabs.com/puppet/related-projects/facter/ to determine facts about a client system (like architecture, virtual, OS Family/release, etc.) which can be used to take actions based on the facts it discovers about the system. It can be used to configure software packages, user and service accounts, install or remove software, change system parameters (like sysctl), etc. And, there's a nice community of pre-built modules http://forge.puppetlabs.com/modules, plus stuff on github, or you can write your own (including facts you wish to discover, then act on).
It's a powerful configuration framework which I think would be a good fit for LinuxMCE. It would be a radical change in how LMCE works under-the-hood, and I think it would make future upgrades and life-cycle management activities a lot easier, as you can specify different things based on custom facts or facts like the OS version or hardware architecture. Think Pi MD vs an x86 MD. You can have the same role applied to both, but satisfy the architecture specific dependencies and configuration using the same toolset and policy. You can also use it to manage the core and it's services. There are implementations on the web where folks are using Puppet to build the PuppetMaster server, which is then used to build client systems (allowing them to bootstrap an entire environment, lets say in a disaster scenario).
Puppet is something that can be implemented incrementally, when each change you want to make is quantified, so it represents a low risk to stability. Start with the easy and non-intrusive stuff first, and as the implementation matures, go for the more intrusive changes one-by-one. That's the approach we're taking with 3 *nix OS Families, 4 hardware architectures, 4 hypervisors, and 10 OS variants in production. I thought I'd throw this option out for discussion, since there's a lot of interest in making the MD's (and other PC's) fit-for-purpose. Feel free to browse the links above, google it, or 'apt-cache show puppet puppetmaster facter' from your core.
Hope this provides some food for thought! Thanks for your time!
/Mike
-
/me wonders what the big thing is? People who do not press the KDE Desktop button, don't have a problem other than maybe a gig of wasted space, so what?!
-
Good day folks!
Having been thinking about this for quite some time (but not having the full understanding of the LMCE architecture to implement it) I think both camps could be satisfied with the concept of 'roles' for net-booted devices. My thoughts were along the lines of:
- MD
- Workstation (or laptop)
- Workstation w/MD
- Workstation w/orbiter
...
/Mike
That would add 3-4x the necessary MD generation scripts, yielding 3-4x the possible points for breakdown/bugs.
- As for workstations, ... just install the OS of your choice. Why netboot? LinuxMCE will generally see shared drives it puts out (I think, anyway).
- For workstations with Orbiter, install the WinOrbiter in WinXP-7 or using Wine in Linux (or resurrect the dedicated Linux Orbiter code and hack/recompile it to be an installable app).
- For workstations with an MD, use VirtualBox to install a virtual machine MD.
What you're talking about would be easier with an Orbiter running on a desktop (in any one of several ways). LinuxMCE can make the media available to non LinuxMCE devices over the network, as a Samba share. You control other functions with an Orbiter... Even my own MD in a VM experiment is a bit over the top, a bit like running a TV tuner app on a desktop... Great for not doing productive work well multitasking, but really unnecessary, if you think about it.
Thom's got a point about not computing on a TV. Posde's got a point about, "so what?! So, just don't use it." Once the qOrbiter is done, it would make a lot of this moot, anyway.
-
I'm going to through this out there and I am probably going to get a lot of rap for this. KDE maybe a waste of 1 gig but it is also a resource hog and any of the desktops for that matter. that extra resource could be used in better ways. Here is an example take a computer lying around and install a distribution without a desktop. second install X and your chosen program. and call it from a command line. it will work, I have done this before.
-
KDE's not being called up unless you select it from the menu. The only resource it takes up, then, is the hard drive spacemon the Core. That's what Posde was saying.
-
I've used it ALOT for troubleshooting, but that's because I'm more familiar with the GNU/Linux terminal than I am LMCE :)
I agree with Tschak though. No need for a full desktop. Gimme a web browser and a terminal window and I'm happy!
Running terminal in 1080p is just sexy. Neighbours must think I'm all Swordfish up in here:)
-
I think the discussion on this topic has been great. I just want to remind everyone that I placed this thread in this forum for a reason. This is clearly a new feature/option and as 10.04 is in beta now, even if I polished off changes today they would need testing, debugging, etc that would have to wait for the real work of bug squashing to wrap up. Where the implementation of this is pretty straight forward for me, what really remains on the table is the roadmap side of this discussion.
Standardization vs. Customization?
Three years ago there really didn't seem to be any support for non-typical installs. I brought up virtual options like VMware and was quickly told "nope, no hardware acceleration" case closed, drop it. Today if you look over the forums or hop in IRC you hear all kinds of setups. Virtual Core, virtual MD, virtual core and MD in the same virtualbox... Where a dev trying to support someone used to only ask "Is this your core or an MD?" now has to ask "What OS is your virtual box running in?, You're trying to do what with what?" etc.
Personally I am a fan of customization options, but I completely understand I am not a typical user. I actually enjoy time adjusting options, rebooting and tweaking settings and for the most part not using my system. Non-OCD folks just want it to work. Buy a Z-Box, Revo, Roku, etc and just plug it in. Want network streaming audio, buy the newest Squeezebox off the shelf and turn it on, etc. To continue giving the typical user this type of experience I feel the only way to add customization is with very brief timeout/default options at first startup.
What level of customization is too much? Everyone knows if it were possible I would have Apple II's running 1/2 an application each all around my house. I would replace my gig switch with a 1920's telephone patch panel and manually route media to different rooms myself. Tschak909 and Posde want to smack me already so before they do I will just clarify again that I understand that is not what LMCE is all about.
Since I tossed this out there I will be the one to have a first crack at it and will submit what I come up with for everyone to review. Typically I overthink things but in this case I might be thinking its too easy of a change. The DVD installer adds some desktop applications on the hybrid/core. It was odd to me then that the Diskless_Setup by default actually creates more desktop applications and programs. If there is discussion about the usefulness of a desktop environment lets keep it to media director only. The core/hybrid has a desktop now and if you want to add little progs or apps then put them there or work on changing the primary installer.
My proposal and the task I believe I am up to involved the Diskless_Setup only, it is something I think I have the ability to change myself with my limited programming ability. Correct me if I am completely off the wall but this is how I think the process works.
A new device is plugged into the network and looks for a DHCP to point it towards a bootloader.
DCErouter (specifically tftpboot.cfg) creates a few new directories based on its MAC address and points it to initrd and vnlinuz
The new device uses these as kernel= and boot=, and builds its image in root=<core>/?/nfs
Based on the content of vnlinuz and initrd, combined with polled info from various scripts the MD image is created just as it would install itself on a computer with a ubuntu install cd.
-add my changes
Because bootloaders can have options in the menu.1st file (sorry I know grub best, even though lmce I think uses something else because of the APPEND options) I believe I can add options here that will point to alternative initrd and vnlinuz versions.
Default option = just like it is now
Option1 = load initrd and vnlinuz that install different applications
Option2 = load initrd and vnlinuz that install different applications
Option3 = load initrd and vnlinuz that install different applications
There are options in the web-admin and warnings about kernel version on MDs so that part I don't think I have any control over. I have tinkered though and adjusted the bootloader on the core to point a specific MAC address to a custom folder which booted TinyCore, DSL, 12.04 LTS and openWRT on different machines around my house. I never got my own custom dsl+squeezebox configuration to boot however and is what led me to the idea of taking LMCE's setup and changing it to my desire.
I believe that I can take all of the source code needed to compile LMCE diskless, change and remove certain components and then compile and make options in the bootloader menu to select that version. Is that an accurate statement? Obviously I would need to debug and repeat a lot of effort but because I am only altering working source code, I would assume I am only looking at minor necessary work. The years of hard work and coding behind current LMCE remains and I am just the jack-wagon that stripped some off.
If some off-the-shelf hardware doesn't quite fit the bill for a full MD, why not have the option to boot as audio only MD? If an MD is going on the bedroom wall where a keyboard will never touch it why not have the ability to boot it without a desktop? If I want to build a minimal media MD for use as an intercom outdoors, why can't I load a boot template designed for just that? These are all just pipe-dreams of mine at this time as I haven't done yet any modification or compiling of lmce code. I have just booted other pre-compiled kernels using lmce tftpboot.
Hopefully this novel of a comment clears up what I plan to do and how I plan to do it. After everyone has a laugh at my ignorance please feel free to correct me. :)
-
Hi, great topic! Figure I'll put my 2 cents in here as I understand things as I am working on an alternate MD right now.
I don't really think the MDs are bloated. That will depend on you point of view I suppose but many appreciate the functionality. My MDs occupy 2.7GB of space each on my core (without Game_Player). Even with 5 MDs I only consume 22GB of space on my core. I can't even buy an HD of less than about 30GB (20GB for SDD) these days and can even get an SSD for $50 in that size. My personal feeling is to leave the stuff in place and don't hit the 'Start KDE' button unless you want to. Removing KDE entirely would not quite save ~1GB per MD. I don't see a space concern/savings. I don't see significant 'bloat'.
Since I tossed this out there I will be the one to have a first crack at it and will submit what I come up with for everyone to review. Typically I overthink things but in this case I might be thinking its too easy of a change. The DVD installer adds some desktop applications on the hybrid/core. It was odd to me then that the Diskless_Setup by default actually creates more desktop applications and programs. If there is discussion about the usefulness of a desktop environment lets keep it to media director only. The core/hybrid has a desktop now and if you want to add little progs or apps then put them there or work on changing the primary installer.
The difference in applications is more about where the packages come from than what is intentionally being installed. The hybrid/core packages are taken directly from a kubuntu live cd, the MD files are built through package installation. The liveCD has packages removed, by the kubuntu team, to allow for it to live within the small space of a single CD. The MD diskless image is created and the package 'kubuntu-desktop' is installed from repository, which installs all of kubuntu and all of the packages you see on an MD. In my recollection of the setup procedures this is the primary difference in the packages available on the core and on an MD. This also causes some services to be started on MDs that are not run on the core, iirc.
My proposal and the task I believe I am up to involved the Diskless_Setup only, it is something I think I have the ability to change myself with my limited programming ability. Correct me if I am completely off the wall but this is how I think the process works.
A new device is plugged into the network and looks for a DHCP to point it towards a bootloader.
DCErouter (specifically tftpboot.cfg) creates a few new directories based on its MAC address and points it to initrd and vnlinuz
The new device uses these as kernel= and boot=, and builds its image in root=<core>/?/nfs
Based on the content of vnlinuz and initrd, combined with polled info from various scripts the MD image is created just as it would install itself on a computer with a ubuntu install cd.
-add my changes
Because bootloaders can have options in the menu.1st file (sorry I know grub best, even though lmce I think uses something else because of the APPEND options) I believe I can add options here that will point to alternative initrd and vnlinuz versions.
Default option = just like it is now
Option1 = load initrd and vnlinuz that install different applications
Option2 = load initrd and vnlinuz that install different applications
Option3 = load initrd and vnlinuz that install different applications
There are options in the web-admin and warnings about kernel version on MDs so that part I don't think I have any control over. I have tinkered though and adjusted the bootloader on the core to point a specific MAC address to a custom folder which booted TinyCore, DSL, 12.04 LTS and openWRT on different machines around my house. I never got my own custom dsl+squeezebox configuration to boot however and is what led me to the idea of taking LMCE's setup and changing it to my desire.
I believe that I can take all of the source code needed to compile LMCE diskless, change and remove certain components and then compile and make options in the bootloader menu to select that version. Is that an accurate statement? Obviously I would need to debug and repeat a lot of effort but because I am only altering working source code, I would assume I am only looking at minor necessary work. The years of hard work and coding behind current LMCE remains and I am just the jack-wagon that stripped some off.
If some off-the-shelf hardware doesn't quite fit the bill for a full MD, why not have the option to boot as audio only MD? If an MD is going on the bedroom wall where a keyboard will never touch it why not have the ability to boot it without a desktop? If I want to build a minimal media MD for use as an intercom outdoors, why can't I load a boot template designed for just that? These are all just pipe-dreams of mine at this time as I haven't done yet any modification or compiling of lmce code. I have just booted other pre-compiled kernels using lmce tftpboot.
Issues/Challenges I see:
There is no 'bootloader' per se. PXE loads kernel/initrd (common if the MAC is not found, from diskless/XX if the device exists) which bootstraps the running kernel from the diskless/XX directory. Grub is not used on the MDs as they are PXE booted, which occurs before grub would have a chance to run. This behaviour cannot be changed without significant user interaction to install grub on the MD before attempting the first boot. This would significantly detract from the 'plug and play' nature of the system.
Your statements about adding bootloader options and "If an MD is going on the bedroom wall where a keyboard will never touch it why not have the ability to boot it without a desktop?" are contradictory. Remember that an MD is not intended to have a keyboard and mouse connected and as such there is likely no interaction between the user and the bootloader on an MD. This is desired behaviour and likely how it should remain. There is a reason that there is no user interaction with the MD until the AVWizard which allows for many different input devices to manipulate it, including game controllers and IR remotes, which cannot interact with a bootloader. Adding a bootloader is going to significantly add to the boot time of the media director everytime it boots. This, to me, is not desireable and would degrade the experience significantly.
What you are trying to achieve IS doable though... The 'right' way to approach this???:
"If some off-the-shelf hardware doesn't quite fit the bill for a full MD, why not have the option to boot as audio only MD?" - This is exactly what device templates are for. All MDs are currently built on the 'Generic PC as MD' device template. That doesn't have to be the case. Device templates could, *should*, be created for different devices that cannot act as a full MD. This give you the ability to add that device and have an lmce core create the device (and associated diskless folders, etc.) within its' capabilities. This could be as simple as the device being recognized under the alternate device template on first PXE boot, or if the device is capable of a Full MD but you want less, you could add the 'less of a MD' device template manually and enter the MAC address into the webadmin. As you have already discovered the nfsboot folders can be altered/changed to accomodate any device. Those folders can be setup properly (and automatically) through the use of device templates.
Existing functionality of MDs, and the current method of Diskless_Setup, should be left entirely intact as it is desireable for many. New DTs that create new (different) directory structures under /diskless/XX/ at the moment the DT is added would be my recommendation. This will require changes to Diskless_Setup as well, but would leave existing MD generation the way it is. This is what I am attempting with the Raspberry Pi. I haven't made it to the DT/autosetup part yet.
Hopefully this novel of a comment clears up what I plan to do and how I plan to do it. After everyone has a laugh at my ignorance please feel free to correct me. :)
No laughing. I don't intend to sound too critical either, I tend to over-analyze and point out down-sides, it's a back character trait of mine. But I understand what you are trying to do and think it could be very useful if applied in a way that is consistent with the mechanics of the existing system.
J.
-
Well, since I had to touch it anyways...
Here is a /usr/pluto/bin/Diskless_CreateTBZ.sh that I am testing. I have included a simple option to not install the kubuntu-desktop package. The resulting MD works and is ~1G smaller. There is no desktop available. If you choose Start KDE I don't know what will happen, you're on your own. This is not intended to be a supported feature, but if you *really* feel strongly about not having kde installed on your MDs then you can try this.
http://pastebin.com/KpEGER17
Copy it into a file on your core (mine is currently /usr/pluto/bin/newDiskless_CreateTBZ.sh) and chmod +x it. Then run it. It should work (I've tested it once here) but let me know if you encounter any issues. Logging is unfortunately disabled as it was causing strangeness I havn't worked out yet.
If it doesn't work then re-run your original /usr/pluto/bin/Diskless_CreateTBZ.sh to recreate your MD tarball and continue on your way.
J.
-
Awesome. I should have posted that this feature request topic I started was back burnered for a few reasons.
Lack of a media director.
Inability.
No large payout (1gig) for the time needed to teach myself coding at that level.
Split opinions on the features benefit.
If you were in there anyways and was curious then awesome! If you dug around at my request let me know if I owe you for your time. I will grab your pastebin tommorow as I have a curiosity about dropping other items from create_diskless, such a X. That is the fail point for 90% of my media director attempts. Thank you.
-
If you were in there anyways and was curious then awesome! If you dug around at my request let me know if I owe you for your time. I will grab your pastebin tommorow as I have a curiosity about dropping other items from create_diskless, such a X. That is the fail point for 90% of my media director attempts. Thank you.
As I said, I was in there already working on RPi tarball creation. I have tested it once, it builds a MD tarball that boots to orbiter, that's all I have tested. This is an experiment and is NOT supported! !! DO NOT SELECT START KDE, it will hang the MD !! Again, this is NOT supported. :)
Unfortunately X is a requirement for MDs. There is no removing X. I have never seen X 'fail' to install on any MD. Video drivers on the other hand are a headache and can prevent X from running. L3mce is working on improving video card detection/driver installation. If you have video card driver problems you should talk to him about your card(s). You will want to learn about and use the system for a while (at least a year, if not two or more) to really understand the internals before trying to remove something.
J.