I used both BASIC and HyperCard - they were dramatically different approaches. If you want a modern BASIC, try Perl or Python or Ruby or - you get the picture. There are dozens of suitable replacements; simple direct languages that can write a short command-line program easily.

And you show the result to the average user out there and they won't even think it's a program. If you want a GUI - like everything out there today - you'll have to work on a major lift, some complex API that takes months to master, and days even for an experienced programmer to learn.

HyperCard could get you a simple GUI-based program in minutes, that even a beginner could do. You could actually get quite a ways without writing a single line of 'code' - though you still needed to think about the structure of how you moved through the application. It could even be argued that you can teach that structural thought easier to certain types of learners, as you get a more dramatic and visual result.

But the largest thing for a beginner that HyperCard could offer was a feeling of accomplishment: In a few minutes you had what 'felt' like a real application, with a GUI and everything. It doesn't look like a cliff to get to the point of writing a program that they can show off to their friends - even if it's a simple program.

There are roles for both, but to get someone interested in programming, I think HyperCard is probably better. Once you have that pull out the major arcania of complex API's and huge libraries.

I just had an excellent counter-argument today: Work uses one password to log into their benefits site and into the handheld scanner used on the floor. The handheld scanner has a keyboard of less than 20 keys - numbers are easy, letters are hard, capital letters are really hard, and special characters are impossible. And there's no other input.

My login to my benefits is now controlled by the password I can type into what's basically a telephone keypad. Because that's where I need to type it a couple of times a day.

Because the average human being can actually read it better off of a changing analog-style dial than they can understand a bare number. It has to do with us being well developed at judging distances for throwing and jumping. (And an analog dial allows you to read both off of one instrument.)

The other place analog (or analog-style) gauges shine is when the rate of change is more important than the value. Speedometers and tachometers are good examples: You usually care more if you are speeding up, slowing down, or keeping the same speed than whether you are going 65 or 66mph.

Depends on what PHP is doing. If it makes a call to system(), anywhere... No, you are not. (Assuming you have bash as /bin/sh - the BSD's don't, and some Linux distros don't.)

If it stays entirely within PHP, then you are. But that'd be a lot of work to double check - You need to check every line of code you run, and the php interpreter itself to see where it calls out.

From the Ars story on the article: Apparently there's some newish law that would keep them from commenting specifically on Section 215 - If they want to do aggregate disclosure they have to group it with disclosures under another law. (Section 702 - which we know they have received orders under, since it was in the Snowden files.) (They also have the option of doing non-aggregate disclosures, but they couldn't do it immediately.)

Assuming POP/IMAP and SMTP aren't blocked - which is even more likely to be the case than that the Gmail page is blocked.

Might work, but doesn't solve any of this guy's problems.

Sure. If the Internet service is that bad, I’m guessing it's some developing country that's nationalized the Internet. Therefore, they want you using their servers and services, because half the point is to make spying on you easier. Not particularly uncommon... (Often they'll only block it if it's encrypted or something like that.)

Actually, an iPad sounds like exactly what he's looking for: Locked-down, with specific functions accessible. There's even some provisions for remote maintenance by authorized personnel. (He'd have to get OS X server and configure things first, I think, but it should be possible.) Main problem is dealing with connecting it to a dial-up link.

You are making the assumption that Gmail isn't blocked, and that the users in question would be open to changing their email addresses.

Also, webmail over dialup has the distinct disadvantage of requiring you to be online to read your email. This ties up your phone line, and may cost money. Batch-download is normally a better solution over intermittent links: Connect to get your email, disconnect, read it, write replies, connect to send. Total time online: usually less than a minute.

1: It's wordy. Larry Wall's famous statement on it is: 'I knew I’d hate COBOL the moment I saw they’d used “perform” instead of “do”.'
2: It's Crufty. Lots and lots of odd corner cases that are there because it made sense in the 70's, as well as decisions that used to be standard: All variables have to be declared at the start of the program, for instance. (With strong typing.)
3: It's finicky. The position (not the indentation) on the line matters, you have to declare things like your input and output formats formally (and separate from where you use them), etc.

COBOL is an excellent example of design-by-committee and then 'accumulate features as needed'. It's object-oriented features are a great example: Bolted on as an obvious afterthought, at a weird angle from the rest of the language, but yes it can be used. It all works, and you can write programs in it, but it's like being forced to write a bad instruction manual.

What it can do that other languages can't, mostly, is run on Big Iron with legacy code from before I was born. It has some decent features for financial markets (decimal numerics are supported natively, for instance), but mostly it's that it's been in banks and big institutions for decades and it's cheaper (and less risky) to hire someone to support it than to hire teams to rewrite their entire codebase. It works, and has been working, basically forever in computer terms. My mom learned COBOL in college, on punchcards. The language hasn't changed all that much since then. (For good and bad.) It's unlikely ever to be 'cool', but it's also unlikely to go away anytime soon.

Possibly. But the short-term social disruption would not be something I'd like to witness.

And since the 'short-term' in this case is probably 'a generation or two', I'd have to be a witness. (Or dead.)

All it takes is a couple of people who 'aren't infected, just look' (there are a few days of little-to-no symptoms) to bribe some official to get on some plane or past a border check. We're a significantly more interconnected world today than even a hundred years ago - you don't need rats to spread things widely.

It's not a pandemic - yet. But it wouldn't take much for it to be one, and it would be major.

It depends partly on what features of ZFS you'll be using, and what types of performance you need. In general, you can run ZFS for an arbitrarily-large disk set with about 2GB of RAM - but you won't be using the memory cache features of ZFS much at all. The more ram you have available, the more it'll assign to the ARC (read cache). If you are running a media fileserver, where every read is a large file and is unique, then the ARC doesn't make much difference. If it's a webserver, where you read the same small files over and over, it's a huge difference. Things like compression and larger checksums also can take slightly more RAM.

The one real computable is if you try to turn on deduplication - you need something like 5GB of RAM per TB of data to be deduped, or performance goes to hell. This is to store the dedup lookup tables (which are put in the ARC) - if you can't fit them into RAM, every read/write adds having to read them into RAM, lookup where the data is, and then load the data. (Which can mean several reads per IO op.) Note that you don't have to dedup the entire dataset - it's on a per-filessystem basis. (And ZFS makes creating filesystems trivial.) Still, it's best to leave it off unless you have ungodly amounts of RAM to throw at it, and know you are storing heavily duplicated data.

That is a feature, not a problem.

There are multiple programs out there to restart demon processes, if needed, with varying amounts of notifications to the admin, and varying interfaces. You pick which works best for you. An embedded appliance may need a 'restart at all costs, write a log and forget about it' program. You may want your restart program to email you, while someone else may prefer a web interface to check status. Maybe some programs should only be restarted in specific circumstances.

The Unix way is not to try to be everything to everybody, but to pick a specific function and do it really well, in a way that lets others do the same thing in a different way if they find the need to do so.

(I'll admit the biggest red flag to me about Systemd is binary logs - that prevents many useful things, in my experience.)