Register
It is currently Mon Oct 23, 2017 12:22 am

Antix 16.2 64 bit


All times are UTC


Post new topic Reply to topic  [ 14 posts ] 
Author Message
 PostPosted: Sat Sep 23, 2017 12:24 am   
. . . .
User avatar

Joined: Mon Apr 21, 2003 3:56 pm
Posts: 8249
Antix 16.2 for AMD 64bit systems is working well right now. It did everything right. And that says a lot.

_________________
eMachines T5246 AMD 64 X2 w/Antix 16.2 for AMD64
EeePC 900A w/ Antix 16.2 32 bit
Dell Inspiron 1545 w/ Fedora something recent for 32 bit


Top
 Profile  
 PostPosted: Tue Sep 26, 2017 8:18 pm   
Linux Guru
User avatar

Joined: Sat Apr 03, 2004 12:39 am
Posts: 12268
Location: Clinton Township, Michigan
mmmna wrote:
Antix 16.2 for AMD 64bit systems is working well right now. It did everything right. And that says a lot.


I recently installed it and I had a similar experience. Glad it is working well right now for you too.

_________________
Brian Masinick
Distros: MX-16, antiX, Debian


Top
 Profile WWW YIM  
 PostPosted: Fri Oct 06, 2017 9:46 pm   
. . . .
User avatar

Joined: Mon Apr 21, 2003 3:56 pm
Posts: 8249
Well, lately in my life, there has been such a frustrating rash of 'failed configurations after installing successfully', this install simply shines.

I just cannot fathom how post installation configuration problems are not caught in beta testing. Unless ... unless everyone in whatever distro operates via continuous delivery of rolling releases, that is. In that case, it means the distro developers never test most portions of their distro installer scripts - because their own system software was initially configured correctly years ago, via a script which worked (back in the day), configuring those simpler binaries (back in the day).

I ran into my first 'rolling release' vs 'confirmed installer' issue well over a decade ago; my point being if you do not use the installer, you are presuming it works. If you want details of my issues, then just stop 'rolling' and do a bare metal install using your own installer. 2 to 10 developers, versus what could be 10's of thousands of installations that need installation assistance.

So when I say Antix is 'working well' (based on post installation operation), the reality is actually that Antix is really really what I expected from the first and every recent distro install.

_________________
eMachines T5246 AMD 64 X2 w/Antix 16.2 for AMD64
EeePC 900A w/ Antix 16.2 32 bit
Dell Inspiron 1545 w/ Fedora something recent for 32 bit


Top
 Profile  
 PostPosted: Mon Oct 09, 2017 2:42 pm   
Linux Guru
User avatar

