Sabtu, 18 Januari 2014

Xathrya Sabertooth

Xathrya Sabertooth

Access Ext3, ReiserFS, XFS in Windows using coLinux

Posted: 17 Jan 2014 08:18 PM PST

One of the problem with Windows Operating System is the narrow-range variety of available filesystem. When using Windows, you are limited to FAT and NTFS family file system. Now, suppose you want to access ext3, reiserfs, or XFS partition on Windows there is no way Windows facilitate this unless you do something. This article will describe the step for doing it using coLinux as tool.

In this article I use following:

  1. Windows 7 32-bit
  2. coLinux 0.7.9
  3. Ubuntu Image 9.04

Note: when this article written (18 January 2014) coLinux can only be used on 32-bit Windows!!

You can try any 32-bit Windows (Vista, 7, 8) but the system tested here is Windows 7 32-bit.

There are some alternative to Ubuntu: Alpine,Debian, Fedora, Gentoo, ArchLinux, Slackware. All of them use kernel 2.6. As the reason for using 9.04 is personal, you can use higher version available.

The Idea Behind

coLinux or cooperative Linux, is a free and open source Linux kernel running on Windows natively. We can say the linux kernel is run alongside Windows on single machine, like a virtual machine does. However the difference is we don’t emulate a machine to do this instead we run the linux kernel itself. Thus it is theoretically much more optimal than using any general purpose PC virtualization software.

So in general, we will do following scenario:

  1. install coLinux on Windows machine
  2. Assure access to disk partition
  3. Export all the mounted file system using samba

Much of the process will use command line interface (cmd.exe) which you should open using administration privilege.

Installation Step

coLinux can be obtained freely from their official site, or go to sourceforge site to download it. The version used here is 0.7.9-linux2.6.33.7. Download the installer and install it in C:\coLinux directory.

Edit the connection settings of the virtual ethernet card installed by the coLinux (It should be listed as “TAP Win32 Adapter V8 (coLinux)”). In the TCP/IP settings, set: IP address to 192.168.37.10 and Subnet Mask to 255.255.255.0

Download Ubuntu 9.04 disk image from sourceforge (listed as Ubuntu-9.04-1gb.7z). Extract the image file (Ubuntu-9.04.ext3.1gb.fs) to C:\coLinux. Note that you should have 7zip to extract this file. Now create a swap (for example 128MB swap) using following command on coLinux:

fsutil file createnew c:\coLinux\swap128.fs 134217728

You should know where the magic number comes ;)

Also make sure you run mkswap in Linux and make sure there is corresponding line in fstab.

Rename the file Ubuntu-9.04.ext3.1gb.fs to ubuntu.fs so we have two files: ubuntu.fs and swap128.fs.

Copy the example.conf to ubuntu.conf and edit it. Alternatively you can copy this text and save it as ubuntu.conf.

#  # This is an example for a configuration file that can  # be passed to colinux-daemon in this manner:  #  #    colinux-daemon @example.conf  #  # Note that you can still prepend or append configuration and   # boot parameters before and after '@', or you can use more   # that one '@ to load several settings one after another.  #   #    colinux-daemon @example.conf @overrider.conf mem=32  #  # Full list of config params is listed in colinux-daemon.txt.    # The default kernel  kernel=vmlinux    # File contains the root file system.  # Download and extract preconfigured file from SF "Images for 2.6".  cobd0="c:\coLinux\ubuntu.fs"    # Swap device, should be an empty file with 128..512MB.  cobd1="c:\coLinux\swap128.fs"    # Tell kernel the name of root device (mostly /dev/cobd0,  # /dev/cobd/0 on Gentoo)  # This parameter will be forward to Linux kernel.  root=/dev/cobd0    # Additional kernel parameters (ro = rootfs mount read only)  ro    # Initrd installs modules into the root file system.  # Need only on first boot.  initrd=initrd.gz    # Maximal memory for linux guest  mem=32    # Select console size, default is 80x25  #cocon=120x40    # Slirp for internet connection (outgoing)  # Inside running coLinux configure eth0 with this static settings:  # ipaddress 10.0.2.15   broadcast  10.0.2.255   netmask 255.255.255.0  # gateway   10.0.2.2    nameserver 10.0.2.3  eth0=slirp    # Tuntap as private network between guest and host on second linux device  eth1=tuntap    # Setup for serial device  #ttys0=COM1,"BAUD=115200 PARITY=n DATA=8 STOP=1 dtr=on rts=on"    # Run an application on colinux start (Sample Xming, a Xserver)  #exec0=C:\Programs\Xming\Xming.exe,":0 -clipboard -multiwindow -ac"

If you copy and edit from example.conf, there are lines you need to change. In the end you should make sure following entries exist:

cobd0=C:\coLinux\ubuntu.fs  cobd1=C:\coLinux\swap128.fs  mem=32  eth0=slirp  eth1=tuntap

Now create ubuntu-start.cmd with following content:

