Re: Daily!?! RFC begs to differ
As near as I can tell, a lot of security rules are set based on what the project lead saw last time they logged into something.
633 publicly visible posts • joined 7 Jul 2017
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.
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).
One of my earliest proper programming jobs was "write a thing that summarises these log files so we can see the important or novel messages".
Turning a few thousand log lines into "2700 Warning As, 300 error Bs, and 2 of error C" can go a long way, especially if you had no idea error C was even in there.
A bit of a catch-22, really. The lack of apps pushed down market share, the low market share discouraged making apps for it.
I had a winphone for ages - the cameras on the higher end nokias were unbelievably good - and the app store was more often comedy than utility. The number of direct lifts of Mario and Sonic games boggled the mind.
Maybe I missed it, but the article could use a clearer explanation of what the WAA is alleged to do.
I think it's saying that if you turn it on, the data isn't saved to your google profile (the one where you can go in and see what adverts Google thinks you want, etc), but to an app-specific bucket that only the app in question can use. Since it's limited tot hat app, whatever data is in there doesn't appear in your Google profile.
However, that there are backdoors that let Google access that data anyway, even if it's not showing in your Google profile.
Is that right? For that to function, Big G would need to have some systems in place for secret profile data, otherwise bringing these two datasets (and any other hidden data sources) together for advertising but ensuring they never merge in a way that shows the user 'shadow' profile stuff.