I think he meant to use exclusivity as a straw man to show that "IP is not food", instead of the more often misused: "not paying is not equal to stealing".
Both are obviously false, but I think that was the intend (argument by confusion?).
Your reasons may be plentiful, but if it's because you prefer the protocol, without the obstruction of handshake, I'd recommend using openssl s_client.
Obvious disclaimer: openssl binary may or may not be part of your system (although the same can be said about netcat and telnet)
> if somebody sent you an email with that code (even if you never open the email)
What is he trying to say here? How on earth would it be possible to execute the url in the context of your zecco cookies unless it's openend in a (browser) in which you've logged into zecco?
Some webmail clients (and potentially other web communicators like online chats - FB messenger, etc) might pre-fetch all URLs send in the email or chat.
The pre-fetching will use the user's context (and cookies) because it's executed by the user's web browser.
I know that MS Messenger used to "pre-fetch" URLs in your system's IE session even if you don't open the conversation. I presume there was some similar issue with 2008-era email clients (it's a "useful feature" after all).
The drawbacks of potentially causing downtime and therefore having the potential to drive away customers as well as obtain an image of unreliability can be much more damaging than not using it in the first place. Customer image means quite a bit.
Agreed, it should be hard to explain benefits even to non technical people. It's like doing a fire drill, if you do it frequently when the actual fire happens you will know what to do. Similarly with infrastructure, it might not be good handling rare events, but once these events are not rare you will learn to handle them.
The biggest issue IMO is explaining need to make things more resilient. Actually the technical people (mainly developers) might be the biggest obstacle, because it adds more work for them (with no visible benefit to them, because when application fails it's ops who get woken up).
I'm confused. It seems you have more information than the blog post and attached documents entail.
Do you know both how long the investigation would be under for? Do you know the timing?
Stating there's no good reason is not true - it's quite possible that a gag order is issued to protect the investigation, including identification of suspects, the number of suspects (at least two in this case), change of behavior (e.g. switch from Signal to smoke signals, fax, or just lay low for a while), etc.
What happens when two days after a terrorist attack, OWS publishes a subpoena for the first time? I for one welcome that they go through the official channels to get the redacted version approved. Let's not botch investigations for the sake of pitchforking the "everything should be public" slogans.
I think a middle ground is possible in this specific case. The government could have said "we're placing a selective gag order, meaning you can't publish this notice but you can publish the redacted notice that we've helpfully attached", rather than wait for OWS to file a petition to publish the redacted version.
Care to give an example? What I'd call "dead simple init.d custom services" I find very easy to do in systemd, so I wonder if our definition is the same.
Here's what I'd call a simple init.d-like example. non-needed things (if you think it's too complex) include: wait for fs mount and network, custom reload command, "don't log stdout"
That only guarantees that your network devices have been enumerated, not that they are available with assigned addresses.
I encountered this problem with SSH failing to start on Ubuntu 16.04 server. systemd was launching SSH before the binding address had been assigned, causing SSH to abort and fail and the server to continue to boot without any way of accessing it remotely.
Workaround ( at the physical console ) was to add a Retry to the SSH unit and time it to coincide with the address having been assigned[0]. hacky, but no other unit imperatives worked.
[0] Default behaviour in the SSH unit, at least on Ubuntu, is that it tries once and never again.
Well, to start a init.d service you only really need an executable and a few links to rc.X. Nothing more. I know about the lsb stuff and that but only gives a few warnings if you omit it. Still works as expected out of the box.
For example, if your service daemonizes (forks) the systemd way wont work. You need fork=yes or something. For my likings is way more complex that it should be.
The thing is we've gone from needing almost nothing 90% of the time (I just want my executable to be run when the system is up) to get the thing working to understanding a lot of sections, files, ill-named options etc.
That's a fair point, but it sounds like we're moving into a debate on OSes switching to systemd by default.
If we're comparing running a binary on startup vs. setting it up as a service in systemd, I wholeheartedly agree that you should always use the right tool for the job. So let's discuss the software, not the politics :)
If we're talking about the original story (crontab) people should compare it to systemd timers if they're looking for alternatives - which I still prefer.
I have no stake in OSes choice of default installed packages (be it init, openrc, or systemd), and agree with your parent comment that OSes shouldn't break (dropping crontab as an installed base package) without consideration.
I haven't come across one of these OSes where it wasn't possible to install crontab from their default package managers, and in their main repositories, though.
Yep, I was complaining a bit of the move to systemd.
To run a binary (that acts as a daemon in the end) with no especial handling needed by the OS and nothing fancy (just run at runlevel 3, I don't even need a "clean" shutdown, everything is handled by the process) I couldn't find a simple way to do it without systemd. The /etc/init.d/ directory was under control (!!) by systemd. The binary wouldn't even run manually, systemd intercepted the process running from that directory. So I had to write a systemd service file. Not a big deal after all, but I didn't like it.
About the timers in systemd I haven't even look at them. As long as I don't need them I'm fine with 'cron' and 'at'. Maybe they are not the best posible systems, but IMO work quite well (and I don't have to change my code to use them). If at some point I encounter problems or limitations with my uses of cron and those are fixed by systemd I will happily update to systemd timers. For now the work perfectly fine for my needs.
He touches on it briefly in this podcast episode: https://www.therobotbrains.ai/who-is-yann-lecun