set COLINUX_CONSOLE_FONT=Lucida Console:12  set COLINUX_CONSOLE_EXIT_ON_DETACH=1  colinux-daemon.exe -t nt @ubuntu.conf

Then run ubuntu-start.cmd.

Next we do some configuration. Login as root with default password “root”. You can change the root password if you want.

Run the editor and edit /etc/network/interfaces. Add following:

auto eth1  iface eth1 inet static  address 192.168.37.20  network 192.168.37.0  netmask 255.255.255.0  broadcast 192.168.37.255

Bringing up the eth1 by

ifup eth1

Test the network by pinging from our Linux to Windows. It should work now.

ping 192.168.37.10

Next we do update to install necessary package.

aptitude update  aptitude safe-upgrade  aptitude install samba openssh-server mc  apt-get clean

Open /etc/fuse.conf and remove # at the beginning of the line user_allow_other

Open /etc/ssh/sshd_config and change PermitRootLogin to “no”

Add new user named user1 (or any name you wish) and next we can login to this account via ssh:

adduser user1

But first, we need to reload the SSH server:

/et/init.d/ssh reload

At this point, use SSH client such as putty to check whether you can login to Linux via SSH.

Mount File System

First, search for the partition you want to mount. Let’ say it is \Device\Harddisk1\Partition4

If you have ran ubuntu-start.cmd (the system is running) then halt it before going further.

Edit ubuntu.conf and insert following:

cobd2="\Device\Harddisk1\Partition4"

Then run ubuntu-start.cmd (or halt the previous machine and restart it). Then login as root.

Do following to create a mount point:

mkdir /media/codb2

Then edit /etc/fstab and add following line (assuming my partition is xfs):

/dev/codb2 /media/codb2 xfs defaults 0 0

Then mount it like usual.

mount /media/cobd2

Share via Samba

Give user1 the appropriate privilege. If you want to share a whole file system with user1, you must give read and write permissions.

After setting permission, add the following at the very end of /etc/samba/smb.conf

[my data]  path = /media/cobd2  valid users = user1  read only = no

Next add the user to the password’s database of samba:

smbpasswd -a user1

Then reload the samba

/etc/init.d/samba reload

On Windows, type \\192.168.37.20 and login as user1 using the password generated by smbpasswd.
Diposting oleh di Tidak ada komentar:

Selasa, 14 Januari 2014

Xathrya Sabertooth

Xathrya Sabertooth

Xathrya Sabertooth

Know the Concept: Desktop Environment and Window Manager

Posted: 14 Jan 2014 02:37 AM PST

In modern operating system, user interfaces tends goes to graphical system. We see window, we see button, we see cursor, etc. In UNIX, the graphical component is managed by independent subsystem. Here we hear two concepts: Desktop Environment and Window Manager. However, still some people confuse about which is which and which is best to use. The former question is fairly simple to answer. However the latter question is a bit more complex due to specific user want.

The Layering System

UNIX use layering system for its graphical desktop. Mostly the system comprised of following (from the base to the top):

  • The Foundation – A system that allows graphic element to be drawn on the display. This system builds the primitive framework that allows system to paint something to various screen (display), interacts with keyboard and mouse, etc. This is required for any graphical desktop. On most UNIX system, X Windows is used. There is also an alternative for X Windows, Wayland, which is still in active development.
  • Window Manager – The Window Manager is the piece of the puzzle that controls the placement and appearance of windows. Window Managers include: Enlightenment, Afterstep, FVWM, Fluxbox, IceWM, etc. This layer needs the foundation (X Windows) but not Desktop Environment.
  • Desktop Environment – This is where it begins to get a little fuzzy for some. A Desktop Environment includes a Window Manager but builds upon it. The Desktop Environment typically is a far more fully integrated system than a Window Manager. Requires both X Windows (Foundation) and a Window Manager. Examples: GNOME, KDE

So, a Desktop Environment generally includes a suite of application that are tightly integrated so that all applications are aware of one another. It is basically rides on top of a Window Manager and adds many features, including panels, status bars, drag-and-drop capabilities, and a suite of integrated applications and tools. Most user opinions on operating systems are typically based on Desktop Environment.

As implied by the name, Window Manager manages windows. Window Manager allows the windows to be opened, closed, resized, and moved. t is also capable of presenting menus and options to the user. It controls the look and feel of the user’s GUI.

The Type of Window Managers

Window managers are often divided into three or more classes, which describe how windows are drawn and updated.

Compositing Window Managers

Compositing window managers let all windows be created and drawn separately and then put together and displayed in various 2D and 3D environments. The most advanced compositing window managers allow for a great deal of variety in interface look and feel, and for the presence of advanced 2D and 3D visual effects.Example:

  1. Compiz
  2. KWin
  3. Xfwm
  4. Enlightenment (E17)
  5. Mutter.

Stacking Window Managers

