Utility Linux Distribution

[Zare]

It's right there in 5.5.1.2, the description of the unlink() call:

The major structure you use to implement that functionality and hard links need not be called an "inode," of course, but whatever you call it it's going to be effectively the same thing: file information separate from the file name so you can support files that have zero, one, two or more names.

Ofc I saw that, but I don't think it specifies what we're talking about. File information is separate from the filename in NTFS, there is ID like FD, there is struct like FILE mapped against it, I think it was FILE_INFORMATION. If you have an active handle on some path in Windows, move that file somewhere, the handle should still work - I haven't tried it.

https://flatcap.github.io/linux-ntfs/ntfs/concepts/file_record.html these are the Windows inodes

But what I couldn't find is what happens in that exact case you wrote; removing the file from one active handle and then writing data from another active handle. I don't know enough about NTFS internals but one could assume refcounting and same consequence as in POSIX.

I am not aware whether ids, file_info and file record were available, as they are described, in that version of NTFS. But in some hobby downtime I'll install both first NT and SFU Windows 7 and try out your suggestion.

Well, that makes my point. Even you use NetworkManager.

Hey, I also use systemd. And Windows. And a lot could be said about Windows

 

[Zare]

Don't ask me--I'm still using ftp and rsync. It's important to me that a backup copy exists somewhere; multiple copies preferred. Reason is that most files for me reflect physical media which may or may not still be in my custody. To this extent, I keep a spare system rsync-ed to my regular one and another with the previous week's files.

Ok I will Why is this controversial or old-school? Rsync is the prime tool for backups and SFTP for file transfers, where you can safely drop the S part if you're on LAN.
I seldom use backups (I know, everyone needs to improve and work on themselves) but when I do it's direct ZFS transfer over SSH.

 

[Bob-O-Rama]

I would recommend taking a look at one of the old versions of SUSE Linux from that time period - for example, version 7.3 with the 2.4 kernel.

They released a really slick boxed set that contained a manual, a nice installer (yast) and all the available software on CD, so you don't need a working network service for the install. SUSE was a major early player and produced, imho, one of the best distros of that era. The old boxed sets are available cheap on ebay.

Or brand new, fresh from the factory, openSUSE Tumbleweed. I am running that on several truly ancient laptops, and desktops. Works with Adapted 29xx controllers, old USB chipsets. The only thing I've found that is a problem is Transmeta Carusoe processors, some of the GUI components use unimplemented opcodes that may not be be present depending on the version of the processor's firmware - in that instance the OS boots and you can use the CLI. Older distributions do support it, however.

 

[cjs]

Ofc I saw that, but I don't think it specifies what we're talking about. File information is separate from the filename in NTFS, there is ID like FD, there is struct like FILE mapped against it, I think it was FILE_INFORMATION. If you have an active handle on some path in Windows, move that file somewhere, the handle should still work - I haven't tried it.

It seems clear to me that in NT the filename is in some way considered part of the file itself, in a way it isn't in POSIX. (In POSIX, a filename is just a directory entry with an inode number; the filename by which you access that inode number is not conceptually part of the file itself and, as I mentioned earlier, need not even exist.)

