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:48PM

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

    1. Stop making stupid radical GUI changes
    By far the worst Linux useability regression is the asinine user interface experiments such as with Gnome 3 and Unity. There was widespread outrage over Unity and how it took what was once one of the most useable Linux distros and made it into a confounding mess that confuses everyone. We need to revert back to the desktop/taskbar/start menu model and stop making these radical changes to the user interface. Few people like Unity, yet Canonical doesnt care, a totally arrogant company.

    2. Hardware compatability
    The continuing problems with hardware compatability are a major blocker. I think what Linux needs to do is develop a stable hardware driver ABI, which could sit above the core kernel ABI, and that Ubuntu, instead of helping Microsoft and messing up the UI, should work with hardware vendors to get hardware drivers using vendor code into Linux as quickly as possible. If we really wanted to do the state of the art here, the Linux distros should jointly support an effort to implement the Windows hardware ABI in a compatability layer above the Linux ABI, so all Windows drivers could run unmodified on Linux. This would really make Linux a serious alternative for most users.

    3. Compatability with Windows Apps via WINE
    Another improvement would be to bring Wine to where it could run 99% of Windows applications. Instead of helping Microsoft by helping Linux programs run on Windows, Ubuntu should be helping to get Windows programs to run on Linux which would be what would help Linux become more useable. Being able to bring their applications with them, often these can be custom applications that have no Linux equivalent, can be a big argument to get people to move to Linux. Yes for general applications there are sometimes alterntives such as LibreOffice, however, Windows is often used for custom applications or lesser known in house applications in commercial settings. Sometimes the Linux alternative is far inferior, such as compare Adobe tools to the Linux equivalents. Yes, sometimes you can get the same thing done with Gimp or Inkscape but the workflow is much worse, its not just being able to do something but being able to have a fast workflow. You ask how to do something that takes 3 steps in Adobe and the Linux equivalent has it taking 20 steps and they act like this is suitable . Time is money and the reason Adobe products are so useable is not just that there is a way to do it, but that it has a fast workflow that makes it possible to get it done quickly.

    4: Systemd is an improvement!

    One of the things which has been a benefit is systemd. Most of the arguments against it are nonsense. The declarative file format is much easier to read and write than shell scripts since it requires less wheel reinventing. shell scripts can be convoluted and obfuscated, systemd often has a simple declaration which would require many lines of shell script dealing with PIDs and so on.

    The idea that it is monolithic is a lie. The system is highly modular consisting of dozens of components. A message bus based model for init makes sense and preserves the ability to have a traditional SysV facility at the same time. A bus based design for the init system is far more flexible and modular, since you can write an init daemon that watches for the event you are listening to on the bus, and then launch a task when you receive the event message, you can also generate your own event message when you launch the task. This makes it possible to start a task on a wide variety of system events. One of the misnomers is that systemd is "taking over" things like cron. Actually, a seperate cron daemon can still be used, the cron daemon being connected to a message bus does not mean that it is no longer a seperate process, though it can interact with the message bus by generating event messages on it .

    You can always run processes using the older SysV method and shell scipts if that is what you want, so the idea that systemd has taken something away from you is also false. I have set up SysV scripts in systemd with no issues.

    Database log files are a benefit when you have to deal with massive log files since it makes querying the file much faster and more precise. If you can store log files into an SQL database you can query certain fields in the table for what you are looking for without having to parse the file. Trying to use grep for this is much more imprecise. I think the log system should allow people to choose the log format of their choice, a text based format, sqlite, mysql, etc. This should keep everyone happy.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 3, Insightful) by MadTinfoilHatter on Wednesday February 22 2017, @08:06PM

    by MadTinfoilHatter (4635) on Wednesday February 22 2017, @08:06PM (#470392)

    4: Systemd is an improvement!

    One of the things which has been a benefit is systemd. Most of the arguments against it are nonsense.

    Actually I find a large portion of the arguments to be well reasoned, and thought out - at least far more well thought out than the "Hey, let's abandon everything we know about good design, because, you know, FASTER BOOT TIMES!!!11 one one" that is what the systemd-camp so often offers. Granted, your argument is a notch above that, but all you say has been debunked long ago. Here is a fairly comprehensive list of anti-systemd arguments, [without-systemd.org] and while I admit that not all the arguments are top notch, some of them are golden.

    The declarative file format is much easier to read and write than shell scripts since it requires less wheel reinventing. shell scripts can be convoluted and obfuscated, systemd often has a simple declaration which would require many lines of shell script dealing with PIDs and so on.

    Superficially, this is true, but it's really just shuffling the complexity around. What's really going on, though, is that the complexity has been moved from the logic into the language.

    In stark contrast to Bourne shell, so many of systemd's unit directives are highly specialised building blocks which aren't easily reusable. This isn't necessarily a bad thing, except that because systemd units aren't real programs, there's no way to escape to more basic primitives as required. Inevitably, what this means is that more and more directives will be added over time as more and more use cases are discovered. See Steven McDonald's page for more details. [steven-mcdonald.id.au]

    Add to this fact that every sysadmin on the planet knows at least some shell scripting - what's going to be easier to fix when a bug is found? The shell script or the systemd C code?

    The idea that it is monolithic is a lie. The system is highly modular consisting of dozens of components.

    The claim that systemd is modular is pure sophistry. In fact it's Fallacy #1 [blogspot.cz] on Jude Nelson's list of systemd proponent fallacies.

    Lennart Poettering claims that systemd is not monolithic by pointing out that it is made of upwards of 69 separate binaries. This is a non sequitur, because "modular" and "monolithic" are not mutually exclusive terms.

    A piece of software is modular if it is decomposable into distinct functional units such that each unit addresses a specific concern. Systemd, the Linux kernel, and X.org are all examples of modular software. Systemd addresses its concerns with its binaries, the Linux kernel with loadable kernel modules, and X.org with its drivers and extensions.

    Now, a piece of software is monolithic if its components (if it has any at all) are tightly coupled--that is, components logically depend on one another to the point where using them in different contexts requires re-implementing the missing ones. Examples include Linux and X.org--in Linux's case, you can't use a kernel module without the kernel, the kernel can't run without the requisite kernel modules to interface with the hardware, and you can't use a Linux kernel module with other kernels or as a stand-alone program. Similarly, you can't use an X video driver without the X server, you can't use the X server without at least one video driver, and you can't use X's video drivers with other graphics managers or as stand-alone programs.

    Under these definitions, systemd qualifies as both modular and monolithic. You cannot run journald without systemd, and cannot run systemd without journald (at least, not without losing logging for systemd-supervised programs). None of the *ctl programs work without systemd, nor do its collection of systemd-*d daemons. It used to be possible to run logind separately, but not anymore. According to the systemd developers, udev will likely be next to hard-depend on systemd. The point is, despite the fact that systemd is comprised of multiple binaries, the hierarchical logical coupling between them means that it is more accurate to think of them as extensions to systemd-PID-1 that just happen to run in separate address spaces. They are not truly independent, composable programs.

    You can always run processes using the older SysV method and shell scipts if that is what you want, so the idea that systemd has taken something away from you is also false. I have set up SysV scripts in systemd with no issues.

    The fact that it worked for you in some cases doesn't mean that it works anywhere near as well as SysV did. I haven't had personal problems, but that's mostly because I've been shunning systemd like the plague. But since it's anecdote time, a buddy of mine however began channeling Samuel Jackson after trying systemd for a couple of months... "I've had it with this motherf***** systemd on this motherf****** machine!" He switched to Devuan and was happy.

    Database log files are a benefit when you have to deal with massive log files since it makes querying the file much faster and more precise. If you can store log files into an SQL database you can query certain fields in the table for what you are looking for without having to parse the file.

    Okay, I really don't get what you're talking about here. I've been on one single project where the devs decided that cramming all the log files into a mysql database would be a good idea. It was the slowest and most horrible cludge I've ever seen. Something that would take grep seconds took the relational DB a minute or more. You had to search for stuff in one hour blocks, or the DB would grind to a complete halt. After 3 days the sysadmins put their foot down and we were back to normal text logs. Wanting logs in binary format sounds like the ramblings of a lunatic - even more so if the binary logs can fuck themselves up so that they're unrecoverable, [freedesktop.org] and troubleshooting therefore becomes a nightmare.

    Finally I would like to close with this link [landley.net], which is one of the more insightful explanations about the philosophical problems that many of us have with what is probably the worst thing to hit the Linux world since the SCO lawsuits: systemd.

    • (Score: 3, Insightful) by Marand on Thursday February 23 2017, @05:35AM

      by Marand (1081) on Thursday February 23 2017, @05:35AM (#470616) Journal

      In stark contrast to Bourne shell, so many of systemd's unit directives are highly specialised building blocks which aren't easily reusable. This isn't necessarily a bad thing, except that because systemd units aren't real programs, there's no way to escape to more basic primitives as required. Inevitably, what this means is that more and more directives will be added over time as more and more use cases are discovered.

      There was another way that could have given us the best of both worlds, but it wasn't taken. Bourne shell isn't required for init scripts; it's fully possible to implement an interpreter for a systemd-style declarative init format and use it where convenient, and then fall back to writing programs when you need something "low level" that it can't do. I explain this in more detail in my other comment. [soylentnews.org]

  • (Score: 1) by WillR on Wednesday February 22 2017, @08:44PM

    by WillR (2012) on Wednesday February 22 2017, @08:44PM (#470415)

    4: Systemd is an improvement! One of the things which has been a benefit is systemd. Most of the arguments against it are nonsense. The declarative file format is much easier to read and write than shell scripts since it requires less wheel reinventing. shell scripts can be convoluted and obfuscated, systemd often has a simple declaration which would require many lines of shell script dealing with PIDs and so on.

    Systemd-the-init-system has some good ideas (making cgroups easy to use and not spinning up yet another goddamn bash instance for every service). It's a pity there's no way to use just the init component without drinking the whole pitcher of "forget 'everything is a file', now everything is a dbus endpoint" kool-aid, because dbus is still an inscrutable, user-hostile mess.

  • (Score: 0) by Anonymous Coward on Wednesday February 22 2017, @09:36PM

    by Anonymous Coward on Wednesday February 22 2017, @09:36PM (#470434)

    4: Systemd is an improvement!

    No thanks, I'll continue running GNU/Linux you can keep your "improved" Lennartix.

  • (Score: 3, Insightful) by Marand on Thursday February 23 2017, @05:24AM

    by Marand (1081) on Thursday February 23 2017, @05:24AM (#470612) Journal

    One of the things which has been a benefit is systemd. Most of the arguments against it are nonsense. The declarative file format is much easier to read and write than shell scripts since it requires less wheel reinventing. shell scripts can be convoluted and obfuscated, systemd often has a simple declaration which would require many lines of shell script dealing with PIDs and so on.

    You've repeated this a few times here, so I wanted to correct this misconception about the sysv-style init. I'm probably wasting my time writing this, since you already like systemd and likely won't care, but it's an anti-sysv argument that keeps coming up and it's just wrong. Despite what you and others seem to think, init scripts do not have to be in sh, or be scripts at all. It's not an inherent requirement of sysv init and should not be used as an argument for the abandonment of it.

    Bourne-style shell scripts are what distros generally use, but it's not a requirement of the init system. At its simplest, all that's required is a program that accepts command line arguments of "stop" and "start", and can be anything that does those two things. If you want to get fancy, you can make it follow the LSB init script requirements and also accept "restart" "force-reload" and "status". There is one LSB requirement that makes it appear that you need shell scripts: LSB inits currently require a very specific type of comment block that documents dependency information that can be used by fancier inits that can do parallel booting. The expected comment block's lines start with "### BEGIN INIT INFO", end with "### END INIT INFO", and contain "# key: value" lines in between, and was chosen because # is a sh comment, so it's understandable that someone might assume sh is the only option to comply, but that's not the case.

    All that is really needed is to have a multi-line text block inside your "init script" that can be parsed. I've made init scripts in Scheme by doing something like this, for example:


    (define init-block "
    ### BEGIN INIT INFO
    # Provides: foo
    # Description: Foo
    ### END INIT INFO
    ")

    Never used the init-block symbol for anything in the script itself, it was just there for the benefit of the parser. It seems to just do something like use the "strings" command to pull out the strings, so you can even do this with binary files! Out of curiosity I tested by writing a simple init script in C, putting a multi-line string in the file that contained the init info block. It parsed it just fine.

    ---

    At this point, you might be thinking this doesn't address your argument that systemd's unit files are declarative and that's superior to having to write programs, regardless of the language. That's the thing, though: since it respects the #!/path/to/interpreter shebang format for text files (scripts), there's no reason you can't use a declarative parser with sysv-style init. You could make an interpreter that reads a systemd-esque unit file and write all your unit files in the same declarative language, just with a shebang and some LSB init headers at the top. All the boilerplate start/stop/etc. code could be handled by the interpreter itself, removing the "wheel reinventing" for inits that fit within the declarative unit file use-case.

    Advantages to this approach would be that you could easily fall back to normal init scripts if you need to do something that's beyond the scope of your declarative interpreter, you wouldn't have to keep tacking on new features to support every possible use case because you have the scripting as a fallback, it would be a lot easier to implement than rewriting everything, and you still have a tiny, battle-tested init that does very little and has a small attack surface.

    The declarative format argument is a red herring that has been used by the systemd folks to convince people that are ignorant of how init works that they need systemd to get rid of shell scripts, but that's never been the case. If that were the goal it could have been done a lot easier with a custom interpreter.