I was reminded of something recently when someone was using a gooey; they hadn’t made any changes, but clicked “Ok” after reviewing something. A bug in the gooey resulted in a whole bunch of DNS CNAMEs being removed.
The fault is of course with the gooey for having a silly bug, but it was also a reminder to reduce risk whenever you have root (or equivalent).
The “Ok” in a gooey should be read as “Please make the changes I have asked for”; if you are not intentionally making changes, why click on it?
One of the reasons I switched to zsh was that I’d heard of accidents involving wildcards, so I wanted the feature that expanded wildcards within the shell before activating the command.
If you are looking at a configuration file, why are you using an editor? Use view rather than vi, and if you are in vi quit (“:q!”) rather than save and exit (“ZZ”).
If you have an account with special rights , don’t browse the Internet with it. You should have two accounts – one for ordinary stuff and one used just when you need additional rights. That’s two long and strong passwords to remember; life is hard; get used to it.
But this is more than just a few tips for reducing risk; it’s about an attitude that goes beyond simply being careful and towards designing your work flow in ways that reduces risk.
It is quite possible I have commented on this before now, but I felt like a rant and I’m too lazy to search through the old posts to see if I’ve ranting on this subject before.
Windows, Icons, Mouse Pointer … or the gooey. Icons are an integral part of the gooey experience. Or so we are led to believe.
But really aren’t they just a little bit shit?
And I should clarify, I am not talking about file icons – pictures of folders (although given the lack of physical folders these days, a bucket might be more appropriate), and pictures of the kind of contents to be expected within files. Although I’m sure there’s a rant to be had with filesystem browser icons, and I do think they can be a bit silly, this rant isn’t about those.
It’s about those silly little icons in the toolbar of an application … or similar ‘functional icons’ which when activated perform some function. All it takes to misinterpret the icons is lacking the perspective of the icon designer, and then they take on a whole new meaning.
For example, the browser I am using to write this has a bunch of icons just below a strange “V” symbol (because it’s uncool to use a sensible word-based button like “Menu”).
The next stupid icon is an arrow in a circle – obviously intended to indicate a function to rotate the web page (although it’s actually to reload the web page), the left and right arrows are obviously a way to navigate between tabs, and there’s a cloud icon; no idea on what that one does.
In ‘normal’ applications there is of course the classic floppy disk icon, which just about everyone has attacked because it is just such an obvious target. Who uses floppies these days? And how many people under the age of twenty actually know what a floppy is anyway?
And my DAP has an icon that looks like two snakes getting friendly – no idea what that is supposed to represent although I believe it has something to do with “shuffle”.
We have a perfectly adequate way to communicate; one which we spend years learning how to use. It’s called writing.
What’s wrong with writing? Well there are two problems :-
There isn’t much in the way of space inside of an icon to get too wordy.
Words have to be translated which can get expensive.
When you come down to it, pictorial icons are just a half-arsed solution to save money.
This question popped on Twitter just now; I’m not sure the question was a serious one, but as it happens I can answer the question as if it were serious. I’ve been running relatively small mail servers for nearly 30 years, so do know a litle bit about it.
This of course does not cover lots of “bolt ons” to email such as SPF, DKIM, DMARC, and that’s just the simple stuff.
To keep things relatively sane, I’m going to gloss over an awful lot of details – for example, there are all sorts of ways of composing and sending emails, but I will assume you’re using some sort of web interface such as Google Mail.
So you compose an email with an interesting picture or two, and click “Send”.
Hang on a bit! You also did some technical stuff when you entered an email address into the “To” field (if you just enter someone’s name, something somewhere is changing that to an email address) and possibly something summarising the email (or trying to get attention) into the “Subject” field.
Those two headers you have filled in – ‘To’ and ‘Subject’ – are just two of a whole collection of headers that are usually invisible. They are invisible because your mail client is hiding them from you; for good reasons as they’re almost always an unnecessary distraction.
But when you have to diagnose an email problem, seeing the full set of raw headers is kind of essential even if it is dead simple (for the relatively technically sophisticated) to forge headers.
For example, if you set up a dedicated mail client rather than use your mail provider’s web-based mail client, you will have to fill out your own email address (to go into the “From” field). You can fill anything you like into that field although you are unlikely to get a reply
If you fiddle with your mail client enough, you will realise that the “To” field can be changed to a “Cc” field or a “BCc” field. All three take email addresses, and can be used to send an email to someone but they operate in very slightly different ways.
The “To” header is for the main audience of a message.
The “Cc” header is for an audience who should also see the message, but perhaps don’t need to take any action based on the email.
The “Bcc” header is a bit special because it isn’t added to the raw mail message as a header, but is instead used to compose the envelope listing who should receive the email. If you need (or should) keep the list of people receiving an email secret, or just want to avoid an inconveniently long header for people to read then use the “Bcc” header.
Although your mail client may hide the details, email addresses look like :-
email@example.com (a “pure” email address)
“Some Name <firstname.lastname@example.org” (as normally formatted)
The Message Submission Server
So you click on “send”. What happens then?
The first thing that happens is that your mail client converts your email (attachments, rich formatting, etc.) into plain text which is why a file attachment just under your ISP’s limit on mail sizes can exceed that maximum.
To the top of that plain text version of your message, your mail client attaches some headers (again in plain text). In addition your mail client will prepare an “invisible” envelope independent of the headers – it contains just the address(es) you want to send to, and your own address.
Finally the mail client is ready to talk to the “mail submission server”. It will login (usually) with your credentials, and sends the message to the server using the “Simple Mail Transport Protocol” (SMTP).
The mail server adds your message to a queue and before it says to your mail client “Okay, I have it”, it will make sure that the message is safe on disk. Mail servers go to a lot of effort to make sure your messages don’t get “dropped on the floor” even when the operating system they are running on crashes.
After you have submitted a mail message to the message submission server, the message is held in a queue. This is significant because email is a store and forward messaging solution, so every server your message journeys through will make sure it is stored on disk before saying to the server sending the message “Yep. Got it.”.
In theory this should mean that messages never get lost “in the system” (although practice is often different to theory). The store and forward style of architecture suits the era that email is from – back in the 1970s when email could (and did) traverse many different kinds of network rather than “the Internet” that we have today.
What does that mean today? Amongst other things, it means that whilst you may think that your message only visits two mail servers – the one belonging to your ISP and the one belonging to the recipient’s ISP – and that is certainly a valid architecture for very small organisations.
But it does not work so well for larger organisations that may handle millions, or hundreds of millions of message a day. Summing up a large architecture without actually seeing an architecture diagram for every single ISP and large organisation on the Internet is going to be a bit hit and miss, but I’ll give it a go.
Your message submission server will probably simply hand your message off to a server responsible for sending email messages across the Internet. If it cannot send to the recipient’s receiving mail server on the first run through the queue, it may well just hand the message off to a “slow message server” (processing large queues is a bit of a drag).
In either case, the recipient’s server will accept the message and then hand it over to a “mailbox server” that the recipient will connect to.
And the journey is over. At every stage, reliability is favoured over speed.
How do servers send your message to each other? Using that SMTP standard I mentioned earlier.
The speed of email is a good topic to cover here. Speed is not what email is about in the same way that the postal service for physical letters is not about speed. It’s about reliability
Your messages may be readable by the recipient within 5 minutes 99 times out of 100, but that 1 time may take a day or two. That’s just the way that email works – if you want instant messaging, use an instant messaging client.
At no point have I mentioned encryption, and that is intentional. At no point is encryption required; email was designed in an era when computers were far slower and encryption was expensive (even though it was far weaker).
At every point, servers are trusting that the senders are not lying and the original sender is trusting that nobody is snooping on their emails.
To correct that there are a whole bunch of optional add-ons to the email standard to deal with that. But that is a story for another day.
Some of the reaction to Apple’s recent product announcements has been amusing to say the least.
First of all, let’s get the monitor out of the way first. If you think that monitor is ridiculously expensive, you’ve not looked at the specifications closely enough. Mid-range content creation monitors do cost that much – a quick look on B&H shows two monitors in the same price ballpark as the new Apple monitor, and the Apple monitor has higher specifications.
Not including the stand may seem a bit cheap, but frankly if you’ve already paid for a VESA stand that suits your working environment why pay for a stand that you will just throw away?
But yes, $1,000 for a metal stand is a little pricey. Given the negative reaction of the Apple fans at the show, I wouldn’t be surprised to see Apple drop that price (I also wouldn’t be surprised if they don’t).
Now onto the Mac Pro.
First of all, I should say that I’m not buying one – I don’t have the money, and whilst I run a somewhat underpowered workstation at work and a somewhat overpowered workstation at home, the strong points of the Mac Pro aren’t what I’m interested in and its weak points are where I’m interested in strength.
Is this expensive? Of course it is, but so is any high-end workstation – this isn’t your standard desktop PC! You can get a very roughly equivalently specced out Dell Precision 5820 for very roughly 2/3 the cost. But that comes with slower ECC memory and is much less expandable. You can also configure a Dell 7920 to a point that a Mac Pro looks cheap (it goes well above $100,000).
And you don’t buy such a system without expanding it beyond the base configuration.
This kind of machine is bought by professionals where the cost is less important than the return on investment. If it makes a professional just a little bit more productive, it can pay for itself within a year. Of the photographic (and video) professionals I watch on the tube, at least one is planning on buying three as soon as he can.
Could you get a better specification ‘DIY’ machine with a budget of say $15,000? Probably although it may not be as expandable.
Could you run macOS on it? Probably but it wouldn’t be supported by Apple (and that sort of thing is important in a corporate environment).
Could you get next day fix or replace support for your ‘DIY’ machine? Almost certainly not; and again, when any downtime costs you money, that sort of thing is important.
There are however two criticisms I would make of Apple :-
Storage. The new Mac Pro is severely limited in terms of storage expansion. In some ways that it is understandable; the sort of customer this is aimed for is likely to have a big fast NAS box somewhere. But I think they missed a trick by not offering a disk expansion chassis; perhaps an accessory tower that clips to the main tower doubling the width.
No “Mac Pro Mini”. There is still an empty spot in Apple’s product line-up covering the mid-range tower territory – in fact exactly what those who criticise the Mac Pro are effectively asking for.
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.