You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 Re: Installation » Is the server ISO a subset of the desktop DVD? » 2021-05-12 11:52:40
Thanks.
#2 Installation » Is the server ISO a subset of the desktop DVD? » 2021-05-11 17:46:33
- pj1967
- Replies: 2
In terms of packages. Asking for a friend :-)))
Just kidding. I'm doing a minimal install and then layering on packages and groups of packages that I need for an "embedded" project, so I want to make sure that I have an exhaustive local repo of packages to install from...it's local because I want to control what patches get distributed after we curate them with our software.
#3 Re: Off-topic » What are you reading/want to read ? » 2021-05-11 17:28:49
The Inheritance of Rome by Chris Wickham
#4 Re: Off-topic » What other distro are you using (besides devuan)? » 2020-10-06 18:33:08
I've diddled with Void and Miyolinux, but Devuan is my "serious" use distro. For my companies back office stuff, I have a mix of Devuan, FreeBSD, and OpenBSD. We do have a Windows 2012 server running our SolidWorks Vault as well as hosting MRP and QB.
For our companies products, I'm still in a pitched battle to rip RHEL from the hands of our software engineers and force them to drink from the cool chalice of Devuan...in a manner of speaking.
#5 Re: Devuan » Debian considering going systemd init only » 2020-01-09 13:30:48
pj1967 wrote:
But if not, we're looking at forking at the kernel level, no?Hyperbola already got plans just for that, albeit forking the OpenBSD kernel. I wish them success.
https://www.hyperbola.info/news/announc … d-roadmap/
OpenBSD seems like a viable starting point for a new opensource OS fork. It's clean, simple, and resists binary blobs.
However, if staying on the "linux" path is necessary, going back to the 2.6 kernel might be a good starting point?
#6 Re: Devuan » Debian considering going systemd init only » 2020-01-08 19:24:08
In the overall battle against systemd (not just limited to Debian and it's downstream affect on Devuan), what's to prevent kernel dependencies worming their way down from systemd creating a lockout of non-systemd components? Despite his rant against Sievers, Linus' apparent apathy to systemd doesn't speak well to protecting the kernel from such pollution. If such encroachments can be kept at bay, then it seems possible to continue with a systemd-less distro. But if not, we're looking at forking at the kernel level, no?
#7 Re: Off-topic » Marginalizing systemd » 2019-09-16 18:09:43
pj1967 wrote:Are there ways to strip it down to nearly nothing, and then call my own "rc.local" scripts to start the few things that I want running?
It may be fruitful to play around with RHEL in a VM. You can circumvent init and a service manager (or don't use a service manager at all) pretty easily. I posted a couple things a few weeks ago that you might find useful.
I don't know your role, why your customer wants RHEL, or how it will be used. When we want to steer a customer to a better alternative, we usually just let them tell us why they want "their" way, and explain the issues with their thinking. Then, we suggest a better route.
Based on its stats, how likely is it that RHEL7, which we know is a farcry from RHEL6, will run well on it? How many more hours will be charged to maintenance? I don't need an answer, but these are issues with tangible consequences for a customer.
Just did exactly that...installed RHEL7 in a VM and limited it's boot to just bringing up the system with console logins. Turned off all daemons, and use rc.local to invoke the network settings and launch the specific daemons I want running.
I do have parallel systems running Devuan which is my distro of choice, when given the choice, but does require more tinkering to get our software compiled and running (just a matter of cleaning up our software build process to know where generic libraries are located).
#8 Re: Off-topic » Marginalizing systemd » 2019-08-27 14:56:29
pj1967 wrote:So, a customer of ours is insisting on RHEL7 (don't know why but I suspect those that make such decisions are not very technically savvy).
I think you should ask them why they want RHEL7. And perhaps you could try to explain to them why it may not be the best choice for an embedded system.
Phil
I think this is a case of the customer employing "corporate" think reinforced by a perceived prestige (undeserved, IMO) that RH has (enlarged to some degree by it's acquisition by IBM).
Since we've already experienced odd performance problems with RHEL7 (RHEL6 works fine for us now), I've already deployed a Devuan-based system for development and testing with the intent to demonstrate Devuan's superiority. In fact, for our other product lines, I've already deemed Devuan to be the OS going forward. However, it's likely that systemd has no bearing on our problem. But, my original post of this thread is my searching for a worst case scenario solution should the customer stick to their demand for RHEL7 and if we are able to resolve the performance problem.
#9 Re: Off-topic » Marginalizing systemd » 2019-08-27 01:10:02
This is a question to be asked on Red Hat or Fedora forum. And best to do research before asking/answering.
You really think I'll get a straight answer from an RH forum? :-\ I'd have better luck in a xBSD forum. Oh, and part of researching is asking those who might know. But, your irrelevant response is noted.
#10 Re: Off-topic » Marginalizing systemd » 2019-08-26 22:15:11
Doesn't RHEL7 come with sysVinit as optional/alternative to systemd? .
Really? I was under the impression that RHEL7 was SystemD only. Hmm, I'll have to look into that.
#11 Off-topic » Marginalizing systemd » 2019-08-26 20:41:08
- pj1967
- Replies: 9
So, a customer of ours is insisting on RHEL7 (don't know why but I suspect those that make such decisions are not very technically savvy). So, if one wanted to reduce systemd's functionality within a system that is, for all intensive purposes, an embedded system, what might be a way(s) to accomplish this? Are there ways to strip it down to nearly nothing, and then call my own "rc.local" scripts to start the few things that I want running?
#12 Re: Hardware & System Configuration » CPU throttling » 2019-07-01 17:00:05
Did you try modifying /sys/devices/system/cpu/intel_pstate/* instead of just disabling it?
I did some minimal perusing of /sys/devices/system/cpu/intel_pstate and didn't attempt to change anything. I certainly will try that, but my initial idea was to "brute force" remove any kind of cpu throttle/governor, then maybe back off that brute force method with more subtle changes.
#13 Re: Hardware & System Configuration » CPU throttling » 2019-06-28 18:06:40
Ok, after nearly a year and a half, I cycled back around to this issue and finally found a solution. As I suspected, it's not a specific issue with Devuan and involves the intel_pstate kernel "module" (not really a module, rather a compiled in feature of the generic kernel). To make a long story short, to prevent CPU throttling, you have to disable the intel_pstate feature in the kernel...the obvious way that I know to do this is to add 'intel_pstate=disable' to the kernel command line in grub....e.g.
1) Append 'intel_pstate=disable' to the GRUB_CMDLINE_LINUX_DEFAULT variable in /etc/default/grub
2) run update-grub
3) reboot
And, viola! All cpu cores run at their rated max clock speed all the time (no turbo mode, AFAIK).
--PJ
PS: I love the Devuan distro! Keep up the good work/fight devs!
#14 Re: News & Announcements » Devuan 2.0 ASCII Stable » 2018-06-13 13:01:47
Awesome, devs!!!! THX for your hard work!!!
#15 Re: Hardware & System Configuration » CPU throttling » 2018-02-22 18:02:58
So, tinkering around with this didn't yield what I wanted. As you indicated, the default governor is "performance" which still throttles down the CPU cores when idle. With redhat 6 (2.6 .32), the kernel config file has similar entries as above, but with cpuspeed disabled, the CPU run at full clock speed even when idle. I suspect I might need to recompile the kernel with the CPU governors disabled?
#16 Re: Hardware & System Configuration » CPU throttling » 2018-02-07 18:35:18
Ah, ok, I'll use cpufrequtils for jessie.
THX,
PJ
#17 Hardware & System Configuration » CPU throttling » 2018-02-07 15:06:32
- pj1967
- Replies: 7
Hi all,
I'm trying to figure out what mechanism devuan jessie uses to throttle down the CPU clock...basically, I want to turn that off and let the CPU run at full clock speed.
cpufrequtils isn't installed, and I'm fairly certain that the BIOS is set to not throttle...so...any ideas?
THX,
PJ
#18 Installation » Installation via network with pxeboot » 2017-11-14 16:01:39
- pj1967
- Replies: 1
Hi Folks,
I have central pxeboot server that I use to install various distros of linux over the network (RHEL, CentOS, Ubuntu, Debian...) and I'm a little stuck incorporating devuan into this. Using the NETINST iso's vmlinuz and initrd.gz, I can pxeboot off that, but the installer process asks for a CD for additional drivers. Should I use a different kernel/initrd?
Any ideas?
THX,
--Phil
Pages: 1
Board footer
