@lockstep: The quality of this question does not fit the standard that a certain group of people expect. On the other hand, some other people like upvoting very basic question like this one. I don't know why? :-)
–
xportAug 2 '11 at 18:33

4

It's a somewhat "basic" question, but I might have asked it, too. And it attracted a lot of answers, so it was interesting.
–
lockstepAug 2 '11 at 22:03

8 Answers
8

TeX Live provides more secure defaults than MiKTeX and probably pays more attention to security in general. For example, section 3 of this paper describes a simple way to make document (or bibtex database, or package) viruses which would almost make MS-Word look as secure alternative ;-) This attack doesn't work with TeX Live's default settings, regardless of the platform (Windows or other).

Not completely unrelated, TeX Live is designed to support multi-user systems, including being installed on a servers and used on network clients, possibly with mixed architectures and OSes. (Which may be totally irrelevant to the OP, but mentioned only for information.)

My impression is that Christian pays attention to security. E.g. since last year (I think triggered by the paper you mentioned) you can't write to parent directories anymore (which breaks some documents as \include's didn't work).
–
Ulrike FischerJun 11 '11 at 10:52

1

I disagree with this statement. By default, MiKTeX is installed to the folder C:\Program File wich is securedby Windows with special care. TeX Live is installed into a separate forlder outside C:\Program File.
–
Igor KotelnikovOct 22 '11 at 11:32

@PaulGaborit Write access to C:\Program Files is only granted to administrators - regular users do not have write access. If users use an admin account or disable UAC the problem is the user, not the OS which tries to protect important OS files.
–
DetlevCMApr 11 '13 at 8:57

I've covered some of this before on my blog, so some of this is a rehash! In recent versions, the differences between MiKTeX and TeX Live have narrowed. Package coverage between the two is similar, as is the ability to do on-line updates. I guess here you want differences:

Only MiKTeX can do 'on the fly' package installation, as TeX Live is more focussed on
having a system that works well on multi-user systems.

TeX Live tends to have slightly more up to date binaries, particularly for LuaTeX.
This is in part due to having a 'team' rather than a single developer.

TeX Live has a richer set of command line tools than MiKTeX.

TeX Live defaults to installing everything, which means that if you want everything
it's easier to use TeX Live than MiKTeX.

@Jasper: Last time I did it, you had to do the basic install first then do a second 'cycle' to install everything. The update wizard also did not pick up new packages as part of an 'update': I had to again select those separately. I've not use MiKTeX 2.9, so that may have altered.
–
Joseph Wright♦Jun 6 '11 at 13:50

12

You can install everything in miktex and then you will get the newest versions. But you can also do a "basic installation". In this case you should run an update afterward. I'm always doing a basic installation, then import additional packages from a previous miktex version on my PC, and then run an update. That has the benefit that I have to download much less and that it limits updates to the packages I'm really using.
–
Ulrike FischerJun 6 '11 at 14:48

@Ulrike: As I've tried to indicate, whether you want a full install or not is probably dependent on your circumstances. It makes sense for a network system with varying demands, or indeed for a developer who might be asked about anything!
–
Joseph Wright♦Jun 6 '11 at 14:52

1

@Joseph Wright It's a click of a button, and MiKTeX installs everything. It's faster to get the setup and the packages separately (using a FTP client), instead of getting the basic installer. And not to download packages by the package manager itself.
–
Karl KarlssonJun 7 '11 at 15:46

maintained by TUG, that is, by more
than one person, which makes it more
future-save

support of many platforms, not just Windows. (The first paragraph of http://www.ctan.org/starter.html needs an update.) I am interested in Linux-x86 and Windows, so I made a portable installation covering both platforms on an external hard disk.

real-time updates of packages: once updated and propagated to the mirrors overnight, new package versions are available in the package manager (tlmgr)

faster compilation (esp. in case of
graphics files)

EDIT:
As for speed (4.), I measured compilation times of the animate package documentation which embeds about 260 Metapost graphics files and a few (3) small bitmaps. I used the Windows Powershell command measure-command {<programm> <prog args>} for the time measurements. I tested TeXLive2010 and MiKTeX-2.8 (the latest version I used before leaving for TeXLive) on a Pentium-4@2.6 Ghz.

@point 3. MiKTeX also has package manager and regularly updates packages. I don't think there is any major difference in this regard.
–
TomekJun 6 '11 at 13:46

2

@point 4. MiKTeX is mostly based on the same code as TeX Live (sans package management). I would be very surprised to see any major differences in compilation speed on similarly configured systems.
–
TomekJun 6 '11 at 13:49

2

@jasper, @tomek. The average package update interval of MiKTeX is about once per week.
–
AlexGJun 6 '11 at 14:01

1

@Karl: See my edit regarding (4). (2) I don't care about GUI guidelines. tlmgr update --all from time to time is enough. If I depended on GUI's I'd use Word. (1) I only compared both.
–
AlexGJun 8 '11 at 8:29

2

@Alexander Grahn Well, measuring is where the science begins. But benchmarking is a non trivial task. A) Disk fragmentation, B) Memory caching and C) Most time consuming task. So, A) MiKTeX files may be more (heavily) fragmented, they even may be on the slowest part of the drive. B) If you all day used TeXLive, than it's files are cached in the memory, and then running MiKTeX which files are not cached. C) If the most time consuming task is Metapost, well, who uses Metapost that much? It's just an example out of the real world.
–
Karl KarlssonJun 8 '11 at 21:34

