Re: the data speed
In the days of ASR33s & 35s that speed was almost unimaginably fast.
16427 posts • joined 16 Jun 2014
Between them it's up to the Internet Society and IETF to push it; introduce encrypted protocols and then deprecate the old ones. After all, they set they standards. Clearly they do need to make public presentation of the case but they need to do more than talk; fait accompli can be difficult to argue with.
That description immediately raises one possibility because elements of it are all to familiar. It sounds as if all sorts of modules were producing the XML portion. And if they couldn't produce valid XML in some modules it's quite possible that they might also have failed to produce well formed XML. I've certainly experienced that in the past. We had to train the staff in the primary contractor's tame Indian S/W house to write well-formed XML. Periodically they'd rotate them out and the next thing we'd receive a new variant which mis-handled names such as O'Neil. In our system I'd make sure that file was rejected and feedback was sent up the line. But if some non-well-formed XML were allowed to fail silently...
A/C, you have my sympathy.
It's worth remembering that it's the disasters that make the news. I've worked on a number of public sector projects which were successful. After a few years of operation, however, the contract period was up and the whole service put out to re-tender.* At that point someone else gets the contract so the original work on which the successful delivery was based got scrapped.
* With some very odd results, it has to be said, but that's a different story.
"I always thought that one of the key goals of agile is to be able to cope with clients who continually try to change the specs and architecture."
it works if you're able to exhaust their capacity to change; at some point they need to stop so you can deliver something. When politicians are the clients that's not going to happen this side of the heat death of the universe.
"I'm in agreement with the guy above - a dozen devs, a page layout designer or two, some databases. One manager to co-ordinate and no bloody jargon."
Don't forget a well-defined, soluble problem. That's in your case, where you're paid by results. If you're paid by billable hours it's a positive disadvantage.
"Working software is the primary measure of progress."
What about training the existing users, having it properly documented for the users of the future, briefing support staff, having proper software documentation, or at least self documenting code, for those who will have to maintain it and ensuring it doesn't disrupt the data from the previous release? Or do we just throw code over the fence and wave goodbye to it?
"There are only 60 million people in the uk ,so the amount of criminals is less than that."
Courts, at least high courts, seem to have enormous scheduling problems.
That's from personal experience. In the worst cases I've spent several hours on each of several consecutive days waiting to be called as a witness despite the fact it would have taken, worst case, about half an hour's notice to get from lab to witness box.
They need to schedule judges, barristers, barristers' juniors, instructing solicitors, witnesses and jurors. Whilst the sittings are built around the judges' schedules it's not always easy to estimate how long a particular trial will last and if one overruns then it might disrupt not only the remainder of the list but also other courts where one of the barristers or witnesses might be scheduled to appear. Add to that the fact that start of business can sometimes be held up as some other matter has to be urgently brought before the judge.
It's not surprising that magistrates' courts are the one thing they've sorted out - my limited experience there is that they have multiple brief cases so, although one might waste half a day, there's no "can you come back tomorrow?".
There could be a huge win by improving high court scheduling but I doubt it could ever be an easy job.
"Usually I check something(s) in every day, for the most major things it may take a week, but the goal is always to get it in and working so it can be tested."
The question is - is that for software that's still in development or software that's deployed in production?
If it's the latter and your "something" just changes its data format you're going to be very unpopular with your users. And that's just for ordinary files. If it requires frequent re-orgs of an RDBMS then you'd be advised to not go near any dark alley where your DBA might be lurking.
Software works on data. If you can't get the design of that right early you're going to be carrying a lot of technical debt in terms of backward compatibility or you're going to impose serious costs on your users for repeatedly bringing existing data up to date.
"WONTFIX. They say to install dropbear instead."
Which in turn has had its problems, e.g. https://www.theregister.co.uk/2015/02/20/250000_routers_have_duplicate_ssh_keys/
If someone is serious about bricking mass deployments of vulnerable kit upatched versions of that could be near the top of the list.
"I think its a good thing, and there should be more of it, the only drawback is its dependency on central C&C."
Looking at the attacks they interrogate various aspects of the system although it's not immediately obvious what they were doing with it. The second one in particular collects quite a lot of detail. This puzzled me until I realised it wasn't a script running on the device, it was running on the C & C server which will be collecting intelligence on the devices being attacked. It seems quite possible that this is in part an analysis phase to design a worm which will brick devices a whole lot faster.
"Then why don't you hear about Kirby and Electrolux vacuum cleaners anymore"
Never heard of Kirby. But we have a Bosch branded vacuum cleaner, a Hotpoint branded washing machine, both bought fairly recently replacing Vax & Zanussi. Dishwasher is AEG. Freezer is Zanussi. I'm not sure how familiar these are in the US but they're all well known brands here.
One of the possible fates of good brands is that they can get asset stripped. Some firm of beancounters the brand and, not having any idea themselves of how to build an electric kettle* or whatever cuts corners to bring the price down and eventually ruins it. However the original owners who put in the work had a valuable brand and got paid for it.
*You may recognise recent experience speaking here. So far Amazon Basics looks like they've got their kettles built by someone who knows how to do the job better than the well-known brand. But then Amazon now have a brand to look after.
"Anybody that deploys any Unix computer with telnet installed and answering is a moron and should consider a career change."
The people deploying these don't know they're deploying a Unix computer. They think they're installing a gadget they bought in a box that says video camera, video recorder, thermostat or whatever.
"Unlikely as it would probably cost less to do a fly-by-night and reappear a few weeks later under a new name."
Rinse and repeat every few weeks until the market learns that no cheap devices survives for long? Fine if you want to keep driving round in a Robin Reliant van.
Build a brand that earns a good reputation and that brand is actually of value. That's where the big money is in the long term.
"mostly it's just adding another headache in the lives of poor bastards that just want to automate their homes"
And the poor bastards who, by trying to automate their homes (in itself a solution looking for a problem) are becoming a headache to vast swathes of the internet. Look on it as overall optimisation.
As a lot of the targets of botnet herders and of this attack seem to be security DVRs it's likely that at least some of them will have been installed by "professionals". If someone prompting themselves as a security professional installs an IoT device without securing then their customer care operation deserves all the grief it gets.
"Unless, of course, THEY'RE getting bricked, too, meaning you're damned if you do and damned if you don't."
That's the point. This is going to brick insecure devices in general. If you're making one of them you'll find both you and your equally insecure competitors are having your products bricked. In any case you're almost certainly just relabelling the same product as your competitors. If you don't tighten up your operation you're toast. And if they don't your competitors are also toast. Those of you who get wise have taken on some extra costs but you're still alive but, because you've all had to take on extra costs (either by your upstream vendor improving the product or changing to another vendor's product) you're all moving in step. It remains the same competitive market but at a slightly higher price until the extra cost has been absorbed.
The alternative is that the generic Chinese approach gets such a bad reputation so quickly that only well-known brands are able to sell by getting a non-bricking reputation. This could even be an operation by someone with a better product aiming to wipe out the competition.
At the moment it seems to be working on a thing by thing basis from C & C servers. If it gets turned into a worm it will propagate a lot faster.
"a shedload of support calls and returned 'faulty' items might get their attention."
As Charles 9 keeps telling us, a lot of this stuff is bought on the grey markets which might make support and returns more difficult. However, it will affect reputations and make buyers a lot more careful in future when they come to replace the bricked items. That, more than anything, will grab vendors' attention.
And the oft touted argument of price competition between vendors really doesn't come into it. There's no point in being a penny or two cheaper than the competition if nobody's buying your product because it's known to get bricked.
"Add to this the PITA of systemd. I know somebody will pick me up on this"
I will, but only to agree with you.
As to KDE you can turn all the fancy stuff off. Irrespective of whether it sucks all the performance out of the UI it's just down-right annoying.
Lab airlines aren't usually particularly vicious.
Chemicals OTOH... Because of the nasty biologicals that might be encountered we used chromic acid as a cleaning solution. The best way to impress a new assistant of the care they needed to take with it was to toss a piece of paper into it so they could see it disappear instantly.
Biting the hand that feeds IT © 1998–2019