Posts by Mike 137 1817 posts • joined 10 Sep 2009
A verified example of such confusion shows how little it takes to accomplish - a short piece of black sticky tape on a 35 mph sign resulting in autonomous acceleration to 85 mph.
Maybe we should rephrase that as ' "cloud first" already allows for non-cloud deployments when justified by initial cost'
Once they have you by the long and curly contract, the price can be hiked at will (it really does happen). And it can be darned difficult (and expensive) to migrate to an alternative provider, particularly if you rent SaaS - due to compatibility problems.
These norms look fine on paper (screen). But how are they to be enforced? Telling a thief not to steal your car because you need it to get around may not actually prevent the theft.
The fundamental problem about rules of war is that wars are fought to win. There'll always be some belligerent to whom that's more important than codes of conduct.
An exercise like this was done by Trinity House some time back (I forget when exactly but around 20 years ago). They sailed a trawler up and down past Grimsby and jammed its GPS signal (awfully easy to do). There were two interestig findings: [1] at one point it broadcast that it was doing around 200 knots over land, and [2] the "fallback" radar navigation system didn't work because it used the GPS clock for synchronisation.
"They have the details already thanks to a previous **** up."
I can't find a reference, but there was also a report on the BBC news just prior to the final departure that a list of Afghans seeking to leave for safety reasons was handed (not sure by what national force) to a Taliban checkpoint "so they could let them through".
"I have known certified people who couldn't code their way out of a paper bag"
Indeed, but their CV/application form probably got past the HR "rejection" round.
I'm have over 20 years in data protection consulting, but because I haven't taken (and won't take for ethical reasons) a 4.5 day plus pub quiz "qualification" there are many opportunities where I could be really useful for which I don't get considered.
It's mostly because the people doing the hiring - and often the people a successful candidate will report to - don't feel they know enough to judge candidates on their real merits and can't be arsed to get help to do so.
Some time ago I had to select a penetration testing service for long term engagement with a large company. As it really mattered to get it right, I set up a multi-round selection process culminating with a scored interview between representatives of the final round candidates, myself and the CTO. A t the end of that exercise I received the CTO's scoring sheets and for every candidate every question was marked middle of the range. As a result the final decision rested with me alone. This wasn't a dumb or lazy CTO. Far from it, but he just felt unsafe making decisions in a technical area he wasn't expert in. Sadly, at that stage, technical expertise had already been largely tested - we were supposed to be primarily testing business acumen and bullshit rating, which he could have ranked reliably.
"Vendors' counterargument generally suggests that individuals and services organisations that claim expertise in a product or technology should be willing to invest in certifications to prove their skill"
That's a reasonable argument, provided the said certification does actually "prove their skills". I don't know the Red Hat ones, but most I've encountered, in general operational IT (and particularly in the security field), definitely don't. About the only really adequate ones at least used to be the Cisco hands on ones, as the proof was in the resulting configuration, but powerpoint based computer marked certs are, pretty much across the board, a complete waste of time and money. I say that advisedly having both regrettably taken, and (even more regrettably) delivered and authored them under contract.
Even supposing you can impart usable knowledge via slides in one week, it's impossible to test real competence using multiple choice tests, as the real skill is the ability to work out what the question is before answering it, but multiple choice not only provides the question - it actually prompts the answer. So all you get for your money a is a certificate of the ability to remember at best some formulaic concepts for around four days.
A certification of real value would require either a verified practical (as for Cisco) or a requirement to explain a topic. That means of course free form questions and subject-competent folks to mark them. Not only is that expensive to run, but there is evidence that these days a lot of candidates can't cope with that type of question regardless of their subject knowledge, as they have difficulty expressing their ideas clearly. So there's a problem for certification providers. Unless a high enough proportion of candidates pass, the cert goes out of favour and they lose the revenue. The practical solution is therefore to make it easier to pass, and that means multiple choice. As it's also cheaper to run, there's no argument against.
As with mainstream education, the ostensible outcome (of delivering capable people) has effectively got lost as other considerations take precedence.
"One, we've never lost everything," said the captain, referring to the nightmare scenario of all WECDIS terminals simultaneously crashing or corrupting
Yet
"Two, we no longer have the skills to operate a paper chart."
You're expendable when 'one' happens.
" the .dbf file format can use one of two values in its header – fieldLength or fieldType – to determine the buffer size of a database record"
Sounds like while coding someone failed to notice that a suitable variable had already been made available and duplicated it. There was a conceptually similar c*ckup by someone at MS a few years back, where someone created a function that required as a parameter a pointer to another function. Someone called the first function, passing a pointer to the pointer to the second function.
Typically this comes down to rushing jobs without application of sufficient attention. I encounter it all the time when developers are working under pressure.
This kind of divide occurs to a great extent because of cultural confusion between the World and the G20 (from the perspective of the G20).
But the telecoms divide dwindles to nothing compared with the fact that almost 40% of the World's population still lives on less than $2 a day.
However the confusion is perfectly illustrated by a Goooooooooogle search for "$2 a day". The majority of the results on the first two pages refer solely to America, as if poverty didn't exist anywhere other than in the land of the free.
The truth about SIM swapping had to surface eventually. We've been told in thepast that it only targets the "elite". We've been led to believe SMS token authentication is a robust system. However at least a decade ago it was being shown to be vulnerable, and a couple of years back EUROPOL publicly declared it should be avoided.
Yet now we're being forced by our banks to implement SMS token based "security" for online banking. That's insecure "security" on top of insecure transactions.
How about working on producing code that isn't still littered with bugs after all the years we've had to practice coding?
As an engineering product, software is the worst. No other branch of engineering would allow constant fixing of flaws in design and implementation for the entire life of a product, and in some cases you'd be prosecuted if you tried it on.
'"this build includes a change that aligns the enforcement of the Windows 11 system requirements on Virtual Machines (VMs) to be the same as it is for physical PCs"'
" this will have an impact to aspects of the user experience "
Getting software right is to a great extent a matter of attention to detail. It might inspire a bit of confidence in their ability to achieve that if they could at least cope with something as simple as expressing simple concepts such as these grammatically.
"Russia is a very young democracy"
Russia is not, and never has been, a democracy. Its political culture has not significantly changed since the forcible unification of the principalities by Ivan Grozny. The vocabulary of the cadres changes but the nomenclatura still aims to stay in power regardless of most other considerations. Despite the changing polemics of the moment, it's always been primarily a power struggle among the political elite rather than a concerted attempt to impose a stable objective social order, hence Lenin's famous comment "first we take power, then we decide what to do with it".
nobody thought that in a DSP class, not using DSP would be the solution
I've faced exactly the same kind of problem. Our instrumentation controller is written in Java, but solely because we need cross-platform executability. In other respects, Java has proved to be a bad choice. The application is essentially a real time system, but natively (i.e. just using the standard libraries and instantiating everything as transient objects) Java is really bad at that. So I have to get developers to break with their ingrained Java mindset. This is actually very hard, not least as it involves persuading them to think outside "object oriented" and code statically to avoid delays and timing jitter caused by unnecessary instantiation of large numbers of objects and automatic garbage collection. Doing this, however, has improved timing precision and consistency is some areas by several decade orders.
"course I was to teach being dictated by when the kiddies had to take their little tests"
Ditto.
I've taught electronics and "ICT" to UK level 4, and in both cases the "tutor pack" contained everything required including a crib sheet of answers to all the tests so the "tutor" didn't have to know the subject. In both cases also, the student practicals were patronisingly trivial. For example on the electronics course the sole PCB practical consisted of "write your name on a piece of copper clad board with a resist pen, then put it through the automated etch machine". I broke the rules, and (this was in the hand taping days) taught them about track widths, spacing, corners and layout decisions. Fortunately, the faculty supported my decision. However the examining body could have decided to fail all my (better informed) students because we hadn't stuck to the syllabus. Fortunately again, they didn't, largely because of the faculty support.
"Shaking off a large jolt ..."
The problem is ancient. My father's school physics teacher (1930s) was demonstrating a Wimshurst machine, intending to cause a big spark. He failed to notice that someone had replaced the brass spark gap electrodes with vulcanite ones (presumably to do charge experiment). He wound and wound the handle but nothing happened. So at last he assumed the spark gap was too large, grabbed the electrode arms to adjust them and positively lit up.
@martinusher
"writing code is relatively trivial compared to the actual mechanics of understanding and organizing solutions to problems"
You could not have said it better, but tell that to most software developers. They're typically embedded in a "how <insert language> works" mind set that tends to completely ignore whether an implementation is functionally optimum or not. There's usually very poor communication between specifiers and coders, resulting in too many detail decisions being left to the coders. Even agile user stories are generally much too lacking in detail for safety, so many design decisions get implemented without proper functional validation.
The main missing lesson is the basic principle that where there are alternative approaches to solving a problem they should be discussed, not decided unilaterally. However in my experience many developers get annoyed by "being challenged" by anyone not as au fait as themselves with the programming language being used - there seems to be an assumption that the language, rather than the product design specification, dictates the algorithms. Could this be why many software products don't behave as expected?
I agree. A important problem is the assumption that "technology" means computers" and they must be used everywhere. This has led in some cases to decline in the effectiveness of education. For example, practical exercises in physics (particularly electronics) are frequently conducted using (at elementary level) sealed computerised modules or simulation at more advanced level. This of course leaves out all the uncertainties that surround the use of real components, understanding of which distinguishes the expert in electronics from the non-expert.
An example of the problem is the PHYS:BIT "potential divider" demonstrator, a closed design computerised wheeze which conceals the real (and incredibly simple) workings of potential dividers behind a crude representation that, for all the student knows, could be delivered by any mechanism at all, including just an arbitrary program driving the display. The truth is concealed to the extent that in one place the supplied lesson plan requires (specifically) a straight line to be drawn through some points on a graph and then asks "Can you explain why there is a straight line through the data in the Voltage versus Resistance graph. (Hint: Ohm’s law)". A smart student might well respond "because you told me to draw one. Furthermore, the entire experiment could be performed for around the same cost using a few resistors, some jump leads and a really cheap pocket multimeter,. This would not only expose the real workings of potential dividers (including their idiosyncrasies) better but could be applied to other experiments as well.
Not every learning situation demands, or can even necessarily profit from, computerisation, and even where it's necessary the way it's applied can be an important consideration. I say that advisedly as the developer of an experiment automation application for controlling lab test gear. In such contexts, computers are extremely useful in support of observation and thinking, but cause serious problems when they're used to supplant them. We designed our application to automate the task as far as possible without concealing from the user either what is going on or how it works. As a result, the application can be used not only to automate vendor equipment but as a basis for developing and controlling one's own inventions. And that's what learning is really about.
"have app runtime permissions expire on older versions of Android for apps that haven't been opened for several months"
By virtue of their purposes to Gooooooooooogle, "runtime permissions" most likely constitute consents to processing of personal data. Unfortunately, under the GDPR at least, the right to withdraw such consent is vested in the data subject. The data controller does not have the right to unilaterally withdraw that consent independent of the wishes of the data subject. If they want to do this, they'll have to find an alternative lawful basis than consent that allows them to do so.
This was thrashed out pretty much as soon as the GDPR came into force, when many organisations erroneously sent out emails to all data subjects on their CRM databases stating that their personal information would be deleted unless they responded with consent for retention. It was unlawful then and still is.
However as this policy, as reported, is restricted to "older Android devices" it's most likely not about helping "protect user privacy" but about making it annoying not to upgrade.
How long before someone decides to hog the booth, leading to street fights in the queue?
Phone calls, particularly from public booths since they took the doors away, have tended to be short. Using these data services and even phone charging commonly take a lot longer.
I completely misunderstood this headline - visions of hypersensitive folks questioning the ethics of data centres diversifying into financial services in general. That looked interesting, but when I read the piece is was about the technicalities of a specific data centre doing so, in which I wasn't interested at all.
Fun headlines still need to impart a reasonably clear message. The classic of this questionable genre is probably the wartime (possibly apocryphal) one: "British push bottles up Germans" but there are thousands of them and the population is growing exponentially as everyone shouts for attention over the noise of everyone else shouting for attention.
It's actually all rather obvious if you just stop and think. Thirty-odd years back when I was doing research, pretty much everyone seemed to be able to make these judgements for themselves and they mostly got them right. Now it seems they need to be guided. I can only assume that the generation of researchers who grew up with an open web have had their personal ethics blunted by notional "freedom of information".
And it still works fine. it's also the last MS OS over which the user can exercise a modicum of control.
Every time an instance of an "out of support" OS crashes it's for some weird reason "news". If it were news every time a current one crashed, a truer picture might emerge.
Yes, an "unsupported" OS may (and I only say may) be more vulnerable to attack than a "supported" one, but by virtue of the fact that the current OS still needs its "support" jock strap, it's not a foregone conclusion.
I know of no mainstream OS or application that has been determined free of hazardous bugs prior to being superseded by a new version that proves just as buggy as its predecessor. That is the harsh reality we must face up to as we make ourselves ever more dependent on the worst quality products among all branches of engineering.
Around the same time a colleague and I created a macro assembler for 6502 and an Acorn compatible disc operating system on an Acorn Atom. I wrote the drivers using the macro assembler and my colleague built them into a DOS using the same tool, starting by saving his work on tape and progressively migrating to disc as development of the DOS proceeded - ultimately developing it on itself.
"Could you not solve the pigeon problem by making the laser a bit more powerful?"
Zapping live pigeons still interrupts the signal, and pigeon droppings don't burn off optical glass as they're essentially non-combustible. Plus the weight of roosting pigeons can deflect the laser so its beam misses the detector. At the distances involved a very small angular deflection results in a large movement at the detector.
If I remember rightly the transmitter was on the roof of the UCL electronics building in Malet Street and the receiver was on the roof of Kings College on the Strand about 1 km away, but even over that short distance, angular aiming accuracy has to be very high.
So one of the much hyped benefits of cloud (expert security off your hands) is no longer the case. Not surprising really. What many folks don't understand is that cloud services are not hugely profitable on an individual customer basis. The value comes from volume. Consequently, any service that's used by the majority is supported strongly, but services used by only a few don't get the same attention. That's actually the same as in practically every large scale big customer base business.
The screen apparently cracks on this cracks if you close the lid on a "small object".
I could stand on the case of my first IBM PC XT and the monitor, although it weighed a ton, survived numerous rattling journeys in the back of vans when changing student digs.
Finesse and fragility often go together (maybe to some extent unavoidably).
Long before any of the products, Sinclair was already being useful in the technology sphere. Somewhere in my library I have an A4-ish thin flimsy publication by Babani publishing. If I remember rightly it's called something like "Using Transistors" by Mr. Clive Sinclair, and must have been first published in the early '60s.
Those were the days when the upper Edgware Road in London was almost entirely populated by electronic component and surplus shops - including the famous H.L. Smith, where you could buy almost anything even remotely electronic. I got my first helium neon laser (and probably this book as well) there among many other things.
"The two parties, in this situation, are the "data controller" and "data processor""
Not necessarily. If, for example, the NHS stores all our medical records, they may make tem available to other organisations, not as processors on behalf of the NHS but for the purpose of those other organisations (e.g. university based research projects). In this case the relationship may be joint controllership or sharing. Obligations on joint controllers are strictly specified, but obligations on sources of information are much less so under sharing agreements unless that sharing takes the data outside the data protection jurisdiction or approved third countries. It is *unfortunately) assumed that every data controller within the relevant or approved jurisdictions will abide by the law.
And by the way, " If the controller has established that the processor has a legitimate reason for having and processing the data, that is all they need to do" is not strictly correct. A processor can only process on the direct instructions of a data controller that specify exactly what is to be done with what data for what purposes. So the only legitimate reason a processor has is having been specifically so instructed by a controller. That's primarily why the use of behemoth processing services (e.g. Mailchimp, Survey Monkey) are legally questionable, as their typically non-negotiable unilaterally imposed contracts with their customers (the controllers) specify the processing despite their being officially processors on behalf of said controllers.
That's the big problem with GDPR Data Transfers in general. A data controller has no statutory obligation beyond verifying the legality of the recipient's privacy regime. Liability for what goes on under the radar after the transfer has happened is specifically excluded. This was made clear quite a while back in relation to tracking widgets on web sites. The site owner is responsible to data subjects only up to the point where the tracking message leaves their site. Thereafter the responsibility to data subjects passes to the recipient of the data. As a result it has emerged, at least in practice, that the transmitting party generally doesn't care what the receiving party does with the data (beyond of course the utility of the exchange to itself). This necessarily undermines the entire intent of the relevant regulations.
The validity of the risk decision depends on who's risk it is seen to be. If the data anonymiser or user defines the risk, is it risk to themselves (getting caught out) or risk to the data subjects? If the former it's the wrong risk to consider. If the latter, they're far from the best judge.
Bearing in mind the poor quality of most corporate risk decision making (limited investigation, fragile methods), attempting to assess (to you) hypothetical risk to some third party accurately is almost impossible, particularly in aggregate ("risk to this population"). But quite apart from any inadequacy of information or technique, potential for harm depends not only on the event but on personal (i.e. individual) circumstances, so risk to the population can be too crude a measure. The outliers may be the important instances.
The GDPR itself is pretty weak on this. Despite using the term "risk" dozens of times throughout the text, the only two categories of risk it specifies are "risk" and "high risk", and it provides no significant guidance (let alone any definition) of where the threshold between the two sits. As the party deciding on risk in that context is also the party interested in processing the data, this presents a serious failure of governance..
"Dirty and biased data will lead to a bad model"
Even ambiguous data is a problem, as quite possibly is training and even some underlying algorithms. There's a recognised condition called underspecification, where use of machine learning yields multiple equally weighted alternative predictors in training but they diverge in the operational context.
It was even posited mathematically in 2014 that any system ultimately running on a Turing machine is intrinsically incapable of resolving certain problems.
My observations of bumble bee intelligence suggest it's very like modern AI. They seem to develop a visual/olfactory template reinforced by trial and error success rate. When something changes they're flummoxed. For example. I used to have bumble bee nests in my wood shed. The door was a bit ancient and had a quite small hole rotted in its bottom which they used to get in and out. However with the door wide open they hovered about, unable to cross the threshold in either direction.
I've been following developments in "artificial intelligence" since the mid-80s and I annoyed several pundits back then by saying "when you can build a bot the size of a bumble bee that can do everything a bumble bee can do with the endurance and performance of a bumble bee, then you'll have accomplished something".
So far as I know this hasn't yet been achieved, so creating an adequate replica of human mentation still seems quite some way off.
"Bhatia explains that Facebook needs compression because its apps keep bloating"
Maybe that's the first problem to address. I have a few well written specialist applications that have excellent performance and will run on almost any Windows box and they have one other common property - they have a really small code base. For example a powerful optimising C compiler for PIC with an advanced drag and drop IDE - the whole things is a few tens of megabytes apart from the device specification files, and it runs on everything back to XP SP2.
Bloat primarily occurs as a result of "tweaking" as opposed to re-engineering. In modern applications there's often a lot of code that never gets executed, either because it's part of a massively redundant library or because it got left in when it was no longer needed by the next version. In either case it never gets called at run time, so it might as well not be there.
Compressing the redundant stuff - however expertly - seems to be merely first aid rather than medicine.
"Harm arising from online technology comes from the actions of those on it, rather than the technology itself"
Quite a large number of folks in the UK don't have access to an adequate broadband connection so they're denied services and even have difficulty fulfilling their legal obligations (statutory returns etc. now increasingly "online only").
There's also the "disintermediation" harm - even for those with potential access, failure to keep up with ever changing (and often needlessly changing) technologies locks people out of services previously available to them, forcing further expenditure, which is of course commonly the prime vendor motivation for the change.
Not everyone is in a position to replace at their own expense equipment that still works perfectly well but has been rendered obsolete by creation of often artificial incompatibilities. However when this is mentioned in public one usually gets slated for being a "Luddite". It's worth remembering that the Luddites only broke machines that directly threatened their livelihoods - to the extent that they generally left adjacent machines on the same factory floor that didn't threaten their livelihoods unharmed.
OpenAI knows this, which is why they and anyone else with half a sense of foreboding are so hot on developing AI ethics"
AI ethics are at best a misnomer. The best that can be done is to implement an inevitably rule based system based on the ethics of the AI programmer and/or trainer (which is of course an arbitrary set of ethics, not one spontaneously developed by the machine as humans do).
In the conclusions to In AI We Trust: Ethics, Artificial Intelligence, and Reliability published last year, author Mark Ryan states "One can rely on another based on dependable habits, but placing a trust in someone requires they act out of goodwill towards the trustor. This is the main reason why human-made objects, such as AI, can be reliable, but not trustworthy, according to the affective account.", making the important distinction between reliability and trustworthiness.
It turns out that there's a cluster of human talents that are inherently missing from anything that ultimately runs on a Turing machine.
"Not everyone learns by sitting still. Some of us do so much better by doing, not reading."
Whether primarily based on doing or reading, real learning starts with having to work out how to do. The basic paradigm of most mass education systems is defective. It assumes that [1] "everyone" can make effective use of the same message; [2] being told something and remembering it is equivalent to knowledge of it; [3] commonly, that nobody should be allowed to "fail" as it's bad for their psyche.
The reality of knowledge is that it's demonstrated by the result - being able to use it effectively in novel circumstances, and that capacity is to a great extent acquired by having to solve problems. Consequently, failures are not only inevitable in the path to knowledge, they're essential - provided there's an opportunity to correct them and learn from them without censure.
"organisations would be required to implement a privacy management programme tailored to their processing activities"
Considering that over the first two years since the GDPR came into force, not a single one of the 400-odd organisations we monitored succeeded in achieving legality in the most basic requirement - transparency about their processing - I don't hold out much hope.
However even the EU seems OK with that. Paragraph 49 of the UK Adequacy Decision states: Data subjects should be informed of the main features of the processing of their personal data. [emphasis added], which implies that the full disclosure essential for the exercise of data subject rights is no longer considered necessary even by the originators and maintainers of the GDPR. Nobody wants all those pesky challenges to their business decisions and processes.
'the need “to provide human review [of AI decisions] may, in future, not be practicable or proportionate.”'
If (as the above suggests) it will be deemed impossible to establish the basis of an automated decision, the ability to challenge it and have it reviewed by a mechanism open to discovery as to basis (e.g. a reasoning human) is fundamental to human rights (if not the limited legal ones, then the wider moral ones). Otherwise it's in constitutional terms no better than the whim of a dictator.
"Computer says No" was intended as a jocular warning. If this proposal gets accepted, we have the prospect of it becoming a legally binding fearsome reality.
"Giphy, styled as GIPHY, is an American online database and search engine that allows users to search for and share short looping videos with no sound, that resemble animated GIF files" [Wikipedia]
Why could this be worth half a billion (some say $400k)? Obviously it has a data slurping angle like all these online "services". but what I can't get my head round is its assumed popularity. They'll need the head count to make the money, but why would anyone sign up to this specifically, seeing there are so many other ways to share all sorts of images and data. This isn't just a rhetorical rant - I'd really like to know what makes this remotely interesting.
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2021
