Posts by Nick Ryan 3756 publicly visible posts • joined 10 Apr 2007
What a strange assertion - and very incorrect.
I nearly replied that replacing core modules that are holding a space station together in orbit both physically and by way of facilities (plumbing, wires, power and so on) can't be harder than dealing with corporate IT and then I remembered certain suppliers...
While the PCI-DSS requirements are pretty solid, where much of the problem comes from is organisations that adhere strictly to the PCI-DSS standards rather than attempt to use any sense and go beyond them, to produce more secure systems. Instead it's often considersed "we're PCI-DSS compliant and therefore don't have to think security ever again".
Standards are the only damn reason why things work.
We can pick up a phone and speak to pretty much anyone on the planet because of standards. In the early days of telephony and before international standards were set this was not possible.
We can email anyone else because of standards. Remember the horror shit-show that was AOL and Compuserve with their internal communication messaging systems that they grudgingly shifted towards standard email?
We cannot do the same with a video call. Instead, we have to use a variety of bespoke and non-interoperable services to communicate with whatever is available at the other end. It's shit, in other words - and this covers Zoom, Teams, HangOuts and all the other services that used to be used before the pandemic hit.
So why are this repository and its administration being specified by politicians and not by doctors?Cynically I suspect that very much it's not the politicians that doing the specifying, it's the organisations (likely US pharma) that are paying the politicians that are doing the specifying.
The ONS has secure rooms where one queries the data. Essentially it's a double remote desktop system through their provided PCs. There's no network access to anything else and cameras and such to enforce things. It wouldn't stop someone remembering the raw data and writing it down outside, however as an Accredited Researcher with them one of the things that I signed was personal responsibility: I am personally legally responsible for the access.
There are also remote access options available however I believe that this does depend on the data being accessed and the organisation requesting access. These have necessarily been more common since covid hit. The remote access is essentially a web based remote desktop session - wouldn't stop someone recording the screen remotely but the data would have to be scraped rather tediously.
Secondly, the external researchers would only access the data through a Trusted Research Environment whereby they execute queries on the data in situ, rather than moving it for analysis.This point appears to have been missed. The Office for National Statistics (ONS) hold a great deal of personal data, Census, Labour Force Survey, Crime, and so much more. Access to this data is through their Secure Research Service (SRS) and in order to access this data one must be an Accredited Researched (I am one, hence why I know about this) and submit a project proposal listing the data analysis to be performed, the datasets required to do so and the outputs that will be generated. Once approved, all processing and manipulation of the data takes place within the SRS environment and when data is requested to be output, it is provided to the SRS staff who check it (and they really do check it, carefully) before the data is made available to take away.
Obviously, like anything else involving people and so on, there is scope for abuse and mistakes but it's a pretty solid process and much better than just giving the data away. Implementing something like this is a huge improvement compared to what the earlier NHS data grab was going to do: just hand the raw data over to private companies.
There's another post here in these comments that adds more to the story: https://forums.theregister.com/forum/all/2021/07/20/new_shepard_crewed_flight/#c_4298703
Yep. I was at the National Space Centre the other weekend and there's a whole section on the female astronaut trainees who underwent all the training, in general passed with better scores and a higher ratio of them passing than their male counterparts... and then were all unceremoniously dropped because they were female.
It's a classic case of feature creep, in this case more specifically network attachment creep.
These devices were always designated for use in trusted environments and the vague stab at security was largely there to prevent tinkering by users that weren't privileged enough - almost to protect more from accidental changes than intentional or malicious ones.
A trusted environment in this case is where everything networked together is trusted and no non-trusted systems are connected. This works fine and has worked fine for many years, however then some numpty decides that for convenience they need to connect the trusted network or trusted systems to some other network. This isn't, like the initial comments here, directly connecting to the Internet (although some car manufacturers have genuinely been this incompetent), it's connecting to other networks, such as a more general office network. After all, the management systems, which are inevitably PCs of some flavour, are all usually networked together and the devices that they monitor and manage (through a dedicated communication protocol specifically for it such as ModBus or CANBus) are networked together therefore why not connect everything together? Well, the why not is obvious to anyone with any form of security clue however that often doesn't apply to the typical developer who when confronted with security their default response is to assign or require Administrator access to everything just in case.
Another commenter's remark about just having access to the control network is enough to disrupt things - network packets can be easily spoofed, amended or just flooded any of which are easily capable of disrupting operations and, frankly, without the detailed plans of any specific control network's design and operation the most effective way to damage things would be to flood the network and prevent monitoring messages from being processed. For example, a pressure sensor that sends values directly to a valve controller if the valve controller no longer receives the pressure readings it won't close off if the pressure gets too high - a simplistic example but that's the kind of thing that's commonly implemented.
I knew of a sales guy (yes, always the sales guys) who got fired before he started his job. He was invited to the pub the Friday before the Monday he started (the place had a good social crowd), got drunk and proceed to verbally attack the CEO and various other people.
He was a nice enough guy when sober, although he had almost no morals (perfect for sales), but when drunk... just best avoided at all costs.
VS Code "is capable of running code from the workspace on your behalf to provide a richer development experience,"
Compiling and building code is one risk with external sources, but automatically running shite that it happens to be in a directory is just typically negligent and stupid.
By the same organisation that created auto-infect/auto-run, executables in emails and ActiveX in browsers (hell, ActiveX has just always been awful)
I'll agree that it is a risk with Terms of Service for private organisations. The control measure is that these organisations also need to protect themselves from being sued for the content that they host, and not clamping down on illegal or otherwise inciteful or damaging content is asking for this kind of trouble.
In this particular case, he kept his accounts only as long as he did because of the very real fear of retribution against the organisations for applying their Terms of Service to his accounts - any other user spouting the same level of hate, bile, rabble rousing and incitement to criminal behaviour and so on would have had their accounts closed much sooner. That's the real injustice of it all.
Hmmm... I read it that the aim was to produce a camera (sensor) that only sends the changed information and not so much just the use of a normal camera sensor after which lots of processing is performed and then the data is sent. The latter would not be low power, although it would be a suitable way to prototype the algorithm.
As noted already above, slow changes would have to be filtered out somehow which means that individual light sensors would likely have to directly communicate/be compared with their neighbours and to only send an update if a light reading had moved beyond a certain threshold.
Argh! Too memories of dealing with the horrors of Microsoft Access databases... Where, depending on the current wind direction, speed and phase of the moon, an empty string column may be returned as " " (single space), or it could be returned as "" (nothing) - set the value to "" and the read it back and it would return " ".
Microsoft has basically tweaked Office to bring it in line with the Windows 11 user interface and its Fluent Design principles
It's the Operating System's job to render applications. However, Microsoft insists every damn time that they "refresh the look" of Microsoft Office to whatever the current fad in their latest Operating System is, to re-implement all of the window and control rendering within the application rather than let the Operating System do it. It's an ongoing example of rampant stupidity and duplication and is one of the reasons that Microsoft Office is so bloated, slow and unstable and hard to port to any other platform.
It may not be great to connect an old/unsupported system to a network, however it is very easy to do safely.
Don't forget that these are are "kiosk" or "appliance" type installations, they are not configured as a general network for general use. [Well, they shouldn't be anyway]
It is easy to configure networking such that each client is isolated from all other clients on the network and to only have very tightly controlled network connectivity to, for example, a central server system. There is often no need for a client to be able to communicate over the network with anything other than the control system.
Things get a little more complicated where remote access to the installed client is required, inevitably for support purposes, but this is far from difficult to configure either.
You need to know about Microsoft Windows 11. It's the latest thing from a dominant monopoly therefore avoiding it is near impossible and counter-productive unless your mentality is one of "I don't like what I am seeing therefore I am going to shut my eyes and walk around blindly pretending that I didn't see it".
As for what you need to know about Microsoft Windows 11? Largely that it's little more than a minor UI reskin, a further attempt to lock users into Microsoft's online rental ecosystem, all with an extra sprinkling of needless hardware requirements to enforce unnecessary hardware churn.
They also invested millions into user interface metrics and research and produced very good style and usability guides.
These were immediately ignored by other departments within Microsoft such as the department responsible for Microsoft Office.
I suspect they gave up with this investment as it was not generating immediate profit and also was not being used by their own developers.
Typically useless "Check tool" from Microsoft... run the thing:
This PC can't run Windows 11
While this PC doesn't meet the system requirements to run Windows 11, you'll keep getting Windows 10 updates.
[Learn More]
Does the [Learn More] link tell me what about my PC does not meet the requirements of Windows 11? Like fuck it does. Just a page of requirements.
Typically similar to the all too common moronic "an error has happened" type error response (as in "we know what the error is but we're too lazy or stupid to trap it and to give information").
There are also a few not entirely great things about the use of hydrogen as a fuel:
None of these are impossible to reduce the impact of, but they all add up to a fuel source that is somewhat more involved than the simplistic "hydrogen is great as it just produces water as a by-product" that many people think it is.
But... but... everyone in the world is North American. Everybody. Absolutely everybody... surely this is so? It cannot possibly be not so? (breathe) But North Americanish culture is everywhere. Everywhere has the same ideal don't they? Except for the red commie scum of course. They don't. Everybody else in the world does though.
The US: One of the three remaining backward regimes in the world which still uses Imperial measurements, believes that their culture applies everywhere and persistently tries to brainwash the world into thinking that the US has a democracy.
It's usually more interesting, and often more valuable, to try to work out which organisation paid for the gartner "report" - to see what agenda they are trying to push. Gartner have no value whatsoever in anything otherwise.
Oh noes... now I'm remembering the horrors of people trying to stuff multiple, independent status values into a single column. Kind of works when there are just two status values as they just multiply together and as long as there aren't too many it sometimes works out OK. As soon as they want to add a third status though it's just a mess. Pretty much a really bad idea all the time.
Oh no! Table data stuffing... shudders... it was only a couple of years ago that I came across a moron developer thought that using tables and rows and columns was far too inconvenient therefore stuffed data in an exported XML stream into a single column.
I still see so much similar stupid done in databases, where individual columns are stuffed with multiple row data rather than using the database to store the rows. Master > Detail is such a basic concept but lost on some.
As for users stuffing too much data into a field, the number of arguments I've had about the storing of data in free-type text fields. If they need to store something in a structured way, store it in the database properly, not as a random-ish mash up of inconsistent characters stuffed into free-type text fields. Which the inevitably want to report on and then get annoyed when data is missing due to their typos...
Dyslexia seems to be rather common in technical fields... unfortunately SQL queries and data definition editors don't have spell checkers, unlike source code. OK, source code isn't exactly a spell checker but spelling mistakes are flagged up and it's often a simple matter in a modern IDE to rename a local variable of function. Doesn't help so much with anything that's published though...
nvarchar(max) is not as bad as you might think in terms of performance. If the data is small (for example 'Y'/'N') then it is stored in row, not off-page.If only things were so simple... MS-SQL server does try to do some clever things when it comes to the (max) data type columns, however as soon as there are too many of them in a table definition then the MS-SQL optimiser seems to go "I give up, you made this mess, you deal with the consequences".
There are various table options that can be used, either to force large data columns out of row storage or to ask MS-SQL to try and store large data column values in-row ("text in row" table option). The table option "text in row" is also set to be removed in a later version of MS-SQL so relying on it is very much not a good idea.
Testing these options are a little tiresome as because the data storage method is only changed when the column data is updated, which is a simple enough query but is not quick and locks the entire table just in case anyone tries this and wants to continue with other testing while the update is applied.
From my observations and testing, using Microsoft SQL 2016, as soon as a column is specified as nvarchar(max) query performance goes to hell. Changing the column datatype to something sensible like nvarchar(30) makes a considerable performance improvement.
In short, nvarchar(max) and so on are not evil as such as there can be good and genuine uses, but performance wise it's like using variants all the time.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