Regarding 5. The number of command line tools may be comparable, but a lot of them are Perl scripts and these run in TeX Live "out of the box", because it ships with hidden Perl interpreter, but for MiKTeX you need to install Perl separately.
–
TomekJun 6 '11 at 13:00

1

@Joseph: I think kpsewhich in MiKTeX 2.9 is now compatible with the one in TeX Live (but this certainly wasn't the case in the past).
–
TomekJun 6 '11 at 13:02

3

Regarding 3. MikTeX claims to accept only FSF-and-Debian-Free materiel on its licensing page, which is quite precisely the licencing policy of TeX Live (which follows FSF rather than Debian when the two diverge, btw). But apparently this common policy is not enforced as actively or as strictly in MikTeX as in TeX Live.
–
mpgJun 6 '11 at 21:14

1

@Joseph I think kpsewhich is a very special case, since it is related to Kpathsea, a library specific to TeX Live's implementation of TeX & friends, known as web2c. So it's really a nice compatibility effort from MikTeX to provide a kpsewhich command at all. In the opposite direction, TeX Live does not provide a findtexmf command (the MikTeX command-line tool for file searching).
–
mpgJun 6 '11 at 21:22

@Jasper Loy: Yes, but it's more like a DIY recipe on how to make it yourself. While MiKTeX Portable runs out of the box not requiring anything from the user. And MiKTeX Portable (non full install) is a lot smaller. While TeXLive allows only a full install.
–
Karl KarlssonJun 10 '11 at 9:10

@xport: I'm not sure where you get (2) from. TeX Live automatically includes a localtexmf tree, %USERPROFILE%\texmf, whereas with MiKTeX I've always had to add an additional root.
–
Joseph Wright♦Jun 10 '11 at 13:30

2

@Joseph Wright: Suppose migration or restoration of the operating system is needed. If localtexmf tree is on the system partition, that requires backup and restore operations. But if, like MiKTeX allows, it's placed on another partition you can do whatever you want with the system partition. Even you can format it, fully erase it - the localtexmf tree remains untouched.
–
Karl KarlssonJun 14 '11 at 10:58

I wonder why TeX Live distribution is so huge? It is 2 times bigger than MiKTeX (2.3 Gb vs. 1.2Gb). And I would't say that that is TeX Live's advantage. First thing I met after installation of TeX Live was that it misses floatflt package. So I was forced to copy floatflt.sty from MiKTeX.

MiKTeX has base mode of installation which provides reasonable point to start. All other required packages can be automatically installed on-fly. As of TeX Live, I wonder why one need to install, say, documentations on all supported languages?

As of absence of command line tools in MiKTeX, it is matter of philosophy. As to me, I don't want to learn names of such tools and prefer to have single centralized manager. Difference in philosophy is visible in number of various buttons, say, in DVI viewer. YAP viewer from MiKTeX follows minimalist design whereas DVI viewer from TeX Live collection has lot of buttons which I never used.

I would also say that MiKTeX Package Manager is more friendly although it is slower at the stage when it loads packages data base.

And final point in favour of MikTeX. I did not find on-fly package installer mode in TeX Live which exist in MiKTeX and very useful.

We don't need to specify -sPAPERSIZE=a4 option/switch for TeX Live ps2pdf when using A4 paper. But the option/switch is absolutely needed in Miktex unless you want the top margin to get cropped. For other paper sizes, both MikTeX and TeX Live allow you to omit this option/switch.

Well I don't need it. I get a a4 paper without any switches. On the other hand with the default settings I don't get letter paper format. But the "culprit" is not ps2pdf but config.ps of dvips. It works if I change the settings for the letter page size in config.ps. You can find informations about config.ps in testflow_doc.pdf (on CTAN).
–
Ulrike FischerJun 10 '11 at 9:41

Btw, I had the exact same problem with older versions of TL. But I think it works by default now, indeed.
–
mpgJun 10 '11 at 16:46

I wouldn't replace it but put the new (local) config.ps in a local texmf tree. Apart from this: I pointed you to a document which contains informations about config.ps. The documentation of dvips exists too. config.ps is a textfile so you can open it in your editor and check its content. Use this informations.
–
Ulrike FischerJun 14 '11 at 7:48