Make USB storage as a GRUB bootable device

I normally have multiple operating systems on my machine. I thought I'd remove my old Ubuntu installation and use the partitions for other purposes. I knew I'd have GRUB issues, but thought it'd be relatively easy to find how to make a bootable USB pendrive. But, I was wrong!

Seems like most installers use syslinux based boot loaders and grub kicks in later. So, getting hold off one wasn't easy. After searching and reading, I found some useful information (I'm missing exact links though :( ). But here's the brief steps to get a plain grub bootable device.

(This is assuming you have access to some other Linux/GRUB based system)

Assuming /dev/sdb1 is your usb (FAT32 or otherwise) device - BE CAREFUL TO PICK THE RIGHT DEVICE!

[ Run as root / sudo as required ]

[ Mount the device ]
$ mount /dev/sdb1 /media

[ Create folders ]
$ mkdir -p /media/boot/grub

[ Next copy stage1, stage2 files ]
$ cp /boot/grub/stage* /media/boot/grub/

[ Start grub ]
$ grub

[ Change grub root device - normally hd0 => sda and hd1 => sdb and so on...again be careful! ]
grub> root (hd1, 0)

[ Setup as boot device ]
grub> setup (hd1)

....some messages, statuses, warnings, etc...

[ Quit ]
grub> quit

It should be a bootable device now and should give the grub boot prompt...you can use that to boot Windows e.g.
[ Again, use the correct number - it depends on your boot order ]
rootnoverify (hd1,0)
chainloader +1
boot

Ultimate PDF Converter (on Cloud)

Introduction

I wrote an android app and related server scripts for converting documents to pdf for viewing on the phone. The app can be downloaded here.
I wrote this for a few reasons including experimenting with AdMob, so caution: the app is an adware.

I have cleaned up the sources and uploaded it to google code.
The server scripts can be found here
and the android application can be found here

Some Technical Details

The flow is normally like the following:

1. Android Application sends the file to the server using the upload.php script
2. upload.php generates a unique key for this file and passes on the information to the app as well as updates the database
3. The python converter polls this database and calls the converters (libreoffice/openoffice) and updates the database with success/failure
4. The app now queries the getfile.php to get the file or the queue number it is in.
5. The file (converted pdf file) is then downloaded to /sdcard

TODOs

1. Change the irritating 'open with' to may be 'share with' rather
2. Conversion of pdfs into maybe images for directly viewing from the app rather than opening it with another pdf viewer.
3. Conversion of other files: e.g. audio files into wave screenshots or something (?)
4. Robustness of the scripts and app needs improvement

Any contributors, please?

The so called Hidden Features of LibreOffice 3.3

There are quite a few non-noticeable features in LibreOffice 3.3.x. I thought of sharing a few here...

Batch conversion
Especially useful when you want to work with command line or invoke conversion from another program or convert set of files to a given format (batch process).

Equivalent commands: oocalc (and its set), localc (and its set), soffice.bin
Assuming the current working directory is the libreoffice installation directory

