Now Debian Jessie is now stable, users *might* want to upgrade antiX-13.2 to jessie.

Only do so at your own risk! If it breaks, you get to pick up the pieces!

I did this on a fresh install of antiX-13.2 in Virtualbox. (YMMV if you have installed apps outside of the denia, antiX repos.

1. Simply change the wheezy repos to jessie in etc/apt/sources.d/debian.list
2. apt-get update && apt-get dist-upgrade
3. READ the output. If it wants to rip out half of your install, press n(no)
4. If you agree, then you will get a warning about the antiX repos and keys. Don't worry, this is normal and press Yes.
5. Once everything is upgraded, you might wish to install a newer kernel. Have a look in synaptic.
4.00 is the latest for antiX.
5. You might want to switch from grub-legacy to grub2. To do so, apt-get install grub-pc and follow the instructions. Then do an update-grub.

This will NOT upgrade antiX-13.2 to antiX-15 in the sense that you will be using the desktop-session features we now use in antiX-15. However, you should be able to do so at a later date, once antiX-15 has been released.

NOTE: antiX-13.2 upgraded to jessie uses more RAM (at least on my box). It went from 55-70MB in a VBox environment.

Only do so at your own risk! If it breaks, you get to pick up the pieces!

Yes indeed! If you use the AMD graphics drivers then don't do this, or else be prepared to switch to Radeon, or to downgrade Xorg.

anticapitalista wrote:Now Debian Jessie is now stable, users *might* want to upgrade antiX-13.2 to jessie.

Only do so at your own risk! If it breaks, you get to pick up the pieces!
...
NOTE: antiX-13.2 upgraded to jessie uses more RAM (at least on my box). It went from 55-70MB in a VBox environment.

Isn't this always the case? With only a few exceptions, newer stuff has more features and therefore consumes more disk, more memory, and often more CPU.

Distributions like antiX and Puppy do so to a lesser degree than most of their peers, but both are extremely larger in consumption than either of them were in 2006 nearly a decade ago. __{{emoticon}}__

RedHat 5.0 base install was 50Mb - no idea what it is today, as I went with Debian from then onward. __{{emoticon}}__

fatmac wrote:RedHat 5.0 base install was 50Mb - no idea what it is today, as I went with Debian from then onward. __{{emoticon}}__

Just a few years after those early Red Hat releases, they would have several CDs for a distribution and they've used DVDs and other media for many years now. Suffice it to say that the default setup is probably a couple of GB, and if you install everything it is probably several GB; 50 GB is smaller than the first antiX that I can remember; the early antiX releases were in the 100-200 MB range if I remember correctly - from back around 2006.

The 2003 edition of MEPIS - BEFORE Warren moved to"SimplyMEPIS" and the use of KDE, I think a May 2003 prototype using a light window manager was only a couple hundred MB compared to the 1.5 GB or so for the last couple of releases before MX-14, which cut it back down.

I hacked an installation; on mine I ended up with systemd in my MX-14 configuration. I also must have said Yes too many times; I ended up with a LightDM devoid of anti goodies. No biggie; I can either program them back or simply wait until we have a release update. For the most part, it worked.

masinick wrote:I hacked an installation; on mine I ended up with systemd in my MX-14 configuration. I also must have said Yes too many times; I ended up with a LightDM devoid of anti goodies. No biggie; I can either program them back or simply wait until we have a release update. For the most part, it worked.

The biggest consequence of using systemd in place of sysvinit is that start up and shut down work differently, so the routines that are provided by the system will only work if you either change them to match the scheduling system you implement, run the commands for the system you've chosen manually, alter the MX or antiX scripts, or tolerate errors and failures that do not take any changes you've made.

I can live with those differences; at the end of the day they are minor to me because I can always directly call whatever tools and procedures are used by the subsystem that I'm working with - and if I choose, I can quickly create either alias definitions or short scripts to perform these tasks.