topic title: antiX-15-beta3 available.
Posts: 325
male
Joined: 04 Nov 2011
#31
@Alanarchy,
it was Qemu and perhaps sensitive... __{{emoticon}}__
Posts: 26
fladd
Joined: 09 Apr 2015
#32
BitJam wrote:
fladd wrote:Looks very nice, but: RAM usage has more than dobuled since Antix 13! It is now 130MB directly after booting into the desktop.
For minimal RAM usage choose one of the min-$DESKTOP options from the F6-Desktop menu in the bootloader. Booting to the desktop using min-icewm takes only 87 Meg total here. Some memory monitors will report an even lower value. For example, htop says only 52 Meg are used. There was a tension between keeping the memory footprint low and adding goodies to the desktop. We added the min-$DESKTOP options to try to relieve this tension. The default is to get a bunch of goodies but it is easy to disable them all.

HTH
Thanks a lot for the explanation. I was not aware of the min switch. I will try that.
Posts: 1,139
masinick
Joined: 26 Apr 2008
#33
fladd wrote:
BitJam wrote:
fladd wrote:Looks very nice, but: RAM usage has more than dobuled since Antix 13! It is now 130MB directly after booting into the desktop.
For minimal RAM usage choose one of the min-$DESKTOP options from the F6-Desktop menu in the bootloader. Booting to the desktop using min-icewm takes only 87 Meg total here. Some memory monitors will report an even lower value. For example, htop says only 52 Meg are used. There was a tension between keeping the memory footprint low and adding goodies to the desktop. We added the min-$DESKTOP options to try to relieve this tension. The default is to get a bunch of goodies but it is easy to disable them all.

HTH
Thanks a lot for the explanation. I was not aware of the min switch. I will try that.
This is indeed a very cool choice. Then again, I can recall not all that many years ago, testing a number of light window managers while using the antiX Full image at that time - probably in around the 2008-2010 time window. I recall that my IceWM instance used as little as 57 MB at the time when invoking just IceWM, one of the terminal emulators, and htop. The range between them all was pretty tight, from around 57 MB to about 62 MB, but believe it or not, at least back then IceWM was the lowest memory consumer, with JWM coming in pretty close, Fluxbox one or two MB more, and Openbox without LXDE fairly light too.

I pared things down reasonably slim, but it sounds like this min-icewm instance at 52 MB with htop is lighter by around 5 MB than what my setup produced 5-7 years ago, so congratulations on this feat! __{{emoticon}}__
Posts: 2,238
dolphin_oracle
Joined: 16 Dec 2007
#34
from another thread....
antiX-15-bata3 uses devuan base. It is systemd-free.
so devuan base for the non-systemd, but I see there are no devuan repos enabled by default in the beta3. How will that work down the road when stuff gets updated?
Posts: 325
male
Joined: 04 Nov 2011
#35
dolphin_oracle wrote:How will that work down the road when stuff gets updated?
it's not working!
Devuan is a dead end. __{{emoticon}}__
Posts: 850
fatmac
Joined: 26 Jul 2012
#36
Devuan seem to be getting the basics sorted out OK.
Don't forget that they had to set up infrastructure first before they could get on with coding.
First release shouldn't be too far away, agreed it will be minimal to start, but once the build scripts get sorted, the repo will fill up.
Posts: 1,445
skidoo
Joined: 09 Feb 2012
#37
dolphin_oracle wrote:from another thread....
antiX-15-bata3 uses devuan base. It is systemd-free.
so devuan base for the non-systemd, but I see there are no devuan repos enabled by default in the beta3.
How will that work down the road when stuff gets updated?
. . .
male wrote:Devuan is a dead end
Back in february, wondering"gonna sh*t or get off the pot?", I sought out their IRC channel, skimmed the archived chatlogs, and joined the channel ~~ with jotted notes and a few skeptical/pointed questions at the ready. I chatted with a fellow (I'm unsure whether his nickname was 'jaromil') whose demeanor and the content of his posts convinced me that he was one of the devuan principals (devs). In his answers to my various questions, he posed a number of questions of his own (requesting feedback on his 'ideas'). His posts sounded passionate, like"manic, but in a good way, well-intended". He described details of his proposed 'roadmap' that I'd not seen mentioned elsewhere -- and STILL haven't seen mentioned elsewhere (but then again, I don't closely follow devuan-related news-n-discussions).

Today, when a chain of links coincidentally led me to the devuan mailing list archives, I skimmed a couple messages
(a couple, as in, my patience is limited ~~ damn awkward way to try reading"discussions")

The phrase"pulling builds from various places" in one of jaromil's recent posts

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://lists.dyne.org/lurker/message/20150610.181451.20c6f997.en.html"
linktext was:"https://lists.dyne.org/lurker/message/2 ... 97.en.html"
====================================

