Re: ECDL
Cycling lessons.
641 publicly visible posts • joined 7 Jul 2017
I used to work in an actuarial department, and they got fed up of being unable to tell what people meant by "good excel skills". Some people thought that being able to copy down a sumif was 'good', some people had got the hang of Index(match()) but 'struggled with nested IF statements after six layers' and so rated themselves as "okay". Genuinely, most applicants had no objective sense of how good they were with Excel, and that made it surprisingly hard to get the right people into the excel dev team.
They, by combining the knowledge of every excel expert they could find in a room of 140 math grads* employed specifically to predict the future of insurance policies, build a Test. It was like 120ish questions, with worked examples about different features in Excel, who they worked and when you might use them.
Literally no-one got full marks - Excel is too damn big. I'm proud to say I came closer than most, but it was the first time I'd ever heard of 'slicers', and honestly I've still not needed to use those since.
The test turned out to be incredibly useful for dealing with Dunning-Kruger issues in self-reported skills.
*I was not a math grad, but a math/comsci dropout who'd instead spent a decade as on-site support, fixing the Very Clever solutions the actuaries came up with on deadlines.
I think there's a bunch of technical, nitpicky law things in the way there.
1) proceeds of crime - most places don't actually have laws on that, weirdly, and when they do they tend to be very specifically written (I think the UK one is one of the broadest, mind).
2) stolen goods - turns out that if you personally walk into a shop and buy something with your money and give it willingly to someone, that's not theft. Morally, of course if fucking is. Legally, it's in a different bucket where the laws are written as much to stop unhappy customers from having the local grocer arrested. Fraud is different to theft, and modern anti-fraud laws just aren't built around this kind of thing.
Genuinely, this is an area that requires competent legislation. If someone can draft some legalese to make this sort of scam *into theft*, without me being able to get you arrested by mailing you a giftcard and faking some text messages, then it would suddenly become a *massive* problem for Apple/Google/etc that they were suddenly on the hook for a lot of this shit. That would probably incentivise them to do something about it, but I'm not smart enough to guess at what that'd look like.
Steam is a really common one too. It's a global distributor, so they can always find local buyers who'll buy a $10 steam credit for $5 and be very happy with their cheap games. Or they can buy games directly and resell the keys - supposedly some of the 'cheap' steam-key resellers get stock this way, but I would have thought that'd be traceable, but it is at least not an option with google/iTunes stuff that doesn't let you resell products.
That's the problem with remote servers, you stop thinking of them as hardware in the first place. Even worse is "cloud" stuff where everyone remembers the decade old sales pitch of virtual machines being seamlessly passed between servers without ever impacting client experience, yet, inevitably, your "cloud application" has been running in a single unchanging rack in a single warehouse somewhere in Dublin for the last six months, and won't move without an outage.
If Chevron goes, the American government falls apart with it. For generations, US law has assumed (under the 'Chevron' decision) that Congress can create an agency to deal with Something and have the agency handle the details around that Something. Almost all federal authority works under this auspice, and without it a lot of things all fail at once, from the parks to the post, from the ATF to the FTC.
I worked with some simulation software that needed a dongle (thankfully USB, though we did have some older serial port ones) to validate licenses, but only at boot. Because the dongles went missing a lot, I once ended up spending an hour sharing a half-dozen dongles between thirty machines, booting then in batches, after a power outage took down the whole room at once. PITA, but I got everything back up and running before the important folk got into the office!
("Power outage? What about the UPS?" I hear you ask. Well, the power went out because the UPS caught fire...)
Honestly, I'd guess that even Google will find people it can't track but really wants to. Rival companies, for example, won't be using google docs for their accounting, and so the corporate espionage world still has reasons to exist. It's risky, obviously, especially when staff can move between the giants freely, but it's certainly not unthinkable.
They don't need to steal my data, as you say they get plenty of that, but there's always gaps they'll want to fill.
You can have too much of a good thing, especially if you're having to pay for it.
That's quite expensive when you're looking at terabyte processes, and has a high risk of being the reason runs fail. Back in 2010ish, my lot (finance actuarial stuff, generating hundreds of TB per year) were spending six figures on daily backups, and those ran out-of-hours to minimise the risk of trying to backup a file that's part processed, or accidentally lock a file that needed to be edited by the simulation software (etc). We did have on-demand access to the last 30 dailies, the last 12 month-ends, and last seven year-end backups, though, which was absolutely worth the cost.
You get some fun stuff with Actuarial modelling, if you stuff up something basic enough. Errors that happen for every month in your projection, for every policy - my record is a log file with 4.8 million error messages in it. Took twenty minutes to open the file with the tools I had at the time.
Ink's where the money is, since the printer companies insist a printer should be purchasable for £50, even though it's a mass of moving parts with astonishingly small tolerances, even after tens of thousands of operations. Everything else in computing has gotten cheaper and easier to make over time, but printers really haven't at all. It's still a hard job to precisely place ink on page at great speed with any degree of reliability.
If the printer making companies had the sense to fix the prices of printers closer to the manufacturing cost, they wouldn't need to pull these ink related stunts, but they've al tried to under-cut each other (and make it up in ink) for so long the home printer market is just screwed.
Hmm.
It seems that Fujitsu likely knew the system was broken in ways that could harm the post office - the sodding cash management bit was broken, that's never going to be good - but as you say, they didn't force the PO to hound people to suicide instead of doing the sensible thing and _suing Fujitsu_ for their botched development.
That said, Fujitsu sent expert witnesses to those court cases, and allegedly participated in the cover-up. Those actions are somewhat more obviously their fault.
That's what bugs me about it - what did they think they were doing? Was the system just wonky, needing constant manual intervention, and sometimes the manual fixes were done wrong?
Was money lost, and by whom? Were the 'shortfalls' entirely virtual, were there unexplained surpluses elsewhere in the system matching them off?
Voice bioauthentication for a helpdesk sounds challenging, TBH. Getting the valid auth samples in the first place is going to be a major endevour, and then how do you deal with the audio quality issues that come from phone lines/potentially poor quality mics, compression, etc?
As a kid in the 90s, I was told the Royal Navy were using Amigas for ship-board computers because, at the time, they had faster reboots than anything else, and that was considered to be important when being shot at.
I don't know how true that was - it certainly isn't any more - but it's the sort of thing you need to consider. These days, solid state drives solve a lot these problems all at once.
Early in my career, I ran into a problem with eComms (IBM mainframe terminal emulator) talking to VBA once. The gist, as I understood at the time, was that VBA thought "TRUE" is a byte value of 1 ('00000001'). eComms thought it was a bit with a value of 1 ('1'), and didn't fret too much about the rest of the byte, resulting in some odd intermitted problems where, sometimes, TRUE <> TRUE.
I fixed that by abusing casting, but if anyone happens upon my past life making terrible automation tools, I hope you're better paid for it than I was.
Rare, or time-bound! I've seen code fail after forty years of continuous use, because that's how long it took for us to have three days in a row where a certain product didn't sell.
Imagine unpicking a 40-year old bug and finding that it was meant to be handled, but someone had commented it out because they didn't understand it.
They'll need to - they won't be able to apply the new T&C if they didn't follow their own policy. That'd get shredded by any lawyer in court.
The whole "send the email and gamble they don't send an objection" trick is far more likely to work in aggregate, even if a few savvy folk spot the problem.
My old office did this for years- the original server room heated the on-site swimming pool for many years, then it was changed to pump the waste heat into the offices heating system.
This was so successful and reliable it was forgotten about by everyone, until we decommissioned the last on-prem stuff and everyone in one wing started complaining about the cold.
The "send" vs "receive" issue is familiar to me - I think of it as the "London Road problem". The only thing you know is that this road, eventually, gets to London. You could be in nearly any town in England.
Say you have to send a file to the Finance team, you call it the Finance File, and send it off to them. Finance end up getting dozens of 'Finance files' from all over the business, and every now and then some of them get confused with others!
Names are hard.
It's probably built to be fast, so it's going to do something like grabbing 4 bytes, treat the first three as an identifier and the fourth as a length, tag that length in bytes as that first identifier then jumping [length] bytes ahead, grabbing four bytes to get ID and lengths, jumping [length], etc, etc.
(I actually got myself into a similar mess a few years back, trying to write a world editor for Minecraft)
It's not until someone calls you up and says "your defragger ate my drive" you realise you've fucked up. Or maybe you always knew it only worked on FAT, asked the boss if there was time to add a test and they said to just put "only for FAT" in sharpie on the floppy disk and ship it.
My last spinning rust drive - either in home or office - is my aging PS4. But even so, 99% is a very large number and plenty of folk still use older machines, so I doubt it's quite that high.
It doesn't seem to be a thing that the Steam hardware survey covers, not sure if anyone else is tracking these numbers, though.
In theory, the money pumped into a company that's making a loss is an investment that'll eventually provide returns to you. For a business, this can be a more efficient use of money than paying taxes (which does have returns, but they're much harder to put on your annual report to shareholders).
The 90s was a very long time ago - I can imagine someone thought it'd work and sold it.
That said, a lot of mainframe software puts cancel on function keys (the one I'm using right now often cancels on F3, for whatever reason), which would be more likely raised on modern ergonomics, and the details in the story lost over the years.
My newest work laptop has the power button right where "delete" is on the previous laptop.
Last week, mid conference call, I found a rogue value in a spreadsheet and hit what muscle memory insisted was the delete key. Cue me hurriedly apologising to the rest of the people on the call as my laptop started to shut down!
My understanding is that they originally added the PIN to help out home users who were frustrated that the machine in their house was such a pain to log into.
Then their corporate customers in regulated industries said things like "it is literally against the law for us to use a 4-digit password, what the actual hell is this for", so MS just let the PIN be longer and more complex (and let sysadmins set sensible complexity rules).