https://mxlinux.org/blog/mx-19-2-kde-now-available/#comment-1534
Monday, August 31, 2020
Thursday, August 27, 2020
MX Linux 19.2 KDE
I downloaded MX Linux 19.2 in the recently released KDE edition. I have not been using KDE very much in recent years and I wanted to see how the MX Linux implementation compares, both to other editions of MX Linux and to KDE implementations in other distributions.
I have used KDE with PCLinuxOS; many years ago I used PCLinuxOS predominantly with KDE. More recently I used PCLinuxOS with Xfce and it was fine.
Comparing any edition of PCLinuxOS with any edition of MX Linux is interesting because both distributions do a good job and meet the needs of their users. No matter which edition is used, MX Linux boots up faster and runs somewhat more efficiently. Past research to determine the reason behind this observation and to separate opinion and bias from experiences and feelings, I found that MX Linux, among desktop distributions, loads fewer daemon and other background processes, contributing to slightly better performance that can be both visualized and quantified. The necessary tools to run a simple desktop are always present in MX Linux and this is evident in the new KDE edition too. It's comparable to the old MEPIS, which always featured a well engineered desktop using functional, efficient software. The only differences are due to a decade of software changes; otherwise it's still the same usable behavior in a modern conservative configuration.
Friday, July 31, 2020
Running EasyPC 2.3.3 - Debian Buster Version
more version
#One or more words that identify this distribution:
DISTRO_NAME='Easy Buster64'
#version number of this distribution:
DISTRO_VERSION=2.3.3
#The distro whose binary packages were used to build this distribution:
DISTRO_BINARY_COMPAT='debian'
Linux version 5.4.51 (root@EASYPC27427) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Sun Jul 12 21:43:54 +08 2020
DISTRO_NAME='Easy Buster64'
#version number of this distribution:
DISTRO_VERSION=2.3.3
#The distro whose binary packages were used to build this distribution:
DISTRO_BINARY_COMPAT='debian'
Thursday, June 11, 2020
About "runit" with antiX
Since the "old" SystemV Init subsystem, sysVinit, was mostly given up in
the Red Hat, Ubuntu, Arch, and Debian spaces, there were a few
distributions that "held out".
It's hard to believe that it has been close to a decade that those controversial changes were first made. To be honest with you, when I've run them on various distributions, I haven't had any real "problems" with them, at least from a technical point of view. I've never had to dig deeply into the bowels of the technical details to resolve any issue, and that's a good thing, because the binary nature of the systemd replacement has been: 1. It's "binary", so everything it does also comes with a tool to manage it. 2. SystemD is WAY more than just an init process, and I think that was the other thing that upset so many people, though it has subsequently been adopted in quite a few places and the noise everywhere, EXCEPT in the distributions that DID NOT adopt it has abated quite a bit.
What's runit then? Well, runit is another effort to replace the old UNIX System V approach that has been around almost since the beginning, not just of the nineties Linux era, but before that in the seventies and eighties with the original UNIX systems, many of which continue to exist in back end server rooms with legacy hardware and software.
Runit is a fairly minimal init process handler, so that makes systemD haters happy, but it does not do very much. It's fast, though, so if you really want a process initializer that ONLY does process initiation, it definitely does that. It doesn't completely handle all aspects of initialization (other than starting processes, so if you have any complaints, it'll be with "missing features" but NOT with a lack of speed. AntiX 19 with runit is as fast or faster than the usual lean, mean, light and nimble system, and if you don't expect much from an init process and you really do want it to only initialize and fork additional processes, runit is perfect for JUST that. Don't expect much with log files or fancy handling when changing run levels, it is not very special and has only the most basic (though sufficient) capabilities in this regard. antiX runit on the whole is great for a system that is simple in the basic sense and fast.
It's hard to believe that it has been close to a decade that those controversial changes were first made. To be honest with you, when I've run them on various distributions, I haven't had any real "problems" with them, at least from a technical point of view. I've never had to dig deeply into the bowels of the technical details to resolve any issue, and that's a good thing, because the binary nature of the systemd replacement has been: 1. It's "binary", so everything it does also comes with a tool to manage it. 2. SystemD is WAY more than just an init process, and I think that was the other thing that upset so many people, though it has subsequently been adopted in quite a few places and the noise everywhere, EXCEPT in the distributions that DID NOT adopt it has abated quite a bit.
What's runit then? Well, runit is another effort to replace the old UNIX System V approach that has been around almost since the beginning, not just of the nineties Linux era, but before that in the seventies and eighties with the original UNIX systems, many of which continue to exist in back end server rooms with legacy hardware and software.
Runit is a fairly minimal init process handler, so that makes systemD haters happy, but it does not do very much. It's fast, though, so if you really want a process initializer that ONLY does process initiation, it definitely does that. It doesn't completely handle all aspects of initialization (other than starting processes, so if you have any complaints, it'll be with "missing features" but NOT with a lack of speed. AntiX 19 with runit is as fast or faster than the usual lean, mean, light and nimble system, and if you don't expect much from an init process and you really do want it to only initialize and fork additional processes, runit is perfect for JUST that. Don't expect much with log files or fancy handling when changing run levels, it is not very special and has only the most basic (though sufficient) capabilities in this regard. antiX runit on the whole is great for a system that is simple in the basic sense and fast.
Monday, February 10, 2020
antiX-19-runit_x64-base
I am running this system live from a fairly fast 64 GB USB 3.0 Seagate drive.
System:
Host: antiX Kernel: 5.5.0-antix.1-amd64-smp x86_64 bits: 64 compiler: gcc
v: 8.3.0 Desktop: IceWM 1.6.3+git20191202
Distro: antiX-19-runit_x64-base Marielle Franco 9 December 2019
base: Debian GNU/Linux 10 (buster)
Machine:
Type: Laptop System: Dell product: Inspiron 5558 v: 01 serial:
Mobo: Dell model: 086DKN v: A00 serial: UEFI: Dell v: A04
date: 08/06/2015
It seems to boot faster and generally run as well or better than using a hard drive with this "fast" USB 3.0 drive.
AntiX is a fairly fast system to begin with and it's built to run well on a variety of media.
System:
Host: antiX Kernel: 5.5.0-antix.1-amd64-smp x86_64 bits: 64 compiler: gcc
v: 8.3.0 Desktop: IceWM 1.6.3+git20191202
Distro: antiX-19-runit_x64-base Marielle Franco 9 December 2019
base: Debian GNU/Linux 10 (buster)
Machine:
Type: Laptop System: Dell product: Inspiron 5558 v: 01 serial:
Mobo: Dell model: 086DKN v: A00 serial:
date: 08/06/2015
It seems to boot faster and generally run as well or better than using a hard drive with this "fast" USB 3.0 drive.
AntiX is a fairly fast system to begin with and it's built to run well on a variety of media.
Saturday, November 16, 2019
Porteus installed on USB
guest@porteus:/proc$ more version
Linux version 5.1.5-porteus (root@porteus.example.net) (gcc version 9.1.0 (GCC))
#1 SMP PREEMPT Sun May 26 17:25:39 Local time zone must be set--
Monday, October 21, 2019
MX-18.3 with the MX Workbench 2019-03 update
inxi -Fxz
System: Host: mx Kernel: 4.19.0-1-amd64 x86_64 bits: 64 compiler: gcc v: 6.3.0Desktop: Xfce 4.12.3 Distro: MX-18.3_x64 Continuum March 14 2018
base: Debian GNU/Linux 9 (stretch)
Machine: Type: Laptop System: Dell product: Inspiron 5558 v: 01 serial:
Mobo: Dell model: 086DKN v: A00 serial:UEFI [Legacy]: Dell v: A04
date: 08/06/2015
Battery: ID-1: BAT0 charge: 33.9 Wh condition: 33.9/41.4 Wh (82%)
model: Samsung SDI DELL 07G07587587 status: Full
CPU: Topology: Dual Core model: Intel Core i7-5500U bits: 64 type: MT MCP arch: Broadwell
rev: 4 L2 cache: 4096 KiB
flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 19154
Speed: 798 MHz min/max: 500/3000 MHz Core speeds (MHz): 1: 798 2: 799 3: 798 4: 799
Graphics: Device-1: Intel HD Graphics 5500 vendor: Dell driver: N/A bus ID: 00:02.0
Device-2: NVIDIA GK208M [GeForce 920M] vendor: Dell driver: N/A bus ID: 08:00.0
Display: x11 server: X.Org 1.19.2 driver: vesa resolution: 1368x768~N/A
OpenGL: renderer: llvmpipe (LLVM 7.0 256 bits) v: 3.3 Mesa 18.2.6 direct render: Yes
Audio: Device-1: Intel Broadwell-U Audio vendor: Dell driver: snd_hda_intel v: kernel
bus ID: 00:03.0
Device-2: Intel Wildcat Point-LP High Definition Audio vendor: Dell
driver: snd_hda_intel v: kernel bus ID: 00:1b.0
Sound Server: ALSA v: k4.19.0-1-amd64
Network: Device-1: Intel Wireless 3160 driver: iwlwifi v: kernel port: f040 bus ID: 06:00.0
IF: wlan0 state: up mac:
Device-2: Realtek RTL8101/2/6E PCI Express Fast/Gigabit Ethernet vendor: Dell
driver: r8169 v: kernel port: e000 bus ID: 07:00.0
IF: eth0 state: down mac:
Drives: Local Storage: total: 931.51 GiB used: 11.51 GiB (1.2%)
ID-1: /dev/sda vendor: Seagate model: ST1000LM024 HN-M101MBB size: 931.51 GiB
Partition: ID-1: / size: 97.93 GiB used: 11.51 GiB (11.8%) fs: ext4 dev: /dev/sda3
Sensors: System Temperatures: cpu: 53.0 C mobo: N/A sodimm: 37.0 C
Fan Speeds (RPM): cpu: 2200
Info: Processes: 199 Uptime: 1h 17m Memory: 7.70 GiB used: 1.23 GiB (15.9%) Init: SysVinit
runlevel: 5 Compilers: gcc: 6.3.0 Shell: bash v: 4.4.12 inxi: 3.0.36
Subscribe to:
Posts (Atom)