johnwfinigan

Besides, probably the best way to find out if it's a "big deal" is to ask your sysadmins. Or, generally, the people who are going to be stuck running it.

A great example in my opinion: Red Hat RHEL7 introduced systemd. A lot changed versus RHEL6. RHEL6 "experts" turned into clumsy RHEL7 "80%-ers". We figured it out.

Not to even mention that SuSE, RHEL, and Ubuntu are about as similar as "Linux" and FreeBSD, if you are worried about the finer points of best practice. We figure it out.

    ls | tr '\n' '\0' | xargs -0 rm

That's pretty specific to the more or less sequential approach with the book, though. It's a good book, so it can support that kind of thing.

I think it will also help with presenting the supplemental material that is linked with each chapter/section. Again, that might be specific since in the Stevens book, there is always a manpage or Single UNIX Specification reference to give for almost any section.

By the way, your article has encouraged me to get the students using issues for eg. homework questions they'd normally email, thanks for that.

I like to write code in class, and it's great to be able to push every couple of minutes so students can follow along on their laptops if they want. Of course that's more about git itself, but the GitHub interface is good and I think that it lowers the frictional cost for both me and the students, so everybody gets a little more done.

Has a lot of rules of the form "Do Not ..."

I have seen the binary translation in action: it was required when POWER6 machines came out. On a POWER5 machine, I remember it taking around 20 minutes for an application that was around 20 MB zipped, but for software licensing reasons not all of the server models exposed the full performance of the processor, so that might not be representative. And at any rate, like the OP said, it's a one time thing, and then the translated version is kept.

I think it is important not to forget these people, but aside from that, no answer here.

After 32-bit Windows Server went away as of 2008 R2, I didn't expect MS to keep shipping 32-bit client for this long. Anybody have a convincing argument as to why? 16-bit legacy apps in large businesses?

Obviously it's not free to do this, especially since they'll be producing every patch for two PC platforms for probably another decade.

On the storage side, I can't help but wonder if it's partially due to incumbent vendors pushing flash as a high markup premium product. I suspect that I am not the only one who has thought, "Well, why replace this array with more already-obsolete magnetic disk that won't be any faster? Wait a year or three, flash markups will come down. Maintenance renewal is cheap."

Now, I realize that cheap flash is dangerous to incumbent pricing structures, so $100K for an all flash tray makes sense when it can replace 10 trays of $30K disk. So maybe they've seen no other choice, business model wise. Maybe it even makes sense to milk a once-per-generation technology disruption for all it's worth for a couple of years before commoditizing it.

But it has kept me happy with what I've already got, since the pricing of the alternative was, for my use cases, hilarious. As opposed to, say, this is somewhat more expensive but we can justify it.

I think that, for multi-million dollar mainframe timesharing systems, it was easier to make the cost argument for good security, since the customer would pay for it so that they could spread out the cost of the machine on many users, between whom there was no trust.

But once you got $100k minis and $10k single user micros, why not just buy a second machine?

Of course, things turned out a little bit differently, but from a time before the ubiquitous internet, I can see it making sense to many people.

It's amazing how much more diverse the hardware/OS ecosystem was in say 1985 than it is now. A lot of good stuff has happened since then, but I think a lot of good ideas got lost, or at least are waiting to be dug up again.

Tangentially, I'm more fascinated by the fact that Paul Karger, the lead author on [1], was a principal on a Class A1 secure hypervisor for the VAX, which DEC essentially finished, but cancelled in 1991. [2]

[1] - see paragraph 3.1 - http://hack.org/mc/texts/classic-multics.pdf [2] - http://www.cs.dartmouth.edu/~ccpalmer/classes/cs55/Content/r...

Note to anyone trying to image old Sun CD-ROMs: anything below Solaris 2.4 (?) is a CD-ROM with a partition table. If you dd out /dev/cdrom on Linux, you may get only the first partition, in ISO9660 format. You will be missing the small UFS boot partitions. There should be one small UFS partition for each supported arch.

Seems like using /dev/sr0 on Linux works.