×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Comments

top

Systemd Adding Its Own Console To Linux Systems

Rutulian Re:it solves some unicode issues (774 comments)

1. Doing away with journald requires a replacement, because it is functionality needed by systemd. No suitable replacement exists. Therefore, it can't be replaced. Why is this so hard to understand? It has nothing to do with being modular or not. Just because syslogd is a logging daemon and journald is a logging daemon doesn't mean the two are interchangeable. If that was a requirement for modularity, we would never be able to develop new interfaces. The syslog API was developed in the 1980s. At some point, the systemd developers decided they couldn't do everything they needed through the syslog API alone, so they developed a new API and journald to go with it. So yes, it is modular, but no you can't replace it because no suitable alternative exists. If you need further elaboration, consider the Unix userspace before multiple syslogd daemons were available. There was the syslog API, but only one syslogd daemon. Since you can't run a functional system without logging, this effectively required you to use syslogd. Does that mean syslog/syslogd was not a modular system until rsyslog and syslog-ng came out? No, of course not.

2. I see you make no effort to elaborate your argument beyond saying "no, you are wrong." The reason for lack of alternatives is that nobody has developed them. I stand by that statement. However, there is starting to be some movement on that front, with efforts by the BSD folks, for example, to port the logind functionality over to BSD so that software that depends on it can use it. Likewise, if you wanted to write a logging daemon that provides the functionality that systemd needs without, for example, using a binary file format, you could do that and I am sure you would have no problem replacing journald with it.

about a month and a half ago
top

Systemd Adding Its Own Console To Linux Systems

Rutulian Re:it solves some unicode issues (774 comments)

The original point of this thread was that the 69+ individual binaries that systemd builds was an example of being monolithic, with claims by various people that you are forced to use all of them and none of them can be replaced. That is false, and that is the origin of my statement above. Journald cannot be disabled with a compile-time switch, unlike the others. Strictly speaking, this does not mean it is monolithic. Journald communicates with the rest of systemd via well-defined, albeit some in a state of flux, APIs (that is the definition of modular, in case you were wondering). The reason why the developers have not made journald optional is because no currently available syslog variant can replace the functionality of journald, so why bother? Since systemd needs something like journald to function, and journald is currently the only available option, make it a hard dependency. Maintaining backwards compatibility with syslog is not a requirement for modularity.

If I am wrong, it matters to me.

Glad to hear it.

about a month and a half ago
top

Systemd Adding Its Own Console To Linux Systems

Rutulian Re:it solves some unicode issues (774 comments)

Why does it matter? Journald cannot be separated from systemd because it draws on many features to gather the information it needs, such as to verify timestamp and authenticity, for example. Systemd is dependent on journald because it needs a logging facility that provides information (indexed and organized by process) in a way that no other logging facility currently does. So yes, this is monolithic because they can't be separated. One might ask if they could in principle be separated. Maybe. It depends at least somewhat on the rational for doing so.

With respect to syslogd, journald communicates all logging information to any external logging daemon via a socket and a well-defined interface. It also gathers logging information from userspace processes via the syslog API. So by definition, journald is modular in this sense (it communicates with other processes via well-defined interfaces). The fact that journald must relay logging information to syslogd is a consequence of listening directly to /dev/log, which prohibits syslogd from doing so. Is this bad? It depends on your perspective.

Why should one lose the ability to view non-corrupted [freedesktop.org] text logs from bootloader just to get an init replacement?

You don't lose that ability. Why do you think that? The bug report that you linked to is about a different issue.

about a month and a half ago
top

Systemd Adding Its Own Console To Linux Systems

Rutulian Re:it solves some unicode issues (774 comments)

I understand that monolithic is a moving target of criticism for people who don't like systemd.

about a month and a half ago
top

Systemd Adding Its Own Console To Linux Systems

Rutulian Re:it solves some unicode issues (774 comments)

The journal is part of the core of systemd, so as such it cannot be removed. Why? Well, in short, syslog does not provide the functionality systemd needs for certain things. So yeah, you can call that monolithic if you want...if you also want to say that you can't remove the shell and still have sysvinit work, therefore it is monolithic. That said, the reason why the journal must pass messages on to syslogd is because only one service is allowed to listen on /dev/log, so nothing like your emacs example. Most of the rest of systemd is entirely optional.

about a month and a half ago
top