Joined: Sat Apr 03, 2004 12:39 am
Posts: 12268
Location: Clinton Township, Michigan
@Mmmna: both the antiX and MX user communities (once based on MEPIS, but that's not been an active distribution for at least five years), have an active development and testing community. They don't invent a lot of new software, but occasionally they will create either a small application or a new interface to work effectively with the collection of software that their user community prefers.

When MEPIS went away, the antiX community picked up MX to replace it. MX switched from using KDE for a desktop environment to using Xfce. At the time, this was because KDE was moving to a different Plasma interface, and some were concerned about potential stability issues. Plasma, KDE, Trinity, etc. now have multiple interfaces, and the Qt libraries used by all of them now have "light" alternatives, plus KDE has been pretty solid. Still, Xfce is a more conservative, stable desktop environment that's been around as long as KDE (both started development in 1996).

MX-16 is the current Xfce-based release and work is going on for it's successor; meanwhile it's rock solid.

Similarly, antiX-16.2 is the stable version of the even lighter antiX release stream, and there is an antiX 17 nearly ready for release.

Both MX and antiX are well tested by their communities of interest, and rarely released with a lot of defects.

The antiX 17 release has been hampered by some issues that have arisen in Linux kernel development, but the good news is that the team has been working hard to make sure that either their own kernel is released to resolve any known issues, and if that can't be reasonably attained with a current vintage kernel, a "legacy kernel" that can still receive security updates will be available instead - and what that means to anyone who just wants to step in and use either of these distributions is that plenty of thought, testing, discussion, and issue resolution goes into the work.

In the case of antiX and MX, there is a bit of "revolt" as well - these are among the projects that REJECTED Debian's move into the systemd realm - they'll work with systemd, if you bring in Debian-based software that uses systemd, but they've worked hard to either build, continue to support, or otherwise develop non-systemd libraries and applications that work reliably, and they still do it with less system overhead than most of their peers.

I interact with a lot of the team members on both of the projects and I have a high regard for many of them, so I'm happy to hear that you appreciate the fine, well thought out work that many of them do. They don't write much core application software, as I mentioned, but they do a LOT of integration work to make sure that the software they select as the main command utility and user application providers work correctly together, and I think they do a solid job. Like anything else, feedback, suggestions, and testing is always appreciated. The more people available to test, the greater likelihood of an excellent end result.

_________________
Brian Masinick
Distros: MX-16, antiX, Debian


Top
 Profile WWW YIM  
 PostPosted: Thu Oct 12, 2017 10:46 pm   
. . . .
User avatar

Joined: Mon Apr 21, 2003 3:56 pm
Posts: 8249
masinick wrote:
...because KDE was moving to a different Plasma interface, and some were concerned about potential stability issues. Plasma, KDE, Trinity, etc. now have multiple interfaces, and the Qt libraries used by all of them now have "light" alternatives, plus KDE has been pretty solid. Still, Xfce is a more conservative, stable desktop environment that's been around as long as KDE (both started development in 1996).
Not sure how to say this, but as a user, the only light-ness I want involves cleanliness of and efficacy in the user experiences. Yes, I acknowledge there are developer frustrations, I really do, but when I think of how developers address developer oriented needs, usually with no user surveys, well, we have to think about the ratio of users to developers.

A silent push of mine, for the past decade or so, is for users to have accountable user input on the outcome of developer efforts, and to urge anyone who will listen, that user input should NOT need every user who has an opinion to sign up in a developer forum to argue, one on one with developers who are invested in a different outcome. That is the current methodology, and it makes little sense from a user perspective. After all, it is quite frustrating when a user has expectations on bigger stuff, such as KDE, and no clear way to communicate the expectations. Multiply that situation by the number of forums users might need to become active in when users want something other than what is being delivered. I've said years ago, there are tens of thousands of users, and for a given project, maybe a couple hundred developers. This OS wants users who are satisfied.... yes? This could go on, and for me, has been going on, but I've made my point here more clearly than ever before.

Masinick wrote:
In the case of antiX and MX, there is a bit of "revolt" as well - these are among the projects that REJECTED Debian's move into the systemd realm - they'll work with systemd, if you bring in Debian-based software that uses systemd, but they've worked hard to either build, continue to support, or otherwise develop non-systemd libraries and applications that work reliably,
...
Similarly, antiX-16.2 is the stable version of the even lighter antiX release stream, and there is an antiX 17 nearly ready for release.
I appreciate that. The sysinit process seems to help me experience a smoother boot process. Maybe I'm not grasping deeper details, but I am, after all, decidedly a Linux user.

Masinick wrote:
Both MX and antiX are well tested by their communities of interest, and rarely released with a lot of defects.
What your words say is that some distros are released with ... defects. I've been scolded for saying stuff like that!!

Masinick wrote:
The antiX 17 release has been hampered by some issues that have arisen in Linux kernel development, but the good news is that the team has been working hard to make sure that either their own kernel is released to resolve any known issues, and if that can't be reasonably attained with a current vintage kernel, a "legacy kernel" that can still receive security updates will be available instead
If I'm not mistaken, that methodology used to be the normal development process, before the concepts of scheduled release cycles arose. If development needs to respond using the older paradigm, I'm ok with that because the concerns are being addressed, not pushed aside because tomorrow is 'release day'.

Masinick wrote:
I interact with a lot of the team members on both of the projects and I have a high regard for many of them, so I'm happy to hear that you appreciate the fine, well thought out work that many of them do. They don't write much core application software, as I mentioned, but they do a LOT of integration work to make sure that the software they select as the main command utility and user application providers work correctly together, and I think they do a solid job. Like anything else, feedback, suggestions, and testing is always appreciated. The more people available to test, the greater likelihood of an excellent end result.
I believe you do interact with the upper levels, and you are continually interacting with me, wherever you find me, and that is all fine by me.

Antix is staying with my hardware for a bit.

_________________
eMachines T5246 AMD 64 X2 w/Antix 16.2 for AMD64
EeePC 900A w/ Antix 16.2 32 bit
Dell Inspiron 1545 w/ Fedora something recent for 32 bit


Top
 Profile  
 PostPosted: Fri Oct 13, 2017 1:50 pm   
Linux Guru
User avatar

Joined: Sat Apr 03, 2004 12:39 am
Posts: 12268
Location: Clinton Township, Michigan
@Mmmna, all of your comments are useful.

Regarding defects, yes, even test builds in the MEPIS - antiX - MX ecosystem have never been filled with defects, though the test versions might initially have a modest number of issues to fix, but what impressed me about all of them from the very beginning was even the very first builds were quite functional, even if not 100% perfect.

Back in the MEPIS days, I can remember only one build that didn't work right with my hardware. I sent in my hardware specs, explained what I was seeing that seemed to be blocking the system from working right, and the very next build fixed that issue, never to be seen again.

In the antiX stuff, sometimes there are problems; the more complicated the upstream code is, the more difficult it is to get everything 100% perfect. I will say this: the team that works with anticapitalista (Bitjam is particularly good; rokytnji and Skidoo are good helpers and testers, though many others are excellent contributors and helpers as well, which is great since it's not a very large community compared to Ubuntu, Red Hat/Fedora, or Debian. But since it also leverages a lot of code from Debian, replacing mostly the systemd-related software and explicitly including a relatively small subset of Debian utilities and packages, the antiX-based systems get the most out of Debian, particularly with respect to providing working, useful software that tends to be less defect prone than larger, more complex and buggy alternatives, and they're careful to choose things that conserve resources and still manage to do a good job.

To me that counts a lot, and even when I build my own Debian-based system, I tend to choose a large percentage of the same programs chosen by antiX and/or MX - a reason why I tweak with Debian less frequently (along with much less disposable time to test and experiment). Getting rid of the Red Hat-inspired systemd - though I've used it without incident on many other distributions, is still an added plus - to have something that's legacy, proven code that works effectively and efficiently. But the bottom lines are that:

1. The stuff works great:
a. Very few defects encountered in released software.
b. Very efficient use of resources.
c. Little effort needed to tune it or otherwise customize it to my specific needs, and GREAT tools for doing so on the occasions that I want to modify anything at all.

These things translate to a "no muss or fuss" solution that's fast, saving me interactive time (speed) when I use it and administrative time in low maintenance (reliability). Big wins as far as I am concerned, and very few other options are really that close.

For example, I do give Linux Mint high marks for being really simple and straightforward, and I recently installed it once again. The current version is as stable and solid as anything I've ever seen from them, so in that regard, Mint does very well. Some may give it higher marks for simplicity and ease of use, though the differences are modest. But even Mint doesn't compare in efficiency; to me it's bloated compared to any antiX or MX version. Beginners might prefer Mint; I'll stick with antiX and MX because of my specific needs - aging hardware needs efficient software; antiX wins. I could possibly tune Mint to be more efficient, matching antiX in some things, but that defeats the purpose and wastes my time. So that's my detailed explanation of why these are my favorite Debian-based systems (and at this point, even preferred to Debian because they save me time and effort).

_________________
Brian Masinick
Distros: MX-16, antiX, Debian


Top
 Profile WWW YIM  
 PostPosted: Sun Oct 15, 2017 10:07 pm   
. . . .
User avatar

Joined: Mon Apr 21, 2003 3:56 pm
Posts: 8249
Had an interesting scenario befall me while setting up the 32 bit version on the EeePC900A.

Elected to run apt on the command line to update the system. It seems as if I managed to select to install nearly everything in the repositories. 45 minutes later, the post install configuration was at over 95% done, and dummy me, I unintentionally closed the terminal window where the command line for the apt update was running. In my past, I did something like that, and that was a fatal blow. Ugh. How many packages got botched? Who cares, if I need to, I can just reinstall.

Decided to reboot to see the glorious extent of my damages. Antix (32 bit on the EeePC900A) booted, gave me graphical desktop and all. Huh. I opened a terminal, relaunched apt, and apt basically offered to pick up where I closed the earlier session. Knock me over with a feather! Sure, that speaks more to the power and ease of Debian, but still, it feels good when meltdowns don't come to pass. Other distros based on Debian seem to fail a lot more than I would expect, where Antix is showing strengths I'd not seen in years, simply by not crashing in those crashy settings.

I guess you could say I'm smitten?

_________________
eMachines T5246 AMD 64 X2 w/Antix 16.2 for AMD64
EeePC 900A w/ Antix 16.2 32 bit
Dell Inspiron 1545 w/ Fedora something recent for 32 bit


Top
 Profile  
 PostPosted: Mon Oct 16, 2017 2:36 am   
Linux Guru
User avatar

Joined: Sat May 01, 2004 2:37 pm
Posts: 3909
Location: AZ, USA
Were you using the newer apt tool, or the older apt-get?

The newer apt is supposed to deal with this type of thing MUCH better than the old apt-get, and has many features built into it from apt-get, apt-cache, etc. Still not 100% complete, but I personally use it almost exclusively when I'm doing something that it can handle. I've found it's very good at dealing with being confused, I've even successfully DOWNGRADED from sid to stable using apt!!!

_________________
Nightlund - AMD FX8320/16 G/960 SSD/GTX 760 2GB/Realtek 1 GB/Deb 9+W10
Excelsior - i7-6600U/32 GB/512 SSD/HD520/8265/Deb 9
Titan - i5-6440HQ/16G/1TB SSD/HD530/8265/Deb 9+W10
Wildmage - i5-5300U/16 G/1TB SSD/HD5500/8265/Arch
Defiant - i5-5200U/16G/256 SSD/HD5500/8260/Deb 10
Lichking - i5-5300U/8G/480 SSD/HD5500/8260/Deb 9
Dretch - i5-3380M/8G/480 SSD/HD4000/7260/Arch


Top
 Profile  
 PostPosted: Tue Oct 17, 2017 9:45 pm   
. . . .
User avatar

Joined: Mon Apr 21, 2003 3:56 pm
Posts: 8249
Apt. I had heard that apt-get was being deprecated, so I simply switched to plain 'apt'. Apt options are all but identical, so the switch is pretty painless.

_________________
eMachines T5246 AMD 64 X2 w/Antix 16.2 for AMD64
EeePC 900A w/ Antix 16.2 32 bit
Dell Inspiron 1545 w/ Fedora something recent for 32 bit


Top
 Profile  
 PostPosted: Wed Oct 18, 2017 1:00 pm   
Linux Guru
User avatar

Joined: Sat Apr 03, 2004 12:39 am
Posts: 12268
Location: Clinton Township, Michigan
mmmna wrote:
Apt. I had heard that apt-get was being deprecated, so I simply switched to plain 'apt'. Apt options are all but identical, so the switch is pretty painless.


Perhaps apt-get will be deprecated at some point in time, but the other alternatives, ranging from the low level dpkg, (which is likely to remain unless the entire infrastructure of packaging is replaced), along with aptitude, dselect (seldom seen these days).

Interestingly, on at least one page, aptitude and synaptic are the "recommended" tools to use:

Reference: https://wiki.debian.org/PackageManagement

Also, on https://www.debian.org/doc/manuals/debi ... de_literal -

"Although aptitude is a very nice interactive tool which the author mainly uses, you should know some cautionary facts:

The aptitude command is not recommended for the release-to-release system upgrade on the stable Debian system after the new release.

The use of "apt-get dist-upgrade" is recommended for it. See Bug #411280.

The aptitude command sometimes suggests mass package removals for the system upgrade on the testing or unstable Debian system.

This situation has frightened many system administrators. Don't panic.

This seems to be caused mostly by the version skew among packages depended or recommended by a meta-package such as gnome-core.

This can be resolved by selecting "Cancel pending actions" in the aptitude command menu, exiting aptitude, and using "apt-get dist-upgrade"."

Later, the same page states that:

"The aptitude command is the most versatile APT-based package management tool.

aptitude offers the fullscreen interactive text user interface.

aptitude offers the commandline user interface, too.

aptitude is most suitable for the daily interactive package management such as inspecting installed packages and searching available packages.

aptitude is more demanding on hardware resources. It consumes more memory and runs slower.

aptitude offers an enhanced regex based search on all of the package metadata.

aptitude can manage multiple versions of packages without using /etc/apt/preferences and it is quite intuitive."

Finally, if you read the long comments in the last reference shown, there are discussions, not only about the routine use of the basic commands, but also a lot of detailed information about working on an "unstable", cutting edge system with "Sid" - the "unstable" repository. For me, I've primarily used apt-get over the years and I'm careful NOT to upgrade anything other than routine packages immediately after a release or anytime there is a great deal of "volatile" activity taking place.

I'm not currently working with Debian Sid, though I do have one or two instances of Debian Sid on some of my old systems. Chances are high that if I upgrade any of them there is a significant risk of them breaking beyond repair. Still, it's quite the "educational exercise" to experiment with them and learn what can and cannot be repaired - as long as you have a "safe system" to go to SOMEWHERE else! :-)

_________________
Brian Masinick
Distros: MX-16, antiX, Debian


Top
 Profile WWW YIM  
 PostPosted: Wed Oct 18, 2017 2:41 pm   
Linux Guru
User avatar

Joined: Sat May 01, 2004 2:37 pm
Posts: 3909
Location: AZ, USA
I was burned by aptitude too many times in my linux "youth" to ever use it again.

One thing I like about apt vs. apt-get is that it has also deprecated the need for gdebi. You can now apt install <local file>.deb and it will install all the dependencies and such just like gdebi used to. Simple reason, but I have several software packages I have to install from .deb directly, and not having to install gdebi and all it's dependencies, and not having to use that 1 extra program saves me time.

_________________
Nightlund - AMD FX8320/16 G/960 SSD/GTX 760 2GB/Realtek 1 GB/Deb 9+W10
Excelsior - i7-6600U/32 GB/512 SSD/HD520/8265/Deb 9
Titan - i5-6440HQ/16G/1TB SSD/HD530/8265/Deb 9+W10
Wildmage - i5-5300U/16 G/1TB SSD/HD5500/8265/Arch
Defiant - i5-5200U/16G/256 SSD/HD5500/8260/Deb 10
Lichking - i5-5300U/8G/480 SSD/HD5500/8260/Deb 9
Dretch - i5-3380M/8G/480 SSD/HD4000/7260/Arch


Top
 Profile  
 PostPosted: Wed Oct 18, 2017 7:09 pm   
Linux Guru
User avatar

Joined: Sat Apr 03, 2004 12:39 am
Posts: 12268
Location: Clinton Township, Michigan
tlmiller wrote:
I was burned by aptitude too many times in my linux "youth" to ever use it again.

One thing I like about apt vs. apt-get is that it has also deprecated the need for gdebi. You can now apt install <local file>.deb and it will install all the dependencies and such just like gdebi used to. Simple reason, but I have several software packages I have to install from .deb directly, and not having to install gdebi and all it's dependencies, and not having to use that 1 extra program saves me time.


I wonder when the documentation will include this. The same Debian documentation that I was reading did acknowledge that some things may have changed by the time the document was finalized. Maybe in the next update of that documentation we'll see these kinds of details. Meanwhile, you obviously found this out from somewhere. Was there a document that you read to learn this, or did you find out by your own experimentation?

This article, while probably not an "official" comment, does appear to explain reasonably well what the 'apt' command, versus APT, the "Advanced Packaging Tool" is, and what the differences are between apt and apt-get. They are not the same and apt - at least in the foreseeable future, won't be completely replacing apt-get or dpkg, but for common use, apt can be used instead of apt-get, gdebi, or dpkg (though ultimately all of the packaging tools do invoke dpkg).

Here is the link to the article: Differences Between apt and apt-get Explained.

_________________
Brian Masinick
Distros: MX-16, antiX, Debian


Top
 Profile WWW YIM  
 PostPosted: Wed Oct 18, 2017 7:21 pm   
Linux Guru
User avatar

Joined: Sat May 01, 2004 2:37 pm
Posts: 3909
Location: AZ, USA
Most of the things I've found with apt have been through experimentation. I know Jessie's apt didn't have this ability yet, but with Stretch it does.

_________________
Nightlund - AMD FX8320/16 G/960 SSD/GTX 760 2GB/Realtek 1 GB/Deb 9+W10
Excelsior - i7-6600U/32 GB/512 SSD/HD520/8265/Deb 9
Titan - i5-6440HQ/16G/1TB SSD/HD530/8265/Deb 9+W10
Wildmage - i5-5300U/16 G/1TB SSD/HD5500/8265/Arch
Defiant - i5-5200U/16G/256 SSD/HD5500/8260/Deb 10
Lichking - i5-5300U/8G/480 SSD/HD5500/8260/Deb 9
Dretch - i5-3380M/8G/480 SSD/HD4000/7260/Arch


Top
 Profile  
 PostPosted: Wed Oct 18, 2017 10:49 pm   
Linux Guru
User avatar

Joined: Sat Apr 03, 2004 12:39 am
Posts: 12268
Location: Clinton Township, Michigan
Cool; I just did an apt full-upgrade and it worked fine. (Did it with MX-16).

Now I'm gonna grab the current Debian netinst with wireless support and see if I can get my Debian back!

_________________
Brian Masinick
Distros: MX-16, antiX, Debian


Top
 Profile WWW YIM  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron


Powered by phpBB © 2012 phpBB Group
© 2003 - 2012 USA LINUX USERS GROUP