caught my attention, because my takeaway from that isolated IRC chat included multiple 'intended roadmap' bullet points, like:

-- distributed (peer-to-peer) distribution mechanism
-- a periodic, incremental"release" would be freely downloadable, but
-- only users who paid an annual subscription would remain on a/the tracker's peerlist, receiving realtime patches/updates
-- each devuan install/instance (both paid subscribers, and non-donating?) would launch a peersharing service at startup + monitor network connection
-- each instance (he typed"node") while network connection available, would act as a package and/or source mirror/peer

The intent, in the big picture he described back in february, was: create a mechanism which would replace centralized repositories
FWIW, I was not (and am not) on that particular bandwagon.
My mindset is toward achieving"reproduceable/verifiable" builds, not toward pursuing a"continual integration" platform.
Posts: 1,139
masinick
Joined: 26 Apr 2008
#38
I'm not too sure that Devuan, in reality, is actually going anywhere. Can anyone show a single package that has even been created, perhaps stored elsewhere? To me, antiX is the most practical implementation of anything even remotely resembling devuan. We have put holds on systemd packages and compiled, recompiled, and reconfigured infrastructure to keep it as it was prior to the introduction of systemd packaging in Debian Testing, which is now present in the current Debian Testing, Debian Sid, and the current release, Debian 8.0 Jessie.

If our tiny project can preserve sysvinit, why can't the Devuan project do something similar unless they really don't have resources or anything more than some very upset individuals? I'm glad that our project technicians have applied something productive to their frustrations and offered the Debian community a practical, working alternative in MX-14 and in the upcoming antiX 15R. Has any other Debian or former Debian-based project done anything tangible beside our project? Maybe I'm just out of touch, but I prefer our approach. Instead of making noise, our experts went out, researched the software, came up with a way to preserve what we have, at least for now, and produced actual images, both test and release images, that retain sysvinit capabilities.
Posts: 4,164
rokytnji
Joined: 20 Feb 2009
#39
Running Live USB. IBM E50 Desktop wirelessly with SIS graphics chip. Picked safe graphics bootup to use Vesa driver from past experience with previous betas.

Code: Select all

demo@antiX1:~
$ inxi -G
Graphics:  Card: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter
           Display Server: X.Org 1.16.4 driver: vesa
           Resolution: 1024x768@0.00hz
           GLX Renderer: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits)
           GLX Version: 3.0 Mesa 10.3.2
demo@antiX1:~
$ inxi -Fxz
System:    Host: antiX1 Kernel: 4.0.0-antix.1-486-smp i686 (32 bit gcc: 4.9.2)
           Desktop: IceWM 1.3.8
           Distro: antiX-15-beta3-V_386-full Killah P 31 May 2015
Machine:   System: Lenovo product: 9218D1U
           Mobo: Lenovo model: 8S661FXMTIU v: x.x
           Bios: Award v: C661KTF6A date: 10/27/2005
CPU:       Single core Intel Pentium 4 (-HT-) cache: 2048 KB
           flags: (lm nx pae sse sse2 sse3) bmips: 6001
           clock speeds: max: 3000 MHz 1: 2800 MHz 2: 2800 MHz
Graphics:  Card: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter
           bus-ID: 01:00.0
           Display Server: X.Org 1.16.4 driver: vesa
           Resolution: 1024x768@0.00hz
           GLX Renderer: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits)
           GLX Version: 3.0 Mesa 10.3.2 Direct Rendering: Yes
Audio:     Card Silicon Integrated Systems [SiS] SiS7012 AC'97 Sound Controller
           driver: snd_intel8x0 ports: e000 e400 bus-ID: 00:02.7
           Sound: Advanced Linux Sound Architecture v: k4.0.0-antix.1-486-smp
Network:   Card-1: Realtek RTL-8100/8101L/8139 PCI Fast Ethernet Adapter
           driver: 8139too v: 0.9.28 port: e800 bus-ID: 00:0f.0
           IF: eth0 state: down mac: <filter>
           Card-2: Realtek RTL8191SU 802.11n WLAN Adapter
           driver: r8712u usb-ID: 004-002
           IF: wlan0 state: N/A mac: N/A
Drives:    HDD Total Size: 82.0GB (3.3% used)
           ID-1: /dev/sda model: WDC_WD800BB size: 80.0GB
           ID-2: USB /dev/sdb model: DataTraveler_2.0 size: 2.0GB
Partition: ID-1: swap-1 size: 2.10GB used: 0.00GB (0%) fs: swap dev: /dev/sda5
Sensors:   None detected - is lm-sensors installed and configured?
Info:      Processes: 168 Uptime: 3 min Memory: 103.1/1988.6MB
           Init: SysVinit runlevel: 5 Gcc sys: 4.9.2
           Client: Shell (bash 4.3.301) inxi: 2.2.1
Everything working good as it should hardware wise. __{{emoticon}}__