Systemd Adding Its Own Console To Linux Systems

Rutulian Re:it solves some unicode issues (774 comments)

They are not all required at the same time. Where are you getting your information?

about a month and a half ago
top

Systemd Adding Its Own Console To Linux Systems

Rutulian Re:it solves some unicode issues (774 comments)

Each of the individual binaries cannot "be combined or interchanged with others like it to create different shapes or designs", which means it isn't "modular", but is "monolithic".

Yes...you...can! That is the whole f$@%@#$ing point of having multiple binaries! Where do people come up with this crap?

What you might ask instead is, why do no suitable replacements exist? Because nobody has written them....

about a month and a half ago
top

Choose Your Side On the Linux Divide

Rutulian Re:My opinion on the matter. (826 comments)

Oh sure, I get that. You are absolutely correct. Proper monitoring requires making sure people can use the system for what it was intended for, not just publish artifical uptimes. The only point I was trying to make here is that systemd allows you to obtain status about running (or not) processes, memory/cpu usage, log events, dbus events, hardware events, forking, open ports, etc, that could be obtained before, but only in roundabout ways with specialized daemons. Systemd now provides a standardized and centralized infrastructure for doing all of that. It does not replace the need for monitoring tools, it just helps them do their job. And it makes containerization and automatic provisioning much easier.

about 3 months ago
top

Choose Your Side On the Linux Divide

Rutulian Re:My opinion on the matter. (826 comments)

True, systemd doesn't do monitoring per se, but it provides the infrastructure to do monitoring easily. Both Ganglia and Nagios rely on either a daemon installed that can collect data and report it, or on polling ports and such. Neither is really integrated into the system the way systemd is. I'm sure both projects will benefit greatly by their ability to now use systemd features for much of their work.

about 3 months ago
top

Choose Your Side On the Linux Divide

Rutulian Re:My opinion on the matter. (826 comments)

Well, it does kind of both in that you can join the public NTP pool, or maintain a private NTP server for your network with ntpd. Bottom line though is it's way overkill for what most people need. Your run of the mill server/desktop just needs a simple NTP client, which systemd-timesyncd is.

about 3 months ago
top

Choose Your Side On the Linux Divide

Rutulian Re:Better question (826 comments)

News to me. Ubuntu Gnome is working just fine without systemd on my desktop right now. They do plan on switching to systemd in the next release, but that is a separate issue.

about 3 months ago
top

Choose Your Side On the Linux Divide

Rutulian Re:My opinion on the matter. (826 comments)

If you don't have a setup system that establishs monitoring automatically and without manual intervention on all new systems

You do understand why systemd was created, right? To do exactly that! You may be proud of your collection of hacked together bash scripts, or maybe you use a third-party tool to do it, I don't know, but some of us think this capability should be a part of the OS itself. And now it is, thanks to systemd.

about 3 months ago
top

Choose Your Side On the Linux Divide

Rutulian Re:My opinion on the matter. (826 comments)

It's not just about auto-restart after crash. When the system knows something about its state, it can manage that state. So you can have a rule set that defines what to do when a particular service crashes. Or you can automatically start and stop services in response to system load. Tools like Puppet and Chef will have an actual infrastructure to use instead of needing to resort to a million polling hacks to do their job. There are a ton of reasons why it may be advantageous for the system to know something about its state (hey, I managed to do that without saying "cloud").

about 3 months ago
top

Choose Your Side On the Linux Divide

Rutulian Re:My opinion on the matter. (826 comments)

Even things as far removed as NTP functionality are now rolling into systemd (did you know systemd is trying to replace ntpd?).

You do realize that most distributions do not enable ntpd by default, right? And that the primary use of ntpd is for running an NTP server not time synchronization to an NTP server, right? Most distributions simply run ntpdate in a startup script to do a quick sync of the time/date during boot. So all systemd is doing is daemonizing the same functionality.

Reinventing APIs radically - The big case here is the basic OS interfaces for networked daemons.

It really isn't. It is providing additional functionality that applications can choose to use, or not (hence why some applications have dependencies on systemd). Nothing about POSIX has been deprecated with systemd. It just happens that the methods systemd provides are often more efficient or have other advantages (ex: monitoring), that you can't get with a bunch of random init scripts. So people want to use those features (surprise!).

