Forum › Forums › Orphaned Posts › antiX-17 “Heather Heyer, Helen Keller” › antiX-17.5 needed?
- This topic has 26 replies, 10 voices, and was last updated Oct 29-12:59 am by BobC.
-
AuthorPosts
-
September 21, 2020 at 2:44 pm #42059Forum Admin
anticapitalista
I was thinking of updating the antiX-17 series to include all latest updates since release because …
1. it shows we still support this release and are prepared to build and upload new iso files for those that cannot use antiX-19 (Does any other distro do this?)
2. anyone downloading and installing the latest version (antiX-17.4.1) to keep it up to date will need to also download ‘298MB of archives’If I do this, should I add some new features/apps that were not on antiX-17 but do appear in antiX-19 eg chroot-rescue, live grub rescue options, isomount options, various yad additions provided by community members eg yad-calendar, various IceWM additions provided by community members eg icewm-toolbar-icon-manager.sh, updated linux-nonfree firmware
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
September 21, 2020 at 3:01 pm #42060Member
oops
::I do not know if it is needed or not, but a VLTS, Very Long Time Support is a good concept.
New versions based to runit too.September 21, 2020 at 3:08 pm #42061Anonymous
::I agree reasons 1 & 2 have merit and can’t think of any contra reasons.
Other distros? FatDog64 “kinda sorta” (mostly unnannounced) has done this across the 702, 710, 720 series.
It might help to understand what I’m describing by scrolling to bottom of page here, and read bottom upward:
https://distro.ibiblio.org/fatdog/web/history.html
.
Also, and again, informally… I reckon we can say that TinyCore has maintained open-ended support for CorePlusSeptember 21, 2020 at 5:10 pm #42063Forum Admin
Dave
::The reasoning for points 1+2 seem sound to me.
However adding updates that are in antiX 19 to the 17 point release confuses me. If you were looking for the newer items why not install version 19 instead? There has to be a reason to stay with version 17? The new features/apps may or may not be part of the reason…Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown
September 21, 2020 at 6:35 pm #42069Moderator
Brian Masinick
::I was thinking of updating the antiX-17 series to include all latest updates since release because …
1. it shows we still support this release and are prepared to build and upload new iso files for those that cannot use antiX-19 (Does any other distro do this?)
2. anyone downloading and installing the latest version (antiX-17.4.1) to keep it up to date will need to also download ‘298MB of archives’If I do this, should I add some new features/apps that were not on antiX-17 but do appear in antiX-19 eg chroot-rescue, live grub rescue options, isomount options, various yad additions provided by community members eg yad-calendar, various IceWM additions provided by community members eg icewm-toolbar-icon-manager.sh, updated linux-nonfree firmware
I am completely in support of this! Though I also support and love antiX 19.2.1 (I have my own customized Base and runit versions installed, out of ALL of the numbered antiX releases, the very first one has “emotional appeal” and 17.4.1 simply had a great ambiance, or appeal.
If we do this, I’d UP my number of INSTALLED antiX instances from 2 to 3; I also have scads of CD, DVDs (Though I did “shed” some of them when I retired and moved into a smaller home), and the latest thing that I frequently use (instead of the Live CDs) are various USB versions:
1. Snapshots, 2. Frugal, 3. Persistence images. Depending on where I am and what I am doing, there’s rarely a day, unless I am not on the computer at all, that antiX doesn’t get use in some way.Add me to the list of 17.4.1 enthusiasts in case I was not automatically added 😉
--
Brian MasinickSeptember 21, 2020 at 11:34 pm #42077Forum Admin
rokytnji
::Shucks. Get asked that after
harry@antix1:~ $ inxi -b -r System: Host: antix1 Kernel: 3.16.0-4-686-pae i686 bits: 32 Desktop: IceWM 1.8.3 Distro: antiX-15-beta1-V_386-full Killah P 16 March 2015 Machine: Type: Laptop System: Intel product: Intel powered classmate PC v: 3rd Gen serial: <root required> Mobo: QCI model: Intel powered classmate PC v: 3rd Gen serial: <root required> BIOS: Phoenix v: HP94510A.86A.0035.2009.0427.2020 date: 04/27/2009 Battery: ID-1: BAT0 charge: 46.6 Wh condition: 52.9/52.9 Wh (100%) CPU: Single Core: Intel Atom N270 type: MT speed: 800 MHz min/max: 800/1600 MHz Graphics: Device-1: Intel Mobile 945GSE Express Integrated Graphics driver: i915 v: kernel Display: x11 server: X.Org 1.20.4 driver: intel unloaded: fbdev,modesetting,vesa resolution: 1024x600~60Hz OpenGL: renderer: Mesa DRI Intel 945GME x86/MMX/SSE2 v: 1.4 Mesa 18.3.6 Network: Device-1: Realtek RTL8101/2/6E PCI Express Fast/Gigabit Ethernet driver: r8169 Device-2: Ralink RT2870/RT3070 Wireless Adapter type: USB driver: rt2800usb Drives: Local Storage: total: 55.89 GiB used: 12.90 GiB (23.1%) Repos: No active apt repos in: /etc/apt/sources.list Active apt repos in: /etc/apt/sources.list.d/antix.list 1: deb http://la.mxrepo.com/antix/buster buster main nonfree nosystemd Active apt repos in: /etc/apt/sources.list.d/buster-backports.list 1: deb http://deb.debian.org/debian buster-backports main contrib non-free Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 1: deb http://ftp.us.debian.org/debian/ buster-updates main contrib non-free Active apt repos in: /etc/apt/sources.list.d/debian.list 1: deb http://ftp.gr.debian.org/debian/ buster main contrib non-free 2: deb http://security.debian.org/ buster/updates main contrib non-free No active apt repos in: /etc/apt/sources.list.d/onion.list No active apt repos in: /etc/apt/sources.list.d/various.list Info: Processes: 119 Uptime: 23m Memory: 1.97 GiB used: 687.0 MiB (34.1%) Shell: bash inxi: 3.0.36 harry@antix1:~ $Went through hours of dist-upgrade, fix keyrings, move /etc/apt/sources.list.d folder from live run to this netbook beta install.
harry@antix1:~ $ sudo apt-get update Hit:1 http://security.debian.org buster/updates InRelease Hit:2 http://deb.debian.org/debian buster-backports InRelease Hit:3 http://ftp.us.debian.org/debian buster-updates InRelease Hit:4 http://la.mxrepo.com/antix/buster buster InRelease Hit:5 http://ftp.gr.debian.org/debian buster InRelease Reading package lists... Done harry@antix1:~ $ sudo apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages have been kept back: syslinux syslinux-common 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded. harry@antix1:~ $ sudo apt-get -f install Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded. harry@antix1:~ $Still uses wicd, my startup sounds stuck in place, My icewm still has quick launch bar. Roxterm stayed in place. Only slim login screen changed.
Dug this out of mothballs to install 19
Decided if dist-upgrade with a repo change went wrong. I could salvage with live cd run and reinstall 19.
But success. On reboot. This is long in the tooth install . Dist-upgrade took 3 stages because I accept package maintainers version. Which changed part of my sources.loist.d file contents.So. Tired now cuz this slow atom netbook has it’s own speed.
So I will come back later to give my 2 cents on this subject.
Head is too cloudy right now.Sometimes I drive a crooked road to get my mind straight.
Not all who Wander are Lost.
I'm not outa place. I'm from outer space.Linux Registered User # 475019
How to Search for AntiX solutions to your problemsSeptember 22, 2020 at 2:22 am #42080Forum AdminSamK
::2. anyone downloading and installing the latest version (antiX-17.4.1) to keep it up to date will need to also download ‘298MB of archives’
Eliminating the need for such large updates is a good idea.
I would like to see all antiX-Full ISOs be treated in that way during the supported cycle period. Up to now the previous ISO release has not been updated at all, and the current release ISO is updated approximately once each year. Workload permitting more frequent updates will be good to have.
1. it shows we still support this release and are prepared to build and upload new iso files for those that cannot use antiX-19
Systems that cannot use the current version of antiX are likely to be older machines. For that type of kit there is little to be gained by having the latest kernel that supports the most recent hardware. I think it would be valuable to have a security patched, antiX-Legacy-kernel shipped within the updated ISO of the previous antiX release.
…should I add some new features/apps that were not on antiX-17 but do appear in antiX-19…
Doing this is potentially inviting trouble without having in place some new practices and methods.
Underlying packages can be different versions (offering different functionality) between antiX releases. This can, and does, break scripts that work on the current release but not on the previous release. Doing this type of backward transfer will certainly require an unwelcome increase in workload to test and fix. It might also potentially attract dissatisfied comments from users reporting broken software. It is probably better to avoid such circumstances entirely.
September 24, 2020 at 7:41 am #42167Forum Admin
rokytnji
::Coming back to this. I see no negatives other then keeping up with updates included with releases as time moves on.
After doing 3 dist-upgrades in one session with 1700 packages and staring at small screen intently for any error readouts or pay attention to me installs
I am for anything keeping me from walking that walk again. So I am for it. Kinda cool to get new features. Also.
Doing this is potentially inviting trouble without having in place some new practices and methods.
Underlying packages can be different versions (offering different functionality) between antiX releases. This can, and does, break scripts that work on the current release but not on the previous release. Doing this type of backward transfer will certainly require an unwelcome increase in workload to test and fix. It might also potentially attract dissatisfied comments from users reporting broken software. It is probably better to avoid such circumstances entirely.
I know what he means. After my dist-upgrade from 15 to 19. Lost the edit icewm button in antix control center > Desktop area.
This is not a major deal for me. Though.Sometimes I drive a crooked road to get my mind straight.
Not all who Wander are Lost.
I'm not outa place. I'm from outer space.Linux Registered User # 475019
How to Search for AntiX solutions to your problemsSeptember 24, 2020 at 7:44 am #42168Moderator
Brian Masinick
::Coming back to this. I see no negatives other then keeping up with updates included with releases as time moves on.
After doing 3 dist-upgrades in one session with 1700 packages and staring at small screen intently for any error readouts or pay attention to me installs
I am for anything keeping me from walking that walk again. So I am for it. Kinda cool to get new features. Also.
Good work Roki! Thanks for your efforts!
--
Brian MasinickSeptember 26, 2020 at 12:03 am #42233ModeratorBobC
::Maybe periodically updated respins are the right answer. Like Manjaro “community versions”.
They would not be supported completely (ie don’t rate or fault antiX for issues), but at least there for those who need it to use, and if it being used by many and has a reasonably fixable problem, then work on it. The main emphasis would be to install newer important packages as long as they don’t break basic functionality.
The biggest reason I’ve seen to use the older releases are video cards that are no longer supported by current Xorg versions, and on older hardware, that really is a problem, because the people running those machines might also not be able to afford to upgrade the video card or system itself. Eventually, at some point all 32 bit machines will have that problem when Debian drops 32 bit support as well.
Just thinking aloud…
September 26, 2020 at 11:06 am #42250Moderator
Brian Masinick
::Maybe periodically updated respins are the right answer. Like Manjaro “community versions”.
They would not be supported completely (ie don’t rate or fault antiX for issues), but at least there for those who need it to use, and if it being used by many and has a reasonably fixable problem, then work on it. The main emphasis would be to install newer important packages as long as they don’t break basic functionality.
The biggest reason I’ve seen to use the older releases are video cards that are no longer supported by current Xorg versions, and on older hardware, that really is a problem, because the people running those machines might also not be able to afford to upgrade the video card or system itself. Eventually, at some point all 32 bit machines will have that problem when Debian drops 32 bit support as well.
Just thinking aloud…
BobC, you have an excellent argument on why maintaining at least one older workstream may be vital for those with hardware that now lacks software support (or will lose that support in the near future).
While I realize that this may be a fairly small community (at least for what we know today), it could potentially emerge as a large community and we may be one of the few organizations that supports it.
I understand how difficult that could become. The longer we can provide such a service, the more grateful those who have unsupported old hardware will appreciate our work.
We also have to realize that we won’t make money from doing this. The satisfaction is from fitting a niche that risks extinction. I hope that we will succeed in sustaining this effort. Thanks for everyone’s help in making it happen!
--
Brian MasinickOctober 3, 2020 at 4:22 pm #42517Member
roland
::A move to be applauded, I would welcome it. And yes, include the few release 19 additions suggested. My reasons are having tried release 19 on a laptop with unpleasant consequences I am cautious now and prefer to move to 19 step by step one PC at a time and leaving the laptop until last. I am generally happy with 17 apart from a minor problem with a flat screen TV I recently posted. I try to keep up with the rolling releases but naturally am cautious before upgrading a nicely working PC. It would be even better if one could move up from a major release to the next major release by means of a few bash scripts, leaving ones’ installed packages in place where compatible, but maybe there are too many objections and perhaps impossibilities with this?
October 3, 2020 at 5:00 pm #42519Moderator
Brian Masinick
::Something else to consider: as many of us know, the number of distributions that STILL support 32-bit hardware is steadily dwindling. I am thinking that “in case” Debian decides to pull, back down, or eliminate 32-bit support at some point in time, another “background task” that we may want to either begin or accelerate soon – if we want to support ancient hardware really long, is to begin building that infrastructure or enhancing that infrastructure, so in case we run out of upstream places to obtain 32-bit kernels, key utilities, and application software, we can gradually build them up from source code. I don’t think we’d have to choose more than a modest set of packages, but enough to run a nicely tailored distribution for old 32-bit hardware as support continues to dwindle away.
Does anyone else find this idea to be “useful” or would it be a “wasted exercise”?
--
Brian MasinickOctober 3, 2020 at 5:33 pm #42520Moderator
christophe
::I agree. I think it could be very useful.
What would be (specifically) needed?- This reply was modified 2 years, 7 months ago by christophe.
confirmed antiX frugaler, since 2019
October 3, 2020 at 6:29 pm #42524Moderator
Brian Masinick
::The things that are absolutely needed are:
1. Linux kernel
2. Core GNU command line tools and utilities
3. For a user environment, a current X server, at least one window manager, a terminal, a file manager, a text editor and a Web browser.That might be enough for the most “basic” system. As long as compilable code is available, anything else missing could be built on demand.
--
Brian Masinick -
AuthorPosts
- You must be logged in to reply to this topic.
