Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:Great... (Score 1) 52

by Rutulian (#49272239) Attached to: New Compound Quickly Disables Chemical Weapons

The destruction of a chemical weapon is rather trivial, when you can conveniantly dunk the toxin in a vat of acid, or base, or solvent or whatever. Dioxins burn really well, for example.

Maybe, but spraying acid everywhere is not really a viable decontamination strategy. This catalyst is not for destroying stockpiles, but for helping with decontamination. Previously they were using an enzyme that is hard to deploy, and they've replaced that enzyme with an engineered catalyst that does the same chemistry, albeit less efficiently. Hopefully it will get better with further refinement.

Comment: Re:Driver model (Score 3, Informative) 199

by Rutulian (#49144719) Attached to: The State of Linux Gaming In the SteamOS Era

I suppose by "nobody" you mean "everybody except nvidia"? Because the nvidia binary blobs are pretty much the only drivers that occasionally have problems with kernel updates due to the way they really mess around deep into the kernel (ie: they implement their own drm code and X api). With Nouveau finally starting to mature, this is thankfully becoming less and less of a problem. But pretty much every other driver (proprietary or otherwise) seems to work just fine with the linux driver model.

Meanwhile a Windows user can buy a PC and have the drivers that come on the system run for the ENTIRE LIFE of the system, I can take a copy of XP RTM, install the drivers, and then run it through the entire life of the OS, 3 service packs and countless patches, know how many drivers will be non functional at the end? NONE, that is how many drivers will be broken at the end and THAT is what you are competing against, and failing miserably!

So, are you saying that over the life time of your system (what is that, say 6-7 yrs?), you never update the drivers? What do you think a service pack is? Nevermind. Anyway, it doesn't matter because you are wrong. SP2 broke a lot of XP drivers (and software for that matter), including the nvidia driver. Yes, you can now download an updated nvidia driver that works, but at the time of the SP2 release the old nvidia driver did not work on SP2.

Comment: Re:Could be a great update! (Score 1) 115

by Rutulian (#48579181) Attached to: FreeNAS 9.3 Released

Meh, I played around with FreeNAS for a while. I originally thought it was neat, but I kept having problems with it and eventually realized that it was easier to just set everything up myself. The GUI didn't offer that much in the way of ease of use. A short list of my observations.

1) FreeNAS makes it dead easy to set up ZFS...but ZFS is actually pretty easy to setup on its own. Easier than RAID/LVM by far. So no huge gain there, in my opinion.

2) FreeNAS makes it so you don't really have to learn the ins and outs of FreeBSD, but zfsonlinux is fairly mature and works well, so not a big deal for me.

3) This may be my linux bias showing, but FreeNAS is limited by the capabilities of FreeBSD. Hardware support is the biggest one (controllers, nics, etc). For example, plenty of Dell hardware won't work optimally. Also, what the fuck did they do the PAM? Lots of functionality missing (kerberos password changing, mkhomedir, etc). The version of SCP seems to come from a stone age that doesn't know about directory recursion. Just lots of little things that really annoyed me. No NFSv4 support. Seriously, this is like 10 yrs old now, and you still can't authenticate NFS users over Kerberos if you are using FreeNAS. Maybe it is fixed in this version, but not in 9.2.

4) Some aspects of the UI were nice (ex: being able to easily to see appropriate ZFS flags) and other not so nice (ex: the snapshot interface). Yes, FreeNAS supports the ability to replicate ZFS, but this requires a cumbersome setup that even involves saving your ssh private key into the UI (maybe they have changed this since then). It's easier to just set this up in a cron job on your own, in my opinion.

5) FreeNAS makes some things very easy, but if you need to do anything differently, it's a pain to work around the UI. The settings are saved in a special database that writes config files on the fly, so you have to know what to edit to make a change. I spent a lot of time making FreeNAS talk to our domain controller and enumerate groups correctly, because the UI had a generic way that didn't work with our schema and there was no way to just change the necessary settings.

Bottom line: if you want to get a quick NAS running to use as a media server, FreeNAS works pretty well. But if you have special hardware or integration needs, you can probably achieve everything you need much easier by just configuring everything by hand.

Comment: Re:it solves some unicode issues (Score 1) 774

by Rutulian (#48120913) Attached to: Systemd Adding Its Own Console To Linux Systems

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.

Comment: Re:it solves some unicode issues (Score 1) 774

by Rutulian (#48113519) Attached to: Systemd Adding Its Own Console To Linux Systems

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.

Comment: Re:it solves some unicode issues (Score 1) 774

by Rutulian (#48106481) Attached to: Systemd Adding Its Own Console To Linux Systems

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 [] 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.

Comment: Re:it solves some unicode issues (Score 1) 774

by Rutulian (#48102787) Attached to: Systemd Adding Its Own Console To Linux Systems

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.

Comment: Re:it solves some unicode issues (Score 1) 774

by Rutulian (#48094627) Attached to: Systemd Adding Its Own Console To Linux Systems

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".! 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....

Comment: Re:My opinion on the matter. (Score 1) 826

by Rutulian (#47764605) Attached to: Choose Your Side On the Linux Divide

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.

Comment: Re:My opinion on the matter. (Score 1) 826

by Rutulian (#47756295) Attached to: Choose Your Side On the Linux Divide

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.

When some people discover the truth, they just can't understand why everybody isn't eager to hear it.