Posts by Doctor Syntax 40432 publicly visible posts • joined 16 Jun 2014
Budgets only work to manage costs when there's somebody keeping an eye out on the overall budget and, in fact, on other stuff. I've seen maintenance type done n stupidly bad order, presumably by separate budget holders not coordinating so one operation comes along and craps on the new paint job that was just finished.
"They know about data and code - and they are separate. It seems that this OO thing likes treating one equal to the other. "
Not in any implementation I've seen.
You program in C? If so you'll know what a struct is.
You define your struct. Somewhere, possibly somewhere else, you write the code that uses the struct. The code will have statements to allocate one or more blocks of struct-sized memory and pass pointers to other code that twiddles bits inside those blocks. You might accidentally pass a pointer to some other struct - shit happens. When you've finished with a block, if you remember, you'll release the block. When you compile it binary code goes into your library or program file. When the code executes and gets to the part that allocates memory for the struct that allocation takes place in the data space. As you say, separate.
Now take the OO case. You define a data structure something like a struct but in the same section of code you provide the code that operates on that data structure including code to allocate and release space for the data structure. You compile it and binary code goes into the library or program file and when you execute the statement to allocate space for an object it goes into the data space. There really isn't much difference except the terms used and the fact that it's a bit more difficult to accidentally point the wrong data structure to code.
OK there are some extra bits and pieces such as inheritance but in regard to keeping instructions and data separate any decent OO implementation will do the same thing as your preferred non-OO system.
OO is really an extension to the way we did things for years and the real problem is that its inventors had to follow the industry standard and invent an entirely new vocabulary and make it into a religion, then add a dressing of hype. It took me years to see through that and when I did I realised it was just an improved version of the familiar.
"As they do this, their change failure rate is significantly lower than slower organisations [and] they recover from errors much more quickly."
Unless, of course, the slight error managed to corrupt the live data. Or allow a breach that's been exploited and you have to have a conversation with the ICO. Or something equally nasty.
"That means they will continue to lose money hand over fist until every other form of transportation including ALL public transport and ALL delivery and trucking companies have been driven to the wall."
That assumes they can get hold of enough money. If not it's they who go to the wall.
"That's not a customer service fail, that's an Ops fail. Do not fuck with production, especially other people's production."
That's probably not how the thinking works. Your production - that's what pays the wages. Other people's production - their problem.
The post-mortem should be interesting. If it's just "Our checks had a bug that did such and such instead of that and that. We've fixed it so it won't happen again." that's not very good. The real question is why it was even possible to implement something that would cut off a paying customer without intervention.
It goes back to the comment I made on the Martin Fowler article. It's all very well being a fast mover and fixing your errors so your quality improves quickly; when there's an error it can do substantial damage in the course of discovery.
"the potential brand damage to his cloud biz"
How about potential brand damage to cloud biz in general? It's another illustration of the dangers of relying on other people's computers. Irrespective of whether or not Raisup had their own backups they're still going to be off-line for some time until they're restored and tested elsewhere and their customers pointed to the new location. And all because of of an script run by a hosting co. The poor response might have been specific to DigitalOcean but the risk of a hoster's automated whim must surely be generic.
"Windows has extremely tight integration between programming languages and the operating system."
Extremely tight integration is just what Unixers don't want. It's what raised objections to systemd. You make Windows sound even worse that that although I've no doubt that the systemd authors are doing their best to catch up.
"It would be nice to not come into my office one morning and find that the machine rebooted over night and only recovered half the files I forgot to save on my way out the night before."
1. Don't want the machine to reboot overnight. A machine should reboot when I tell it and only then. Power failure can get in the way. A truly seamless update wouldn't need a reboot, of course but that concept is clearly going to be beyond the grasp of anyone weaned on Windows. To be fair I don't have that on Linux as yet for kernel updates although it does exist at a price.
2. Shut down applications you're not using. The only scope for data loss would then be applications you're leaving to chew away on a big task and in that case, see 1. above.
It's largely a list of the things I don't want in an OS and the good things in the list I already have. I wouldn't, of course, have them if I were running Windows.
One thing I think would be a good idea would be separation of applications and user data. Have a separate, versioning storage engine, either running in a separate container or possibly even on a different processor providing storage as a service, preferably with some sort of authentication to authenticate the application as well as the user ID.
'Hello - this is Microsoft technical support'
This is an example of AI never doing anything useful. A good AI would switch the call through to Lenny or the like and then turn the speaker on for your entertainment. A better AI would handle the call itself, learning from past experience with similar calls.
"Are GCHQ that dense? Yes, yes they are."
No they're not. They just hope they can get away with it anyway.
They'll brain-wash the Home Sec to let them do it. And heaven help us if the current Home Sec. in the HO gets into No 10. The current Home Sec in 10 has been bad enough but the current Home Sec. in the HO actually wrote an article in the times describing himself going through the process without even being aware of what he was actually describing.
"The ad agency even bragged about it."
If you pull a stunt like that the only way to get away with it is to keep quiet. An ad agency is about the least likely body to achieve that. Good to see they receive sufficient opprobrium to spill over onto their client. I wonder if their other clients will notice. Who was it again? Leo Burnett Tailor Made.
I wonder if Leo Burnett Tailor Made will get themselves onto first page on Google with this report.
"if a set of data wasn’t believed to be useful, there wouldn’t be a market to buy it"
FTFY
Remember what I keep telling you, the only thing the advertising industry sells is advertising and this sort of thing is one of their products. It doesn't actually have to be useful, they only have to get clients to believe it is, probably by telling them that all their competitors are already buying it.
I wonder how long it will take for currently US tech businesses to come to the same conclusion and shift their HQs. Just use a US franchisee to conduct any sales there. ROTW is a big place compared to the US so cutting yourself off from it isn't going to be a good idea.
Noting his previous logistics background before joining Amazon (i.e. none) it explains a lot. Such as the customer being the only one to notice that a product had gone into a distribution point and never officially left let alone not having left on schedule. Or their system going into confusion if an order didn't get delivered to a locker, treating it as a return and sending a courier to pick up up the non-received item from the customer who hadn't received it without having any notion that sending out a replacement PDQ would be a good idea. Or including a locker over 200 miles away in the nearby location list.
Let's hope they appoint someone who'll take a look at the whole sorry mess.
A long time ago I worked for a branch of a business that printed out its own invoices & things. Then there was an instruction from on high that all this sort of thing must be printed by some behemoth printer in a corporate data centre with which we otherwise had nothing to do. The corporate data centre had its own ideas about what the data it was to receive looked like irrespective of whether it fitted out requirements.
Somewhat less long ago I worked for a business that received and transmitted data via EDI irrespective of whether what was needed was a good fit with EDI message formats. If there were good tools for parsing EDI messages I never found them.
A little later I worked on a couple of projects which used XML. XML came with all the tools to transform one schema into another or even into non-XML formats. We could have our own private schema and not duly worry about what the customers' schemata were, all we had to do was knock up new style-sheets to transform them into what we wanted. By comparison with what had gone before it was like having a big light switched on. So no, I won't support your comments about XML.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
