Slashdot Mirror

Those are "the systemd requirements for the filesystem", what systemd needs. It provides no clarity about what goes _in_ those directories, nor why,

Yes, those are the basics for systemd to work. Again, rather simple requirements. It doesn't state what goes into what, because this is something the distros dictate, not systemd. The systemd developers can merely suggest where to put things, but distros won't necessarily follow those suggestions.

systemd is designed with different distro policies in mind, so they provide "Presets" to help facilitate the different policies and needs of different distros:
http://freedesktop.org/wiki/So...

Compare this checklist with the actual FHS documents, and you'll see the distinction. The result is confusion, such as the systemd migration of "/media" attachable storage to the individual user's owned subdiroectories in "/run".

The FHS is primarily concerned about directory layout, not so much the content of these. And there is nothing in FHS 3.0 that contradict the slightest that user attached storage is mounted in the /run hierarchy.
All such disc layout reorgs of the distro I have tried, have been discussed on mailing lists etc. before they are implemented. Again, this is something the distros dictate, not systemd.

Allow me to restate your comment:

> Systemd will continue to work for Linux distros that don't care for stateless boot etc

Rather, systemd will continue to re-arrange, and break, stable subsystems without warning to the user communities.

Come on. It is the distros that dictates exactly what features systemd have turned on, and how the FH layout is. There are no systemd developers sneaking into the distro repos at night and secretly turning on features without documenting them.

You may not follow the eg. development mailing list of your distro where such things are discussed, nor care about reading release notes. But Linux distros have always evolved this way, with new ways of doing things, often from release to release.

OTher examples abound. For example, the new replacement for /etc/resolv.conf says at http://www.tin.org/bin/man.cgi...

Note that /run/systemd/resolve/resolv.conf should not be used directly but only through a symlink from /etc/resolv.conf.

I fail to see how this in any way breaks any stable subsystem.
1. systemd-resolved is an entirely optional feature. If the distros don't want it, they can just turn it off.
2. Whatever its /etc /run requirements is, this is a new feature, not a change of something old and stable. So it doesn't break anything at all.

I really don't think you can give just a single non-contrieved example of how systemd are breaking stable subsystems for users without warning.

While more documentation is always better, I think the systemd project is way better documented than most other software projects, and certainly much better documented than many people think it is.

I'm not even going to mention what happens if you accidentally follow generations of sytem standard behavior and install NTP alongside an active systemd NTP daemon. It's not a pretty site, and the accumulated clock management confusion if they're not pointed to the same NTP servers can break Kerberos authentication in startlingly short order.

Running two NTP-clients at the same time was an amazingly stupid thing to do even pre-systemd. AFAIK, systemd per default tries to avoid this by using "conflict" statements in the service files, so if one NTP client or daemon is run, the others are suppressed.
I don't think eg. SysV

The Volkswagen Beetle from the Woody Allen movie, "Sleeper"

        http://www.tin.org/bin/man.cgi...

More realistically, some chemical batteries, such as good lead-acid batteries in cool, dry climates will retain a slight charge for years. But they all have a notable self-discharge rate of at least a few percent a month. The notable exception among battery technologies seems to be this:

        http://en.wikipedia.org/wiki/O...

That device has been running off its battery, at an extremely low rate, since 1840. The bell is much softer now, but it shows no signs of failing.

Those are "the systemd requirements for the filesystem", what systemd needs. It provides no clarity about what goes _in_ those directories, nor why, Compare this checklist with the actual FHS documents, and you'll see the distinction. The result is confusion, such as the systemd migration of "/media" attachable storage to the individual user's owned subdiroectories in "/run".

Allow me to restate your comment:

> Systemd will continue to work for Linux distros that don't care for stateless boot etc

Rather, systemd will continue to re-arrange, and break, stable subsystems without warning to the user communities. OTher examples abound. For example, the new replacement for /etc/resolv.conf says at http://www.tin.org/bin/man.cgi...

          Note that /run/systemd/resolve/resolv.conf should not be used directly but only through a symlink from /etc/resolv.conf.

Who's going to maintain the symlink? If any sysadmin unsuspectingly edits that file directly and breaks the symlink, or exposes their system to puppet, cfengine, chef, or any other system tool that manages /etc/resolv.conf, does it break the link? And what restores the link if it's broken? If the link is broken, DHCP updates to /etc/resolv.conf will no longer be effectively published by the sytemd based DHCP client.

I'm not even going to mention what happens if you accidentally follow generations of sytem standard behavior and install NTP alongside an active systemd NTP daemon. It's not a pretty site, and the accumulated clock management confusion if they're not pointed to the same NTP servers can break Kerberos authentication in startlingly short order.

