PapaSpaceDelta

He was inspired by Iram of the Pillars, which is mentioned in the Quran (https://en.wikipedia.org/wiki/Iram_of_the_Pillars). There's an interesting overview of its role in his work here: https://lovecraft.fandom.com/wiki/Irem.

I’ve heard stories about high end recording studios, with shrink wrapped boxes of expensive audio software, that used cracked versions on their workstations because they don’t want to deal with the inevitable iLok hassles…

The Victoria line in London runs up to 34 trains per hour, using CBTC: https://tfl.gov.uk/info-for/media/press-releases/2014/june/v...

On very busy urban systems, one major advantage of CBTC is that the signalling blocks (the section of line that only one train can be in at a time) can be smaller, since the possibility of a driver failing to notice a red signal can be discounted. This increases the number of trains that can be run on the same line.

I recently migrated from 1Password using Dropbox for sync, to KeePassXC (Windows, Linux & Mac) and Strongbox (iPhone & iPad) still using Dropbox.

Migration was a simple matter of exporting a CSV and then just correctly selecting the column order for KeePass import.

For those who don't want to trust a third party, even with their encrypted data, I believe that home NAS sync-when-available is possible - I personally haven't tested the implications of syncing changes from multiple devices at the same time in that scenario.

I suppose that I have to put this: https://www.youtube.com/watch?v=VTSCppeFzX4 here. Many a true word…

For a lot of us Brits Sir Clive's machines were our first glimpse of the future. If that doesn’t sound like you, then just stand aside while we mourn our hero.

It's an interesting part of corporate culture. Large companies hate the process of firing employees for a number of reasons: staff moral, public perception, potential legal liability, etc. This applies whether it's individuals for performance reasons, or entire teams for economic reasons. To avoid this, there is often a lot of (bureaucratic and difficult) process to justify the hiring of a new FTE.

The corollary to this is that it's often a lot easier for a manager to hire a contractor or use an out-sourcing vendor, even if they don't see the requirements of the role being any different than that of a "permie" and even if it costs the company more money.

With regard to its popularity with publicly traded companies, aside from the cost and liability issues that are being discussed here, I have been told that Revenue per Employee is an investment metric that senior management try to optimise by the use of vendor and agency staff.

Source: I have worked for large corporates both as a contractor and as a full time employee in mixed teams.

This is an excellent point. If you are a hands on techie by inclination, then you should be aware that blindly chasing promotion in an organisation that doesn’t have a track for “individual contributors” is simply going to lead to more time in meetings and less time doing what you are good at and enjoy. Most of the corporate world is built around the idea that promotion will entail more and more (formal) leadership responsibilities.

My personal experience is that people who wish to specialise in developing their own technical work to a higher level, without taking on management responsibilities, need to be more proactive about seeking the next role that will be right for them and very often that means looking externally.

Of course there are a number of organisations that explicitly provide a specialist seniority track outside management (Sun Microsystems was the first that I encountered), but you probably already know if you work somewhere like that.

The fact that he went into hospital and came back out to a functioning farm suggests that he has a good relationship with his neighbouring farmers. My guess would be that he's planned for exactly what will happen to his livestock and farm when he passes.

I dived the Blue Hole in Belize and was shocked by the slack attitude of most of the other divers on the boat. I'd just completed my Advanced Open Water (with a deep dive) so was very conscious of the regular air checks, however despite a detailed dive briefing with emphasis on the pressure cut offs at each depth, about half the party ended up having to be given supplemental air at the final safety stop. Although I'm sure that there are many irresponsible dive operators out there, there are clearly also divers (many of whom were at least experienced enough to bring their own equipment) who don't take responsibility for their own safety. I don't know if that's a training issue, or just a human stupidity issue.

I don't think there's any real standard, since it very much depends on application SLAs, industry sector, size of the on-call team, geographic location, length of on-call rotation, frequency of call-out, how realistic the management are, how much inconvenience the team members are willing to put up with, etc.

For example, I work in London and it would be unreasonable to expect that someone could travel between home and work on public transport and still meet a response SLA less than one hour. That would likely be a different length of time in another location, or if people worked 100% remotely, for example.

My opinion is that if you have a response time less than say 30 minutes, then you actually need to be compensating people for sitting in front of their computers ready to respond immediately, whether that be in the office or remotely.

Unless call-outs are very frequent (in which case there are underlying reliability, capacity management, and/or alerting issues which need to be resolved), then on-call isn't really about the extra time spent working, but the restrictions on what one can do whilst on-call.

To use a fairly simple metric: if an on-call SLA means that I have to be concerned about whether I can pop out to a local shop or how long I can spend in the shower, then I don't think that I would be on-call, I would be working.

Of course start up environments (especially early stage) are always different from more corporate environments and there are generally greater resource constraints in general. For a start up I am usually looking more at what valuable experience I can gain, rather than maximising remuneration (subject to a certain base-level of course).

However ultimately the question remains the same: do I think that what I am getting out of this role is worth what I have to put into it? There are probably roles in which I'd be willing to put up with the inconvenience of very short on-call SLAs, because either they paid very well, or I was gaining very valuable experience.

Whether a role fulfils ones own expectations for the reward/expenditure ratio is a question that everyone has to decide for themselves.

If your expected response time is of the order of 5 minutes, then you are not "on-call", you are working 12 hour days and your compensation and time off arrangements should reflect that.

I suspect that if the company is currently getting that amount of extra work (over and above a normal length working day) for free, then you're unlikely to be able to get them to change that. If it was me, I'd be looking for a role in another team or company that has a more realistic approach to on-call.

Any potential extra impact on your current colleagues that you leaving might cause is the responsibility of your management and up to them to mitigate. How your current colleagues decide to react to the on-call situation should be up to them.

Good luck resolving this, I've been in work situations that had unreasonable expectations myself and I appreciate how stressful it can be.

My impression was that during the early stages there was more concern about touch based transmission, so there was a feeling that the benefits of masks (trapping respiratory droplets) might be outweighed by causing people to touch their faces more frequently.

My family have always been happy to make a donation on my behalf to the good cause of their choice, perhaps that might work for you?

If you can gain the same enjoyment vicariously, you might enjoy SouthernASMR's channel - she often tidies up the shelves of the stores that she visits. Here's a playlist of her Nail Polish organisation videos: https://www.youtube.com/watch?v=9TsxWuFsy3I&list=PL7SQKahkOA...

Betfair takes its commission as a percentage of the profit that one has made in a given market rather as a percentage of a bet size, so it's always worth making a bet on a certain event. Usually by the end of an in-play sporting event, one will find that there is no liquidity available to bet for the likely winner or against the likely loser (and draw if applicable) at any price (their lowest price is 1.01 BTW).

In this case, there are clearly people who are still willing to bet against (lay) a Biden Presidency, at very long odds. This is presumably either because they believe that the price adequately compensates for the low probability of it not happening, or to hedge risk that they have accumulated taking other positions while trading in this market (more likely IMHO).

One other factor is the cost of carry - while money is tied up in a bet it can't be used for anything else, including other betting strategies that might have a higher expected profit. In this case, if one has already made a profit betting for a Biden Presidency at longer odds than 1.07, it might now be worthwhile to pay someone else the slight risk premium to take up ones position until settlement, so that one can lock in the profit and move onto other things.

Have you tried Reaper? I haven’t personally used the experimental Linux builds, because I depend on a lot of third party VSTs, but if it's anywhere near as good as it is on Windows/Mac it may work for you.

I think this (alleged) Orson Welles quote says it best: “The enemy of art is the absence of limitations.”

(Information on the quote's provenance, for those who might be interested: https://quoteinvestigator.com/2014/05/24/art-limit/)

One reason is that any System Administrator can be expected to be able to understand and maintain Bash scripts.

I recently built a fairly complex system entirely in Bash, not because it was the "best" language for the job (it would have been much easier to do in Ruby or Python), but because the client didn't have any permanent staff that could maintain Ruby or Python scripts.

As a contractor, one of the major factors in the technical decisions I make is: how supportable is this technology for the client, once I have left? Of course the answer to that question will vary on a case by case basis, but Bash is usually a good lowest common denominator in a Linux environment.