For example, a traditional *nix daemon might be capable of managing its daemonization in an advanced way with the flexibility of the POSIX APIs (e.g. allowing a controlled 'restart' behavior for reducing downtime that starts a new daemon overlapped with the old one and uses some IPC to coordinate the handoff of live sockets, etc).

What you're basically saying here is that you can hack the POSIX socket implementation, but with systemd you have to do it differently. That is not really an argument about anything. If what you meant to say is that with systemd there is no way to manage service restarts with minimal downtime, that is completely false. The fact that you have to learn how to use systemd does not obviate its usefulness.

Also, a full conversion of a system to systemd doesn't work well with just leaving some daemons as traditional sysv-init style

Define "doesn't work well." Every distribution that implements systemd already does this, and probably will for the indefinite future because there is a lot of software out there that doesn't (and may never will) use systemd services.

It introduces a new latency in exposing new APIs.

The different ways that you keep using the term API makes me think you don't know what an API actually is. The ways in which APIs will be available to applications will not change with systemd. If systemd provides an API that an application wants to use, then it will of course depend on systemd, but that is really it. What you might be referring to is that systemd provides a bunch of new APIs that parallel kernel and glibc APIs, but doesn't really change the way APIs are developed or exposed to applications.

In general, while they minimally accommodate server-side daemon software, most of the development focus of systemd is for the desktop user's use-case.

This just keeps getting repeated. It's like a self-referencing Wikipedia article. Just because somebody said it doesn't mean it's true. Can you point to a whitepaper or design document somewhere that says "systemd is primarily developed to support desktops"? It's complete BS. Look, just take a minute to determine what Red Hat's primary market is. Hint: it is not the desktop. If it isn't obvious to you why systemd is great for servers, and in particular large systems of servers that regularly communicate with each other, need to be monitored remotely, and need to be completely auditable, then you have never really worked seriously with servers. You may be the kind of guy that likes to script your own toolkit to provide the functionality that sysV lacks. That's fine, but don't pretend systemd doesn't solve problems for servers. It does, a lot of them.

systemd, in spite of seeming to want to completely encapsulate or replace large swaths of well-regulated APIs from POSIX, doesn't seem to have any real version control, changelogging, or version/feature -querying capabilities to manage compatibility of this new pseudo-API.

Well, I agree that that would be nice to have. But I think they are really aiming for two states: stable interfaces and interfaces under development. The stable interfaces are stable and won't change, so you don't need to check version. The interfaces under development can change, but won't change indefinitely. So you can either wait until they stabilize, or stay on the mailing list and keep an eye on it. They probably don't think a "capabilities" call is necessary because they don't anticipate having a lot of different versions with different features.

Total disregard for everything outside of Linux,

You might be right about that. But then again, the BSDs and other Unixen have plently of their own features that are unique to them. It doesn't have to be a portable standard, but it does add another consideration to applications that may or may not care about portability.

about 3 months ago
top

Researchers Discover New Plant "Language"

Rutulian Re:Communication? (70 comments)

FYI, the scientists who did the work did not report it as "communication." As usual, the popular science writers were a bit over zealous in their choice of words.

http://www.phdcomics.com/comic...

about 3 months ago
top

Comparison: Linux Text Editors

Rutulian Re:depends on what you're doing (402 comments)

My guess though is that you "hate vi" because it's strange and foreign to you and if you humbled yourself, took the time to learn some simple, easily memorizable things you'd probably change your tune.

No, it's really that I already have to know and be familiar with a number of things. I've used vi, very frustratingly, maybe three times. I don't care to spend more time learning it because i see it's complexity as just completely unnecessary. When I already have to know how to configure a dozen different services off the top of my head, manage cross-distribution complexities, script in half a dozen different languages, and keep up with new stuff coming out every month, the last thing I need is to keep a bunch of completely non-intuitive random letters and symbols in my head to do very basic every day things. I'll stick with nano, thanks.

about 4 months ago
top

Comparison: Linux Text Editors

Rutulian Re:depends on what you're doing (402 comments)

Simple 3x5 card with the commands on it is all you need to be proficient enough to get most things done. Hell, a Post-It note would do.

That's just the point. I shouldn't need to refer to a reference sheet, notecard or otherwise, to edit a bloody text file!. I shouldn't need to spend two hours learning the difference between !#*$ and ?!$& just to go between a bunch of nonsensical modes (view, edit with insert, edit with overwrite, edit the end of a line, edit the middle of line, blah blah blah) in vi just to edit a text file. It is retarded.