All window managers that have overlapping windows and are not compositing window managers are stacking window managers, although it is possible that not all use the same methods. Stacking window managers allow windows to overlap by drawing background windows first, which is referred to as painter’s algorithm. Changes sometimes require that all windows be re-stacked or repainted, which usually involves redrawing every window. However, to bring a background window to the front usually only requires that one window be redrawn, since background windows may have bits of other windows painted over them, effectively erasing the areas that are covered.

Examples:

  1. AfterStep
  2. Blackbox
  3. Fluxbox
  4. FLWM
  5. sawfish
  6. Window Maker
  7. WindowLab

Tiling Window Manager

Tiling window managers paint all windows on-screen by placing them side by side or above and below each other, so that no window ever covers another.

Examples:

  1. wmii
  2. xmonad

Dynamic Window Manager

Dynamic window managers can dynamically switch between tiling or floating window layout. It is a tiling window manager where windows are tiled based on preset layouts between which the user can switch. Layouts typically have a master area and a slave area. The master area usually shows one window, but one can also change the amount of windows in this area. The point of it is to reserve more space for the more important window(s). The slave area shows the other windows.

Examples:

  1. fvwm
  2. xmonad

So Which One Suit Me?

Again, it is a tough question. Your choice might be affected by many factors: your need, your taste, your mood, etc. Unless you want to explore deep, you might consider default Desktop Environment and default Window Manager provided.

Separating CPP Template Declaration and Implementation

Posted: 14 Jan 2014 12:59 AM PST

Templates are a feature of the C++ programming language that allow function and classes to operate with generic types. This allows a function or class to work on many different data types without being rewritten for each one. The C++ Standard Library specify a special section for heavy use of template, called Standard Template Library.

Defining a template is like defining a blueprint. When we need a specific instance of function or class, the instance can be made from the generic blueprint. However, the common procedure in C++ which put the definition in a C++ header file and the implementation in a C++ source file can’t be applied to template. This is the behavior which is true for all compiler.

In this article we will discuss about how to separate declaration and implementation of template object (class / function). The article will be divided into three sections: how template is parsed, compilation issue, and the solution methods.

How Template is Parsed

Unlike other code, templates are parsed not only once, but twice. This process is explicitly defined in the C++ standard and although some compilers do ignore this, they are, in effect, non-compliant and may behave differently to what this article describes.

So what are those two processes? They are, let’s say, Point of Declaration (PoD) and Point of Instantiation (PoI).

1. Point of Declaration (PoD)

During the first parse, or Point of Declaration, the compiler checks the syntax of the template and match it with C++ grammar. This way, compiler does not consider the dependent types (the template parameters that form the templates types within the templates).

In real world, we can consider this phase as checking the grammar of a paragraph without checking the meaning of the words (the semantics). Grammatically the paragraph can be correct but the the arrangement of words may have no useful meaning. During the grammar checking phase, we don’t are about the meaning of the words. Our intention only toward the correct syntax.

Now, consider following template code:

template <typename T>  void foo (T const & t)  {      t.bar();  }

This is syntactically correct. However, at this point we have no idea what type the dependent type T is so we just assume that in all cases of T it is correct to call member bar() on it. Of course, if type T doesn’t have this member then we have a problem but until we know what type T is we don’t know if there is a problem so this code is ok for now.

2. Point of Instantiation (PoI)

At PoD we have declare a template, which we have the blueprint. The instantiation process start at Point of Instantiation. At this point we actually define a concrete type of our template. So consider these 2 concrete instantiations of the template defined above…

foo(1); // this will fail the 2nd pass because an int (1 is an int) does not have a member function called bar()  foo(b); // Assuming b has a member function called bar this instantiation is fine

It is perfectly legal to define a template that won’t be corrected under all circumstances of instantiation. Since code for a template is not generated unless it is instantiated the compiler won’t complain unless we try to instantiate it.

At this point, the semantics are now checked against the known dependent type to make sure that the generated code will be correct. To do this, the compiler must be able to see the full definition of template. If the definition of the template is defined in a different place where it is being instantiated the compiler has no way to perform this check. Thus, the template won’t be instantiated and an error message will be delivered.

Remember that compiler can only see and process one translation unit (module / source code) at a time. Now, if the template is only used in one translation unit and the template is defined in same translation unit, no problem rises.

Now let’s recap what we got so far. If the template definition is in translation unit A and we try to instantiate it in translation unit B the compiler won’t be able to instantiate the template because it can’t see the full definition so it will result in linker errors (undefined symbols). If everything is in one place then it will work. but it is not a good way to write templates.

Template Compilation-Issue

From the first section we know that between template definition should be visible and on the same translation unit with the instantiation. Thus, the following code works:

/** BigFile.cpp **/  #ifndef _FOO_HPP_  #define _FOO_HPP_    template<typename T>  class Foo {  public:     Foo() { }     void setValue (T obj_i) { }     T getValue () { return m_Obj; }    private:     T m_Obj;  }
Diposting oleh di Tidak ada komentar:
Langganan: Postingan (Atom)