johnwfinigan

.tar.zst - I have found Zstd to be enormously faster than gzip, bzip2, or xz. Its compression ratio is good and it's available in most Linux distros.

On that basic point, I agree -- although there are advantages to swimming upstream sometimes. Otherwise, given the landscape of 10-15 years ago, we'd be having this discussion about Windows servers instead of Linux!

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.

Experts have to get made somehow. It's not as if Linux is a frozen target where you can count on being "productive and community standard-compliant without any effective lag time" without going back to the docs sometimes.

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.

Excluding filenames containing newlines, I wonder how many weird corner cases this would reveal:

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

Sure. Basically, we go through the first half or so of Stevens' Advanced Programming in the UNIX Environment fairly sequentially. My first take was to group the example code by topic, but I've realized that it might make more sense to group it by book chapter. So that's my current reorganization plan. The thought is, with lots of topics, it will help orient people better if they have an explicit cue for what chapter to review if they are confused.

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.

I am definitely feeling that: I've already had to do some reorganizing as I discover that some of my initial decisions weren't perfect, as to organizing the class repo.

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 teach a college UNIX systems programming class. This semester I decided to switch to GitHub, and so far, I can't believe I didn't do it earlier.

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.

I have actually used daytime for a "real" use: as a quick and dirty way of eliminating the possibility of guest clock drift when running benchmark scripts inside of emulated guests with unreliable timekeeping. Obviously a bad idea for benchmarks measured on the order of seconds, but probably fine for benchmarks running for hours. ntpdate -q would probably work just as well though.

https://www.securecoding.cert.org/confluence/display/c/SEI+C...

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

Only on topic regarding interesting 1970s OS design, but does anybody have a reference with a similar level of technical detail to this one, but for the ICL (now Fujitsu) VME operating system?

The book "Inside the AS/400" has some really cool exposition on the unique aspects of the AS/400. If I remember right, the disks and memory are in a single address space, and of course, there is a relational database built in to the operating system.

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.

In the last several months, I listened to the Hardcore History podcast about World War I. I am still struggling with the same question as the article poses, but applied to war instead of disease. I want to believe that it's respectful to try to understand these experiences on their own terms, maybe especially because of how horrible they were. But at other times I remember that I can walk away whenever I want, and so I can never understand, and if I enjoy the podcast (for example), is that exploitative?

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

"Microsoft Edge is also 64-bit, not just by default, but at all times when running on a 64-bit processor."

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.

Running a small datacenter for the last few years, I can totally identify with that quote.

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 don't know of any explicit follow up, but there is a ton of interesting info at multicians.org.

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.

According to [1], the original Multics trap door that Thompson cites as his inspiration was distributed, to an Air force installation no less.

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

Yes, that timeline error stuck out to me as well. Recently I found Solaris 2.1 physical media, and the date on it is 12/92. My goal is to get old GCC running on it, but first I have to get it running at all. My sun4m is a SparcStation 20, so will probably have to find a sun4c or SS10.

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.

Tim Hunkin's work is unmistakable. After all of these years, The Secret Life of Machines is still some of my favorite television ever. Glad to see he is still at it.