SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
How would you find out what the current sendmail/postfix usage is among slackers?
To respond to usage questions like this was invented the Telemetry and this seems to be the single way to get a meaningful response.
However, I do not believe that the addition of Telemetry (aka OS calling home) will ever happen on Slackware, because this will generate a scandal magnitude grades bigger than the adoption of systemd.
So, there are more chances for Mr. Poettering to join the Slackware Team as Init System Architect, than Slackware to ever phone home. Because nothing is hatted more by Slackers than software phoning home.
Last edited by LuckyCyborg; 11-24-2022 at 11:03 AM.
How would you find out what the current sendmail/postfix usage is among slackers?
Even if everyone's /var/lib/dbus/machine-id were attached to config files generated in users' /home and synced to centralized datacenter:
There's no way that will represent actual usage of software in question, considering different data protection laws in different parts of the world.
The data you're asking about, even if it could be efficiently obtained, is unreliable enough to be technically worthless.
I don’t see too much of a hassle. We are not talking KDE efforts. Apache has been updated once in a blue moon (for many reasons), and Nginx isn’t a time waster with their release cycle. sendmail is still offered as an option to postfix in extras. PHP has both v7 in mainline and v8 in extras/. We had two gcc and glibc before (again, for reasons).
If Apache fits most needs and people are fine living in the 90’s, that’s fine and perfectly acceptable. Others might want to look at 2023 and go after newer solutions, and I expected not to offend by asking, the same way I expect “no” as an answer and I shall continue to compile one from SBo/sources myself until minds are changed.
I'm a big fan of nginx and everything I set up is using it. I also have a package for it in my repo for people to use if they want.
That said, httpd is the classic option and there's probably very very good arguments needed to get nginx to replace it in core. Even if nginx is already very established, it's still the new kid on the block compared to httpd, and I can imagine a lot of people using Slackware have more experience with httpd than with nginx. That also includes other members of the core team, and that's why that argument matters even more
I'm not saying don't try. It's just that you have an uphill battle to fight to change the relevant minds
My friend with in your packages do you by chance have slackbuilds so that if something goes wrong with say we want another dep added to that program we can build that said app and rebuild the main one that required it?
Quote:
Originally Posted by ppr:kut
I'm a big fan of nginx and everything I set up is using it. I also have a package for it in my repo for people to use if they want.
That said, httpd is the classic option and there's probably very very good arguments needed to get nginx to replace it in core. Even if nginx is already very established, it's still the new kid on the block compared to httpd, and I can imagine a lot of people using Slackware have more experience with httpd than with nginx. That also includes other members of the core team, and that's why that argument matters even more
I'm not saying don't try. It's just that you have an uphill battle to fight to change the relevant minds
My friend with in your packages do you by chance have slackbuilds so that if something goes wrong with say we want another dep added to that program we can build that said app and rebuild the main one that required it?
Overview of changes in GLib 2.74.2
Fix GVariant type depths checks on text format variants (work by Philip Withnall) (#2782)
Fix an obscure corner case with FD handling in g_spawn_*() when a process has already closed the standard I/O FDs (work by Ray Strode) (#2795)
Fix regression in type checking on const arguments to g_str_equal() (#2809)
Now that -current has at-spi2-core updated to 2.46.0, I'd like to note the libraries atk and at-spi2-atk should be removed from the packages, as they are now included as part of at-spi2-core package.
From the NEWS file:
Quote:
What's new in at-spi2-core 2.45.1:
* Atk and at-spi2-atk are now merged into this project.
Just noting this here again, so there isn't stale libraries sitting in the tree.
Maybe because everyone is turning to the “friendlier” postfix?
Postfix certainly seems to be the flavour of the month, and that's fine - choice is a good thing. However, I for one plan to stick with Sendmail while it continues to be maintained by upstream. I have many site-specific customisations set up which would take considerable time to port to Postfix, and there are some which Postfix couldn't do when I last checked.
'Maybe because everyone is turning to the “friendlier” postfix?'
Postfix certainly seems to be the flavour of the month, and that's fine - choice is a good thing. However, I for one plan to stick with Sendmail while it continues to be maintained by upstream. I have many site-specific customisations set up which would take considerable time to port to Postfix, and there are some which Postfix couldn't do when I last checked.
Yes, but it seems you and I are in the minority -- Slackware is fast becoming the preferred package manager for friendly software. Who needs boring old features such as reliability, stability, and fit-for-purpose?
Yes, but it seems you and I are in the minority -- Slackware is fast becoming the preferred package manager for friendly software. Who needs boring old features such as reliability, stability, and fit-for-purpose?
Look out Ubuntu!
You know, not everybody have your patience and interests, to spend 30 years learning how to configure sendmail...
I have never used (as in "managed") a mail server, but I heard in various place that the fall (and the fail) of sendmail was exactly because its over-complicated configuration written in Klingon, so when a viable alternative became available, nobody bothered anymore to struggle with it and its crazy configuration.
Nope, is nobody's fault, just that today there are not many to appreciate something like this:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