getting 1024x768 on a 21 incher crt which is just fine for a live session. I prefer this resolution on a live run before running the installer.
Posts: 4,164
rokytnji
Joined: 20 Feb 2009
#40
Rebooted and did not change any boot parameter or use F keys. just a noob default boot.

Code: Select all

demo@antiX1:~
$ inxi -G
Graphics:  Card: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter
           Display Server: X.Org 1.16.4 driver: vesa
           Resolution: 1280x1024@0.00hz
           GLX Renderer: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits)
           GLX Version: 3.0 Mesa 10.3.2
Still using vesa, but resolution is now bigger on touching nothing. Thought you would like to know.
Posts: 1,445
skidoo
Joined: 09 Feb 2012
#41
Brian, regarding the status quo, I think you'll find that a few minutes spent reading these will be enlightening:

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://refracta.freeforums.org/going-with-the-systemd-flow-or-not-t422-140.html#p4859"
linktext was:"http://refracta.freeforums.org/going-wi ... html#p4859"
====================================


========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://without-systemd.org/wiki/index.php/Main_Page#GNU.2FLinux_distributions"
linktext was:"http://without-systemd.org/wiki/index.p ... tributions"
====================================
Posts: 1,139
masinick
Joined: 26 Apr 2008
#42
skidoo wrote:Brian, regarding the status quo, I think you'll find that a few minutes spent reading these will be enlightening:

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://refracta.freeforums.org/going-with-the-systemd-flow-or-not-t422-140.html#p4859"
linktext was:"http://refracta.freeforums.org/going-wi ... html#p4859"
====================================


========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://without-systemd.org/wiki/index.php/Main_Page#GNU.2FLinux_distributions"
linktext was:"http://without-systemd.org/wiki/index.p ... tributions"
====================================
Thanks for the information! It appears that there is some activity going on. I do know that there are quite a few distributions outside of the Debian space that offer alternatives to systemd and of course some that run Debian-based software too.

It's good to see details about removing systemd and keeping it out, for those who have concerns.

I've run both; systemd is not the complete disaster that some people seem to think it is, and with distributions like Debian and Fedora behind it, I figured as much. Personally, I think that having a choice is good, and at the present time there are plenty of good choices. However, I'm sure it has been disconcerting to some people that the approach taken with systemd made quite a few non-portable decisions and also quite a few decisions that force large package groups to be included.

From the standpoint of small distributions like antiX, I can certainly see why some have objected to the notion of having so many libraries forced upon them in the systemd implementation. I am thankful that, so far anyway, antiX has steered clear of the noise for the most part, and simply offers another alternative in keeping with sysvinit. It will be interesting as time goes on to see if the team is able to provide alternatives that will allow users to choose one, the other, or even side by side choices or implementations that can run either initialization approach. I think doing such things could prove to be quite a strong challenge, though not impossible. Either way, I applaud our developers and integrators for being decisive and making some systems that work really well.
Posts: 850
fatmac
Joined: 26 Jul 2012
#43
or even side by side choices or implementations that can run either initialization approach. I think doing such things could prove to be quite a strong challenge, though not impossible.
I think you will find that Debian can be 'converted' to 'sysV' init, but it will still use systemd files to do it, & of course all the software that will still be tied to systemd, so no way of dumping systemd!
Posts: 1,139
masinick
Joined: 26 Apr 2008
#44
fatmac wrote:
or even side by side choices or implementations that can run either initialization approach. I think doing such things could prove to be quite a strong challenge, though not impossible.
I think you will find that Debian can be 'converted' to 'sysV' init, but it will still use systemd files to do it, & of course all the software that will still be tied to systemd, so no way of dumping systemd!
Whether side-by-side code or a choice between code would depend greatly on exactly what is used and how it is implemented.

I suspect that package dependencies in the current Debian infrastructure would require another repository and considerably different layout and dependencies; it would not be easy or it would already be out there.

I don't personally have the packaging or integration skills to accomplish it, though I may be able to conceptualize an overall approach. Having not achieved it, I may, in reality, be an out of touch observer! __{{emoticon}}__
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#45
rokytnji wrote:Still using vesa, but resolution is now bigger on touching nothing. Thought you would like to know.
Look at the output of these two commands:

Code: Select all

/sbin/make-xorg-conf default

/sbin/make-xorg-conf safe
This is why the resolution is different. If we don't find hardware that supports a KMS video driver then we create an xorg.conf with the first command. If we didn't then you would get the default fbdev driver and the same resolution as the consoles, which by default is 800x600. In failsafe mode we use the second command to make the xorg.conf which in addition to using the vesa driver also restricts the resolution. It sets the resolution to 1024x768 and if that fails then it falls back to 800x600.

If you want to see the default behavior without an xorg.conf use the"noxorg" cheat (and don't use Failsafe).