Re: To be fair to Adobe ....
Stockholm syndrome?
5659 publicly visible posts • joined 15 Mar 2007
Partially. They no longer give you a full service/maintance manual with the device, and the stuff is deliberately hobbles so you have to pay for a "software upgrade" to actually use the full capabilities of the hardware you have just purchased.
Mine is the one with the HP8640B manual in the (bulging) pocket =>
Backups - even if they hare made, are they frequent enough and tested for a full bare-metal recovery?
It is a bit like UPS support: few are willing to send Igor to throw the big red switch and see how the whole building copes with a power outage (you know, to see if aircon holds up while servers are shut down in an orderly manner, etc, instead of overheating).
We ran DOS software under dosemu/MSDOS 6.22 and it never seemed to crash. OK the host machine would be rebooted occasionally and the dosemu instance restarted occasionally, but we never saw an "OS crash" with uptimes of the order of 600 days.
Having said that, if you don't poll for time at least once per day by some program/system action then the DOS date gets stuck as the time-of-day counter simply sets a midnight flag, and is not actually incrementing the date counter...
Was in London about 10 years ago and the hotel cost £125 / night, not too surprising for that city and it was not too shabby for the price. However, they wanted £25 for breakfast and another £15 for WiFi per day! So I thought bugger that and went to a café that did waffles just round the corner. you could get a bacon & maple waffle along with a latte (for that breakfast experience) along free and usable WiFi for the princely sum of £8.
It could be a "euphemism for backdoor" insertion if you start with the assumption that device manufacturers, IoT purveyors, OS-mongers, ISP router selection, etc, are all made with security as a #1 (or even recognisable) priority.
Or, cutting them some slack, you could also look at the current pisspoor state of the above and find it might be quite the opposite.
Tricky one to decide...
The problem with "goto" is not its effectiveness - hell that is exactly how flow control happens in the generated assembler/object code - but in another human reading it and upon seeing a jump destination being able to work out how many ways one gets there.
For some very small functions with a local jump (please, PLEASE, don't bring up setjump/longjump here!) it might be fine as a simple way, for example, to break out of nested loops. But on a larger scale the program's intentions become unintelligible.
Mind you, there are other constructs that are also a bit dodgy, for C you can return out of a function at any point, not always clear logic there. But $DEITY forbid you find yourself working on old FORTRAN where you can have multiple entry points to a subroutine!
It might not be "in permanent need of fixing" but simply subject to lots of application-breaking changes by folk who are using it for something not quite the same as yourself and/or care not for compatibility (or who don't might fixing their own applications every couple of weeks).
Either way it is also a bit of a warning that maybe you should think twice about using it.
Worryingly, the 2018 CVE mentioned by Kaspersky was patched in January that year, suggesting user and/or sysadmin slackness has a part to play in the popularity of these particular problems.
Of course the MS "patch" for the equation editor simply breaks it - they DID NOT FIX IT. Apparently they don't have to code or license to do so! https://www.theregister.co.uk/2018/01/16/microsoft_equation_editor_patched/
So if you have many documents using the old-style equation editor and don't want masses of pointless work trying to re-draw them (probably introducing errors) in the somewhat more shitty new-style MS equation editor, you simply can't plug that hole.
Last time I was at the local barbers the hairdresser was chatting away and mentioned she had one of these in the bedroom. I just quipped about what it must have heard when her boyfriend was over and she went bright red and the other hairdresser laughed out loud. It had NEVER occurred to her this device could be listening to all sorts of intimate activities.
No, I have no idea if she did, but what if =>
I think most people don't commit crimes because they don't believe it is OK. Sure the correlation between "crime" and "morally wrong" can be tenuous, for example copyright laws, so there is a degree of flexibility there.
However, what the real moral of his story is that it is practically impossible to be truly anonymous on-line. The probability of being caught, of course, depends on what resources the authorities are willing to apply to finding you. If it is something high-profile like what the Silk Road was doing then you see what can be done.
Shame they don't try a bit harder against the huge number of the "minor" scams that cheat old folk and naive PC users out of savings, etc.
So has the software in use at the time, as verified by some decent code versioning system, been subject to a proper audit and found to be trustworthy or not?
I am reminded of this analysis of Toyota's engine management software: http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf
Radar should be able to discriminate between a drone and a bird simply by looking at the Doppler profile of the return and the spread due to the high speed of the rotors. It is short-ish range (km or so I guess?) so you could choose a band well above the typical civilian radar and comms bands for it and not worry too much about rain attenuation (heavy enough to kill radar probably means it takes the drone out as well)..
But as you point out, what to DO once you see the target is a whole new kettle of fish.
Hmm, fire fish at them to (a) clog the rotors, and (b) any that escape get the attention of local gulls?
The UK does not have to enforce its laws in the USA - just to fine the company like facebook for GDPR-like amounts. Very quickly FB would have to either (1) fix the click-bating feed of shit, or (2) get out of all UK advertising business (so I guess dropping 1/8 or so in revenue).
A win-win from where I'm standing...
That is exactly my point - this is not about forbidding advanced coding/modulation techniques for performance or reliability, but about stopping obscure/closed systems that you can only interact with if paying the company behind it. Just like DRM, and the opposite of the amateur radio ethos.
There are two separate points here:
1) The use of encryption for emergencies in support of disaster mitigation - fair enough (and allowed in the UK).
2) The use of obscure/propitiatory systems as a DRM-like system that looks out any user who is not willing to pay the company behind it. It is this point that I object to.
The issue of error correction coding for performance is not a problem, that is well known and perfectly fine if it is an open system (like those covered by the CCSDS standards) and some well known amateurs have freely contributed to this (just search for Phil Karn as an example).
Amateur radio has NEVER offered privacy. Indeed that is a key aspect of it in that you can get a license to transmit after passing the technical & regulatory exams, or simply act as a receiver listening in to those with a similar interest talking to each other anywhere in the world.
If you want secrecy there are MANY internet based services that do it properly.
Forcing the opening up of all systems used for amateur radio use is perfectly right and proper, after all the whole ethos is about understanding and furthering radio use for the benefit of all.
Encryption (or "propitiatory" obfuscation) should never be an option - even for spacecraft command it should be authentication-only to prevent others monkeying with anything important. If that is incompatible with your business then move to a commercially licensed spectrum and compete with the big boys/girls.
"We have no real (at least not this in depth) assurance that products from rival vendors are more secure"
If, and it seems a good idea, that critical infrastructure needs to be secure against both back doors and crap code, then it should be a requirement that the alternative suppliers are similarly audited to show they actually do better. After all, it is not that Cisco have no history of both back doors and serious bugs needing fixed either...
Those "11,000 lines" could well be just the header file's function / class definitions, you know the stuff that has to be exactly the same for an implementation to be compatible?
A crude 'wc -l /usr/include/*.h' on my box reveals 52,771 lines of text for the standard C header files, easily 11k lines of "code" by a certain definition.