Stories
Slash Boxes
Comments

SoylentNews is people

posted by on Wednesday February 22 2017, @09:56AM   Printer-friendly
from the it's-already-perfect-is-not-the-right-answer dept.

We all know about Microsoft's latest OS, so I won't rehash. A lot of us intensely dislike it, to put it politely. Those of us who can, use other operating systems. This is Soylent, so let's focus on the one that is the most important to us: Linux.

I have been using Windows as my OS since right after Atari times. A few years ago I bought an ARM (ARMHF/ARMv7) netbook and put Lubuntu on it. I had problems with my first Linux experience, mainly in the area of installing software: missing packages in Synaptic, small dependency hells, installing a package at a time by hand, some broken stuff. I put it down mainly to the architecture I have been using, which can't be supported as well as x86-64.

Now, we all know that no software is perfect, and neither is Linux, even though it is now my main OS. We support it in spirit and financially, but there is always room for improvement.

So, the question is: What are your problems with Linux and how can we fix them? How do we better it? Maybe it's filesystems, maybe it's the famous/infamous systemd. Let's have at it.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by eravnrekaree on Wednesday February 22 2017, @02:09PM

    by eravnrekaree (555) on Wednesday February 22 2017, @02:09PM (#470158)

    I agree except for systemd. When you are dealing with a huge log file, having the log in a database can be a big advantage since it becomes much easier to be able to query certain fields and so on without having to parse the file. I do agree that you should be able to configure it to use the log file of your choice, such as text or sqlite.

    systemd's init files are also easier to deal with, because its a declarative format, there is less wheel reinventing to do simple things. You can always write a shell script if you need to, but often systemds init files have the feature you need, its much easier to write a declaration rather than have to write complex shell code. Shell code is not easier to deal with than the delcarative file format.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 4, Insightful) by q.kontinuum on Wednesday February 22 2017, @04:24PM

    by q.kontinuum (532) on Wednesday February 22 2017, @04:24PM (#470253) Journal

    I believe in the approach of small, dedicated tools for certain tasks, cobbling them together for big tasks. In this context I would expect a tool which ingests the existing log files and imports them into a database.

    Systemd as an init system is imo broken because it requires adaptation of other sw to work --> not modular.

    --
    Registered IRC nick on chat.soylentnews.org: qkontinuum
  • (Score: 2) by NCommander on Thursday February 23 2017, @03:11AM

    by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Thursday February 23 2017, @03:11AM (#470575) Homepage Journal

    My biggest issue with the binary log format is I can't easily glue syslogd to it. At a previous job, I would have syslog send all logs to a central source so I could easily check any machine in the cluster. The *sane* thing would be to do is make journald output to syslogd, and then provide a binary backend to syslogd to get the advantages you listed. Log files could also be written in plain text to /var/log for times when journalctl can't read its own database. That way you get all three, remote logging, text logging, *and* binary logging. Instead, they threw the baby out with the bathwater and made it extremely difficult for the two to interact in a sane way.

    Unit files are an improvement (this was something upstart also did), but systemd's implementation is badly flawed. The first one is that a typo is not a critical failure; you put Userr=nobody, and you'll get your program running as root without error. Upstart comparatively would refuse to load the file until it parsed successfully. The second (and IMHO fatal) error is its all or nothing. I can't define a custom variable and load it from another location. A couple of daemons (most notably varnish) requires command line arguments to be set at run time to load the right VCL files. The only way to do this with systemd is edit the unit file, and then have it merge it by hand when dpkg upgrades varnish (fortunately it will let you drop to a shell to do this. RPM will just override it without a message).

    --
    Still always moving