With nano, you have a basic intuitive text editor. Navigate with the cursor keys (amazing, imagine that!), edit with backspace, delete, and just type letters to insert them ( more shocking things). When you need to save and quit, there is a help text at the bottom of the screen, Ctrl-x. That's it and that's why I like nano and hate vi. On top of that, nano is small and efficient and easily fits in a minimal environment. There is really no reason to not have it as a default text editor in any distribution.

about 4 months ago
top

Comparison: Linux Text Editors

Rutulian Re:depends on what you're doing (402 comments)

However, as an admin, I have long ago standardized on VI for the simple reason that it's included by default on every single *nix variant out there. (At least, in my experience.)

While true, in my experience there is no reason why nano could not be included (and should be).

about 4 months ago
top

Valencia Linux School Distro Saves 36 Million Euro

Rutulian Re:TCO (158 comments)

(though Linux does have non-stock application deployment packages available, like Puppet, that partially fill that last point).

You're kidding right? In addition to Puppet, which is a relative newcomer, there has been Satellite (http://www.redhat.com/products/enterprise-linux/satellite/) and Landscape (http://www.ubuntu.com/management/landscape-features) among others (Suse has one too). Where do you think the distros make their money? Now you may have meant there is no free application deployment and management software, but last time I checked Windows Server was definitely not free. If you need free, though, you can roll some scripts fairly easily, wrapping things like Kickstart with custom repositories (yum or apt) and services like Cobbler or Spacewalk (which Satellite is based off of), rsync, cron jobs, and ssh (for remote execution).

Linux AD-via-Samba quite simply doesn't even come close for the convenience of centralized GP maintenance,

I don't know what you are trying to say here. Why would you manage linux machines with a Samba domain? If you want the same functionality as AD on linux, FreeIPA is the most mature project, and it can integrate with AD via cross-realm trusts in the latest version. So you can manage a mixed Windows/Linux environment with the same core infrastructure. If instead you meant Samba as an AD domain controller for Windows, Samba4 is (mostly, 95%) a drop-in replacement for Windows Server. There are a few features missing, but you can provision and manage an AD domain via Samba with ease.

about 4 months ago
top

Ask Slashdot: Linux Login and Resource Management In a Computer Lab?

Rutulian Re:FreeIPA (98 comments)

Well, if it's linux, FreeIPA is better because then you can take advantage of group policies that are designed to work with linux. If you use AD, you will get authentication and that's about it. Now if you have windows+linux it's a bigger problem. In our lab we went with AD forsaking the advantages of FreeIPA for our linux users, but you could also set up both servers with a shared trust. It's a bit more complicated, but this is something RedHat are trying to develop into a turnkey solution.

about 4 months ago

Submissions

top

Can you trust Wikipedia?

Rutulian Rutulian writes  |  more than 4 years ago

Rutulian (171771) writes "The somewhat provocative title is a quote from an article in the Boston Review that discusses some of the history and current happenings in Wikipedia world. The fundamental questions are "What makes Wikipedia work?" and "What is needed for Wikipedia to continue to thrive in the future?" Some excerpts from the article,

Most inclusionists were not extremists: they did not favor articles on that morning’s breakfast. But in a vast range of cases, they thought that limited and imperfect information was better than nothing. Deletionists disagreed, and to resolve the many borderline cases, the community had to find an objective and quantifiable metric for discrimination. Neither cash nor file-size could do the job, so they settled on the principle of notability: “a topic is presumed to be notable if it has received significant coverage in reliable sources that are independent of the subject.”

In many cases, however, notability cannot be determined even by following thoughtfully developed guidelines. It is, for example, much harder to verify the notability of a figure from the 1920s than from the 1990s. Most of the important characters of that earlier era are gone from public memory, and newspaper archives from those days cannot be accessed easily online (where Wikipedians spend most of their research time). Given that the flow of articles on Wikipedia far outweighs the attention span of its editors, the latter often have to make the same tough choices that print editors do: why waste a day improving one hard-to-nail-down article when one can improve a hundred?

Any thoughts from the Slashdot crowd?"

Journals

Rutulian has no journal entries.

Slashdot Login

Need an Account?

Forgot your password?