This is demonstrated by trying to rename or delete a filename that a program has opened: the OS will reject this with an error. I see this all the time on Windows. The two most common examples are with Adobe Reader (which apparently holds open the files that it's displaying) and with files that are currently being sync'd by the Dropbox client.

But what I couldn't find is what happens in that exact case you wrote; removing the file from one active handle and then writing data from another active handle.

That's not the case I was discussing. You do not need—and cannot use!—a file handle to remove or rename a filename, since that's not part of the file. (It's an entirely independent operation on a pointer to a file.) When you have an open file handle there's no way to trace that back to the name used to open it (if that name even still exists), or to any other name, other than just going through every name in the filesystem and for each one checking if the inode to which that name points is the inode of the file you have open.

Hey, I also use systemd. And Windows. And a lot could be said about Windows

I don't have any particular grudge against Windows, though I don't find it a particularly effective operating system. I'm just pointing out that the semantics of files under Windows (in particular, that a filename is, as far as I can tell, a property of a file, rather than just an independent pointer to a file) is by nature incompatible with POSIX.

I'm still very curious as to how POSIX file semantics actually got implemented in the NT POSIX subsystem, since I don't see any way POSIX semantics can work with standard Windows files without breaking Windows semantics.

 

[cjs]

Rsync is the prime tool for backups and SFTP for file transfers, where you can safely drop the S part if you're on LAN.

No, you cannot safely drop the 'S' part if you're on a LAN. For all you know, your attackers are also on the same LAN, or can get on to it.

And these says I'd suggest that the "prime" (in the sense of most commonly used) backup tool is Git. (Which is not surprising given that Git is an excellent file transfer tool.)

 

[Svenska]

File information is separate from the filename in NTFS, there is ID like FD, there is struct like FILE mapped against it, I think it was FILE_INFORMATION. If you have an active handle on some path in Windows, move that file somewhere, the handle should still work - I haven't tried it.

NTFS is fully capable of providing POSIX semantics. It was designed for that after all, because of the POSIX subsystem in early NT.

However, the Windows API does not allow you to use NTFS in such a way. So on Windows, you actually cannot provide full POSIX behaviour even though the underlying technology is able to. WSL1 implements two file system types for this reason, and still does not provide full semantics.

Windows has removed some of the most obvious limitations in recent years, but iirc you still cannot just create a file/directory, open it, delete it, create a new file/directory with the same name, open it, and use both handles.

I"m not sure what that means. I guess perhaps I was always just looking at it from a technical perspective?

My problem with systemd is not systemd, it's mostly the people who made it and their mindset.

As for the "what is UNIX" discussion... there is a single entity which owns the name and therefore decides whether something is UNIX or not. Even if it is a Linux or Windows in disguise, and even if it feels disgusting. Deal with it. From a technical perspective, only the various standards matter, and they are only interface standards. Implement the interface and you are free to request certification.

 

[Perico]

My problem with systemd is not systemd, it's mostly the people who made it and their mindset.

On the other hand, my problem with systemd is systemd itsself, I don't mind programmers being pricks if they don't f**k my ass.

Before, you were called to support a misbehaving Linux system, and you just found what the default runlevel was and what symbolic links that runlevel directory had in /etc/rcX.d

Now with systemd, you just reboot the system about a dozen times and take note of whatever "deviations" you may notice. Pure troubleshooting hell. But it is well paid, I concede that --because nobody wants to touch it with a ten foot pole.

 

[cjs]

Before, you were called to support a misbehaving Linux system, and you just found what the default runlevel was and what symbolic links that runlevel directory had in /etc/rcX.d

Which was often enough a complete mess, not to mention the interesting things that could happen with shell scripts affecting each other because they were all run in the same environment. And, of course, for those less familiar with System V runlevels, just figuring out how they were working in detail could be quite a pain.

Now with systemd, you just reboot the system about a dozen times and take note of whatever "deviations" you may notice. Pure troubleshooting hell. But it is well paid, I concede that --because nobody wants to touch it with a ten foot pole.

Well, that may be how you do it with systemd, but that's not the way you should do it. There are much easier ways of debugging startup issues that don't involve rebooting at all.

I think you've just fallen into "I know this software and I don't know that software" trap. Which is, admittedly, what a lot of complaints about System V runlevels back in the day probably were as well.

It's also worth noting that systemd was not the first system designed to mitigate the pain and suffering caused by trying to use shell scripts to start, stop and supervise system background processes. Arguably one of the first was inetd, but long before systemd there were also daemontools, runit, Supervisor, and so on.

Tons of people who used /etc/rc, runlevels or any of the above were complaining about how bad the others were, much as for the last thirty years we've had people promoting the obvious superiority of Windows/MacOS/Linux over the other two, or Vim over Emacs or vice versa, or whatever.

I've found that if someone can't point out the advantages that other systems offer, as well as the disadvantages, you can generally just ignore their criticism as uninformed.

 

[Perico]

Before, you were called to support a misbehaving Linux system, and you just found what the default runlevel was and what symbolic links that runlevel directory had in /etc/rcX.d

Which was often enough a complete mess

But whatever mess it was, it was easy to solve, because it was easy to inspect and review.

With systemd, just forget it about being easy to inspect and review - it's now a full time job.

 

[doshea]

I think systemd is fine if you take the time to figure out how it works. I think I had the benefit that figuring out how it works was a project at my work - which admittedly didn't go perfectly, but that wasn't entirely systemd's fault - where I had time to research and experiment. For most people, I suppose they start figuring out how systemd works when some critical service won't start and they've got other, better things to do.

Also I think systemd does a lot of things better than init scripts did, but they're not things that most people care about. For example if you want some automated tool to figure out whether the foo daemon is alive, you could run /etc/init.d/foo status, but not all scripts implemented that, or implemented it consistently, or even implemented it reliably. systemd can handle that better in a lot of cases, but if you're not writing a Linux-based appliance you're probably not going to care too much about that.

It seems like starting services in parallel is a good thing though. Maybe one of the other solutions like upstart (which I'm not familiar with) wasn't so offensive?

 

[Perico]

It seems like starting services in parallel is a good thing though. Maybe one of the other solutions like upstart (which I'm not familiar with) wasn't so offensive?

Not in a server. I don't want MySQL and Apache starting concurrently, but I also don't what to configure MySQL as a dependency of Apache.

 

[cjs]

But whatever mess it was, it was easy to solve, because it was easy to inspect and review.

No. I've been there, done that, and strange interactions between startup scripts sharing variables are not easy to figure out.

With systemd, just forget it about being easy to inspect and review - it's now a full time job.

Only if you refuse to look at the systemd config files, which are much simpler than init.d scripts, and refuse to use the nice tools that systemd provides to interrogate the current status of a program, find all its logs, and so on.

As for your MySQL/Apache example, it's logically inconsistent. If Apache isn't dependent on MySQL, there should be no problem with whether it starts before or after it. If you don't want Apache running when MySQL isn't running, it is a dependency, just an undocumented one that may not always take effect anyway (e.g., if MySQL appears to start but doesn't really).

There's not actually any huge problem with wanting a super-simple startup at the cost of reliability, but it mystifies me why someone wanting that would go for complex runlevels rather than a much simpler straight /etc/rc script.

 

[Perico]

There's not actually any huge problem with wanting a super-simple startup at the cost of reliability, but it mystifies me why someone wanting that would go for complex runlevels rather than a much simpler straight /etc/rc script.

It mystifies me why someone would want to go for complex systemd runtime-variable just-in-time dependencies, instead of clearly inspect-able predefined runlevel numbered scripts.

 

[cjs]

It mystifies me why someone would want to go for complex systemd runtime-variable just-in-time dependencies, instead of clearly inspect-able predefined runlevel numbered scripts.

That's because you've never looked at systemd config files and seen how much enormously simpler they are than runlevel scripts.

But I think it's telling that I was comparing runlevels to /etc/rc, which apparently you are not willing to do and consider how your arguments fare when comparing to that.

 

[lowen]

I personally find the systemd unit files simpler than the sysvinit-style unit scripts with the startup and shutdown priorities and that inflexible chkconfig comment line (what if I want different priorities in runlevel 3 versus 5? Can't do that, but bless I want the stupidity of multiple init scripts, one for each runlevel...talk about unmaintainable). Very flexible dependencies; just have to flex the old noggin out of sequential mode and into the modern parallel processing world. I started with Xenix V7 (TRS-XENIX 1.X) in the mid 80's, so I've seen all of the init systems out there. The systemd method sucks the least. IMHO.

 

[Chuck(G)]

Systemd, as wretched as it seems, is less wretched than other init schemes.

What the heck, I'm not sure why we have initialization separate from general operation today anyway. Reminds me of the restriction in DOS that said devices drivers had to be loaded at system boot time--until they didn't.

 

[Svenska]

Not in a server. I don't want MySQL and Apache starting concurrently, but I also don't what to configure MySQL as a dependency of Apache.

Sounds like you are trying to solve the wrong problem. Please take a step back and try to figure out what you are trying to do - and why.

By now, systemd supports most features one might want to wish for. Almost all daemons today either interact well enough with it or behave in a reasonably standard manner, so that it can deal with them well enough. It is easy to write reliable unit files (which are generally readable even without learning much systemd) and there is a lot less boilerplate to handle. It is much easier to administrate as well. Sure, the /etc/rc systems in V7, Xenix or Minix are easy to read, but the shell scripting hell towards the end of sysvinit definitely wasn't. It also lacked good documentation and was distro-specific.

Technically, systemd is sound (after all, it copied great ideas from other projects). But I am not happy about its developers outright disregard for other projects, their "my way or get off my lawn" attitude and their NIH issues. There aren't that many people Linus himself has specifically banned from contributing to the kernel. There is no reason why systemd couldn't support BSDs - or share daemon compatibility code at least - except for explicit developer hostility.

And I still consider PulseAudio a problem.

 

[Perico]

That's because you've never looked at systemd config files

Please, state facts or opinions, but refrain from making false statements about what you think others do or don't do.

 

[cjs]

Please, state facts or opinions, but refrain from making false statements about what you think others do or don't do.

I'm sorry. I was working on the principle of being charitable, and thus assuming you hadn't looked at systemd unit files. Since they are objectively much shorter and more clear than runlevel shell scripts, assuming you have looked at them would also be assuming that you've decided that saying the same thing in a long, complex and much more error-prone way is better than the short and simple way.

 

[bsd64]

I think all the moderators must be at the VCF East ... This thread started out with the question "Can anyone recommend a good modern(ish) linux distribution for Pentium II class machines?", and has since tried to ascertain the definitive definition of "UNIX" before moving on to discuss the relative merits of the various Linux init systems.

Thanks though to everyone involved for letting us know how you feel, for keeping it professional, and for avoiding personal attacks. Though I might recommend moving the different topics into their appropriate threads.