It was in a college/university computer lab (not CS') with an old /. member from our college days. He showed me Linux (Red Hat? Slackware?) and telnet (no SSH yet). I fell in love with the text mode programs like Tin (still use it and test some builds for Urs, the maintainer). I also used Pine, SLiRP, TIA, FTP, etc. on a production machine for school's e-mail services on 14.4k - 56k (only up to 28.8k) dial-up (useful for text modes!).

I did not run Linux on my own computers until 486 DX2/66. Then, I got stuck with the Red Hat Linux v6.1(?)'s Disk Druid because I didn't know about disk partitioning and stuff. I was scared too. Finally, I got through it with a dual boot setup. Then, I didn't do much. Got bored and frustrated. Then, came v7.1(?) and loved it. Had an extra box for it to be run it for 227 days of uptime because no more Kernel updates and stuff. Then, came Debian which was even better and still use it today.

I noticed I like all computers and OS': Apple and its Mac OS X, PC with Windows, DOS, and Linux.

Also, don't forget to set the kernel flag that enables the leap-second code. It's quite likely that this was the cause, and the kernel won't know by itself that it should insert one. See adjtimex(2) for more information.

It's definitely possible that some program couldn't cope with time jumping back. Actually, it may be just as easy to just test this by manually stepping back in time.

Not really it looks like the DragonflyBSD folks added the Debian patches and these are not to be found in the OpenSSH sources. But that is sort of a joke actually. The tool is called ssh-vulnkey, and you can find a patch for it here:

http://people.debian.org/~cjwatson/openssh-blacklist.diff

There is a man page for it, here is an online version:

http://www.tin.org/bin/man.cgi?section=1&topic=ssh-vulnkey

What it does is a binary search of key files against /etc/ssh/blacklist.TYPE-LENGTH files. It can be used to hunt for bad known weak keys. You can download the blacklist files here from debian:

http://ftp.de.debian.org/debian/pool/main/o/openssh-blacklist/openssh-blacklist_0.1.1.tar.gz

The README describes it better (I had to trim the junk characters):

This package contains a set of default SSH keys that were known to have
been generated during the time when the Debian OpenSSL package had a
broken Random Number Generator.

The source package contains the full fingerprint of the vulnerable keys
in blacklist.RSA-2048 and blacklist.DSA-1024. The installed package uses a
partial fingerprint for identifying the keys by stripping off the first 12
bytes of the fingerprint.

Also there is a new feature of the patched sshd that searches the blacklist files for matches. It can be disabled by the 'PermitBlacklistedKeys' option to sshd.

So the reason that this is funny is that how this works is that there is a list of known weak keys. If some user generated a ssh key pair on an affected Debian box, you're affected and the blacklist won't do you any good.

The output is pretty clearly that of a shell script being executed with 'set -x'. There's quite a bit of debug output there; aside from that, it seems to be doing little aside from setting a few environmental variables.

The ldd call would make sense for debug output, but interestingly it doesn't print anything like what ldd would. In fact, it likely isn't the usual ldd(1), but another binary that happens to have the same name; especially since the debug output stops there, suggesting that it didn't return and the following output was generated by that ldd process, or its children.

The Debug output could have been deactivated with a 'set +x', but before the deactivation went through that command itself would have been printed, so that's out. What is possible, though, is that the ldd was in fact the last command executed in a subshell, and the parent (which wasn't even necessarily a shell), wasn't set up to produce that kind of debug output.

A search for "seatapps" brings up very few results, those apparently being first-hand accounts of people who have seen similar screens during a flight, suggesting that the whole setup, as you suggested, highly specific and non-standard.

Last time I was reading USENET (some years ago), I was using TIN.

Ade_
/

If you can live until 2020, you will be able to live until 2040. And if you can live until 2040, you will be able to live forever.

I could easily imagine a productive environment based around GNU screen and a terminal-based editor, mail client, news client, and IM client. Throw in something like w3m, and other for images, its good.

Yup, that's pretty close to the way I've worked for most of the last year or two. For me it's screen, of course, along with:

• editor - vim,
• mail client - mutt,
• news client - tin,
• web client(s) - a combination of w3m, lynx, and wget for most downloading tasks,
• spreadsheet - sc, which is surprisingly useful,
• P2P client - mutella, though I think there are console options for other protocols,
• IM/IRC client - irssi along with the fantastic bitlbee (and if you haven't heard of bitlbee before, take a look).

...and then I use good 'ol ratpoison for my window manager in X for the occasions that I need graphics (ie. some web browsing, viewing PDFs, playing graphical games).

Strike that. In most cases, multi-tasking can be very counterproductive. Shell escapes and $EDITOR_OF_CHOICE is good enough.

It varies :-), though I agree generally speaking. I'm using KDE3.2beta at the moment for a bit of a change, though most of the action is still inside my screen(1) terminal(s). You do tend to (or at least I tend to) find yourself more productive when you don't have stray graphical bits and pieces around the place to distract you.

Of course if you need the GUI for your normal working environment (ie. you're developing a GUI app), then, well there's not much you can do but live with it. :)

Except when I'm reading newsgroups with tin.

At least, that's what I always say. I've used tin for ten years now (ever since 1.11PL2), and still is IMNAAHO the best text-based news client.

tin is menu-based, with lots of useful options (and not bloated with irrelevant stuff). The basic usage is very simple, and is pretty configurable. If you have a shell account in your ISP, it's the ideal choice.

That's it... I've put it off for too long, I'm switching to Mutt (from Pine).

Sure, the functionality and the control are nice and all that, but dammit, that little dog on their FAQ page is so doggone (pardon) cute.

Guess that means I'll have to switch to Tin too...

But I won't miss having to go around my ass to get to my pgp-encrypted elbow.