The following command would convert all the *.doc files to *.pdf files
./soffice.bin -convert-to pdf:writer_pdf_Export -outdir /home/user/output /inputfiles/*.doc

[PS: wildcards wouldn't work correctly on windows specify the file names (list) instead.]

Forcing input filter while opening via command line
Whenever we open a file using the command line, we wouldn't generally have a choice to select the input file type (e.g. xlsx MSO 2007 or xlsx MSO 2010 or anyother). We would be at the mercy of the program to auto detect correctly. Use the following option to force opening the file with a given filter.
./soffice.bin -infilter="Calc Office Open XML" file.xlsx

Combining the above two
oh well...I guess by now it should be easy ;)

References
./soffice.bin -help
List of output filters: http://opengrok.libreoffice.org/xref/filters/filter/source/config/fragments/fcfg_writer.mk
List of input filters: Search with the above example filter or http://opengrok.libreoffice.org/search?q=PreferredFilter&project=filters

Watch out for more such features...

BSD, Linux, OpenSolaris Filesystem Encryption - FSE

Similar to my DVD Catalog project ( :) ), I have been searching for a good (transparent) filesystem encryption for my open source operating system(s).

ZFS is a very good option but the encryption module is currently in beta. (And ofcourse, with the usual license problems)


So, I am planning to write a transparent filesystem encryption module for using with any exisiting filesystems and OSes (Unix-based).

== The Design ==

User view:
The user mounts a harddrive (say, /dev/sda1) as an encrypted drive (say, /dev/esda1). And will use any of the exisiting filesystems to format and mount this /dev/esda1 onto a mount-point.


Developer's view:

The module reads/writes from the actual harddrive (or another loopback FS) by encrypting/decrypting the data. For data I/O the module exports a device, say, /dev/esda1. Which is emulated as a harddisk for the existing filesystem modules.


This would be very similar to a loop-back filesystem with encrpytion.



== But, Before I start ==
Unlike DVD Catalog project, I would like to get options and opinions before starting this project.

1) Are there any exisiting projects like this or very similar to this?
2) Are there any other alternatives/file systems?
3) Are there any other better designs?

Linux and GPL...Move to OpenSolaris, FreeBSD and/or OpenBSD?

I know this topic is discussed over and over again. [But clarifications and hence a kind-of detailed reasons listed on (say) kernel.org would be helpful, I think.] Anyways,

I read
http://www.kernel.org/pub/linux/docs/lkml/#s1-19
(note: The link to the message wasn't working - I am guessing its the normal licensing.txt or might be this)
and
http://kerneltrap.org/Linux/NDISwrapper_and_the_GPL


I have a lot of confusions over the reasons for why a GPLONLY API needs to be there. Use of GPLONLY define implies some kind of differentiation between kernel modules which are GPL and "other"licenses.

[Just for the sake of argument, what prevents the same kind
of extension (of differentiation) to GPL programs/applications
and other programs?]

Linus, himself says it is not good to prevent non-GPL driver code in Linux. There is a nice argument here, here and of course here.

I think you really just disagree on what is derived, and what is not.
Richard is very extreme: _anything_ that links is derived, regardless of
what the arguments against it are. I'm less extreme, and I bet you're even
less so (at least you might like to argue so).

I liked this argument of Linus,

The silly thing is, the people who tend to push most for this are the
exact SAME people who say that the RIAA etc should not be able to tell
people what to do with the music copyrights that they own, and that the
DMCA is bad because it puts technical limits over the rights expressly
granted by copyright law.

Doesn't anybody else see that as being hypocritical?

So it's ok when we do it, but bad when other people do it? Somehow I'm not
surprised, but I still think it's sad how you guys are showing a marked
two-facedness about this.

This is exactly what I feel about GPLONLY symbols too.

If Linus was convinced by his fellow-team-mates (so called) to add such a define, why shouldn't some one convince him to make GPLONLY system calls for user space programs as well? The reason given in the FAQ is:

To allow choice for developers who wish, for their own reasons, to contribute code which cannot be used by proprietary modules. Just as a developer has the right to distribute code under a proprietary licence, so too may a developer distribute code under an anti-proprietary licence (i.e. strict GPL).

Choice?


Many people, including me, like freedom without any frills. GPL license adds too many frills to it. GPL (as an extreme example) is like saying: take these seeds (for free) do what ever you want with it, but if you grow a tree using it (with whatever hard work it might take) you need to give it back to others (for whatever reason they might need it for) - for free, as in freedom, of course.


Whatever it (the reasons) might be, what's the guarantee that, the so called exceptions (like the one that allows non-GPL code running in user space) be taken out by our Linux kernel friends? Or for that matter limited to a few legacy APIs only?
What is the guarantee that GPLONLY define will not be put all over the kernel? Maybe that's the idea...

Unless a standardized API (for drivers i.e.) is published and maintained (20yrs of kernel developement and not a hint towards it), there probably is no guarantee...We just have to hope (and pray), Linus is not hijacked!
Note: I am not saying it should never change, but it should be more or less standard across minor version changes. And if it can be done with GPL drivers (not extenstion of the kernel) then it should be possible with non-GPL drivers.

At least wrappers, like the one use by nVidia drivers, will go away.


Because of all the above reasons (and more), I am seriously contemplating on moving to OpenSolaris, FreeBSD and/or OpenBSD.

I have already registered for a free CD of OpenSolaris and will be downloading FreeBSD and OpenBSD. Read on for updates on my experiences with those...

-----

In comparison to GPL, LGPL is far better, BSD licenses are too weak (but in some sense the best), do we have something in between? Can't I ask for both pista as well as strawberry milkshakes? Is that the reason why I like cassata ice creams?


PS: I am not anti-GPL.