Re: Gum them to death.
"Yes, and how much have they collected from these companies?"
More than it used to. The ICO has been blocking companies from phoenixing and going after directors
This has been happening BECAUSE of questions like yours
14469 publicly visible posts • joined 8 Feb 2008
"Majority of businesses and organizations are not sufficiently secure. This will NEVER change."
Personal legal liability of manglement for breaches would focus attention. One of the biggest problems IT bods face is that the people with the resources don't see the need for improving security until an event has already happened
Forgetting all the issues with engines and efficiency, these proposals invariably run into 2 major issues which grounded the Boeing 2707
1: Going much faster than Mach2 requires specialist and very expensive metallurgy due to friction heating.
Stainless steel is doable on Rockets because the heat impulse is short lived (launch and reentry are minutes, not hours)
2: At these speeds, sonic booms are a major problem even if the aircraft is at 60-100,00 feet
XB70 proved this in the 1960s and SR71 operations underscored it - people can put up with a couple of light booms a day but not the kinds of repetition associated with commercial operations
NOISE is a major major issue and it's _already_ limiting speeds on terrestrial high speed trains - Shanghai maglev had to be slowed down most of the day (it only hits max speed on runs for a 2 hour afternoon window on weekdays. slowing down further after dark) and the much-vaunted Japanese maglev Shinkansen is likiely to face similar protests before commercial operation, despite being routed away from occupied areas as much as possible.
It's happened already.
In 1998 NASA discovered script kiddies had pwned the computers controlling Mars Pathfinder and Sojourner whilst investigating odd behaviour
In 1999 and 2000 there were more malicious hacks of command/control systems for various LEO birds (although the satellites themselves diodn't seem to be the target)
Military systems aren't much better. In a lot of instances notifying sites about odd behaviour and script kiddies (mostly Eastern European) spotted operating from obviously compromised systems in military IP ranges resulted in denials and threats until DISA stepped in during 1999 to act as intermediary on all issues
The bigger problem is that THE UNDERLAYING ISSUES HAVE NOT CHANGED - NASA and ESA staff frequently regard OpSec as a nuisanmce which slows their jobs and simply bypass it or ignore rules. Just about every compromised system in NASA found when the late Jay (Cancer Omega) Dyson audited networks had had the security disabled by staff before hackers waltzed in through the doors left gaping open.
NASA and military networks were high value targets for script kiddies back in the late 90s as they had high network bandwidth availablity and were easy to launch DoS attacks from
"lower cost bids that meet the letter but not the spirit of the tender"
Often with the active collusion of those supposed to be in charge of the Tender
The number of times tender requirements have been "rewritten" by procurement is legion. Always go over things with a fine tooth comb before approving what they send out
"I can easily believe they've lost the source (or toolchains) for an awful lot of stuff, too."
I've worked on a number of science cases where the source or toolchain may be available, but is so expensive that RE is preferable in order to work out what it's doing and reimplement it (This is why a lot of places don't like using proprietary software. Opensource means that you can (eventually) rerun tests 30 years later, etc)
I was onboard with the idea of REing old software so it can be updated/replaced but the idea of "patching binaries" will fail anything which is cyptographically signed and is unnecessary if you own the equipment it's running on
This clearly has applications in government-sponsored malware (if it hasn't already happened elsewhere) but I can see a burgeoning use case of much older proprietary software being pulled apart by those wanting to reimplement it (and others wanting to snark the likes of Adobe, etc)
"are we building it right" - should include "are we leaking personal data to 3rd parties?"
My GP has just switched to the THIRD vendor of front-facing customer software
THEY may not be leaking data, but that's no guarantee whatsoever that 3rd parties is not - and we know that Google and FaceAche both aggressively harvest whatever they can get their grubby mitts on
" I've had to work with developers who think the code is more important than the functionality of the product"
Plus more than a few developers whose response is "Why would you want to do that?" and refusing to consider it
That kind of attitude resulted in several crashed Airbusses.
Pilots want to do "that" to test the systems are working properly when things go pearshaped. Users frequently want to do "that" to ease their workflow or test worst case scenarios
"trace elements of Genesis that are common with Mesopotamian/Sumerian creation myths"
Erm, like large chunks lifted wholesale from the Gilgamesh Epics (themselves having been written down about 1000 years earlier but dating back at least another 1500 years) and tweaked only slightly from the original
You can see the garden of Eden/apple/serpent story, Flood, Exodus and others in the early poems
In my expereience: They frequently learn nothing anyway, unless threatened with pain (financial is almost as effective as physical, but emotional works best. People HATE being ridiculed in front of their peers but if someone's constantly ignoring what the users want then it's an effective tool)
I think whiffle bats should be mandatory in any development environment
"if you digitise and automate a shit manual process/cottage industry it becomes a shit digital process"
It's ALWAYS worth analying every step along the way anf find out the hostory of why something that doesn't make sense is included in the process.
It's usually a hangover from kludging around something broken that was fixed decades ago. Once you can point that out it's easier to get buy in on changes
Another thing to bear in mind is that apart from management's near patholigical need to see people "busy"(*), people themselves don't like twiddling their thumbs and anything which halves their time to do a task may result in pushback unless there are other ways to keep them occupied
(*) This applies to maintenance staff in partucular. The guys you see sitting around playing cards are "on call" waiting for something to break. If they are able to play cards all shift then something is going right(**) The guys you can't find when you go to their office may be down a hole somewhere clearing out drains or in a roof inspecting for rot. They're seldom skiving off in the bogs as many micromanagers seem to believe
(**) This applies to things like backup systems too. My robots had 6 tape drives and a hundred slots, not to speed up backups but to ensure rapid restores when the shit did hit the fan. The mangler who only sees 2 drives and 8 slots in use on a daily basis overlooks that requirement
OR if what's in use is cumbersome and what replaces it REDUCES effort
One of my pet bugbears has been when I've brought in a system which has XYZ all built in and manglement insist on tasking people to go develop XYZ all over again (usually badly, for all the usual reason expounded here - users are utterly crap at giving a full list of requirements)
"Medical software interfaces are clearly written by disinterested 16-year-olds doing School projects."
"Kids in Bedrooms" is the term used by one old manager I worked with to characterise Open Source software
He didn't like it when I co-opted the term for shitty UIs in "professional" applications and liked it even less when I used the term in a meeting with one vendor
As I pointed out to him, when OpenSource has a shitty interface, someone always fixes it (and if it has a good interface, someone always comes along with an unusable variant), but for commercial wares you're stuck with whatever the vendor supplies
Opensource frequently ends up with a plethora of ways to access the same data, tuned to the requirements of the people using any given interface. This is NOT a disadvantage
One of my constant complaints when trying to turn a project into a frontend for users is that it's virtually impossible to get people to test things (for various reasons, not least of which is "they're too busy" for manglement to spare them)
The result is that devs work in a vacuum and it's extremely harmful, where weeks are spent polishing the graphics on a turd which is difficult to drive and use no matter how shiny the wrapper
"Remember filament light bulbs?"
Yup, and replacing them with LED made almost zero difference to my power bill(*)
They may draw less, but lighting is a tiny part of the overall equation (especially offpeak - streetlighting switchoff schemes "to save money" have frequently resulted in local authorities being charged MORE for their power as the lighting load was a useful way of shedding excess generation rather than letting burners go cold in CCGT plants)
In any case, things like bigscreen TVs and other electrical kit have vastly outpaced reductions from changing domestic lighting
(*) On the other hand, I haven't had to go up a ladder and change bulbs in a very long time
> Look at ring mains
I'd rather not.
They're not even NEEDED these days (radial mains is perfectly acceptable and tacitly encouraged(*)) but rings save (a very small amount of) money(**) and those who approve the works can't envisage anything else.
(*) I'd like to see a rule change mandating radials for new builds
(**) Mainly because you can put FAR TOO MANY outlets on a single ring whilst radials have strict limits on potential draw
cats and fuel:air ratio legislation in the USA is a classic example of regulatory capture by entrenched interests
US Domestic makers couldn't compete with Japanese ones on fuel economy and the Japanese were bringing newer (more expensive) cats to market which tackled the NOX issues from lean burn systems.
By mandating 3-way cats and a stociometric fuel ratio, domestic makers weren't at nearly as much of a disadvantage on fuel consumption and they didn't have to spend money to pursue more efficient engine technology (This is also the reason why the USA domestic car industry pushed light trucks, truck-based vans and SUVs so hard during the 1970s-2000s - they weren't subject to strict emissions and crash safety controls, whilst the 25% import tariff on them (2% on cars) made the profits even sweeter in their captive domestic market)
The lawmakers were _extremely_ heavily lobbied (bribed) by Detroit to get legislation placed which claimed to be doing one thing, but whose goal was entirely different (protectionism)
Kinda hard to force a client to install these at their own site.
If you can get them to do that you can usually convince them to put the equipment in a server room off limits to cleaners
(Unfortunately then you still have the problem of "security guards" who make it their life's mission to switch off aircon in unoccupied rooms - including rooms full of noisy equipment and racks)
New Zealand's VAT/GST implementation is unusual in that the GST is applied to EVERYTHING except banking(financial) services
The huge mess in Australia and Britain, "where bread was exempt but raisin bread was not" was one of the major drivers of that decision. The government didn't want a system which had been demonstrated to cause expensive court cases over interpretations (Jaffa cakes, anyone?)
The result of that decision was astounding.
GST went in at 10%, income taxes reduced, the hideously complicated system of import duty and sales taxes (which could result in tax being 120% on some items) went away.
The government netted MORE income and within a decade was able to reduce inland revenue staff numbers by 1/3 (nobody in IRD was complaining of overwork either), vs being on track to double staffing numbers on the existing system, within a decade just to keep up
By not having exempt categories, business calculations were easy and it became _very_ hard to cheat the system. In most cases if a rort was going on the government only lost GST income on the MARKUP applied, rather than the entire tax amount (which was a constant feature of a sales tax system only applied at retail sale and required that wholesalers be specially licensed/only allowed to sell to retailers)
"everyone had hard-coded the original value into their programs, rashly assuming politicians would not change their minds"
I knew people who worked in the vehicle registration system. Management swore black and blue that personalised registration plates would never be deployed in New Zealand and ordered the staff NOT to allow for it in the new system they were developing
About 8 months after the new system came online, personalised registration numbers were announced as a new policy from the Beehive. Thankfully said manager had been ignored and modules written "just in case"
I crossed paths with him myself about a decade later.
He was attempting to do offsite backups
By emailing the database files to an office in another city
Said files were ~90MB
Over a 2400bps dialup modem
Using a mail client which didn't declare the size of the message being sent
Starting at 5:30pm each day
That was when I discovered that SunOs 4.1.3 sendmail uses the swapspace partition (containing /tmp/) to buffer messages too large for memory
About the same time as I discovered WHY the system was running out of swap around 2am Tuesday to Saturday was when he sent a snide mail (dead trees) complaining that our service was unreliable. Pointing out the default 10MB limitation on email size was simply unacceptable to him (the receiving end also had a 10MB limit and had no intention of raising it, so bumping my limit was pointless).
It turned out he'd sold "email backups" to the higherups as a great way of reducing costs and had received a large bonus after demonstrating it - with 100kB files
He left the MOT shortly afterwards and then showed up at another large customer. A friend of mine worked there and whilst technically under him, was aware of the damage he was capable of (more importantly had a good personal relationshop with the company owners) and managed to prevent him making changes which would have impacted a multi-hundred million dollar mail order outfit
About a year after that it was mentioned that this manager had left under a cloud. The owners are conservative religious types (Not American conservative types) and one of them had walked into his office to find him broswing penthouse.com on his work machine, at lunchtime. As 98% of the employees were female it was deemed to be a hostile workplace issue and he was walked to the front door by security within minutes (Did I mention that there was a specific prohibition on accessing unauthorised resources from the workplace network as part of all employment contracts? And a firewall which whould have stopped that website even being visible?)
"The HP machine is giving to the family member as a premium for getting the work done and not mentioning it to anybody."
In the case of the NHS, that's an ICO investigation waiting to happen
Medical computers are in a class of their own WRT privacy issues and that applies if all they're doing is running the building climate control. Treat EVERYTHING as if it contains sensitive data and ensure everything is erased (not just signed off as erased) before it goes out the door
That's EXACTLY what's happened in a number of cases in one place I worked (A presitgious department in a Russell Group university)
One serious IT cockup happened because the user in question (now deputy director) had done an end-run around the IT group because she was of the opinion her PhD trumped any of our experience
Sounds like the idiot in question needed removing from the position and what you achieved was job security by letting him keep trashing his employer's equipment (or letting him allow his underlings to do so)
There's a risk with such users that they tell porkies to their management which results in your external contract going away
Such a machine is a cleaner with a floor polisher(*) away from disaster
I've had machines on sites with uptimes of YEARS suddenly stop working - in virtually every single case it's becase the cleaners unplugged it to run a floor polisher - despite the DO NOT UNPLUG/DO NOT SWITCH OFF label on the socket and plug itself
At least one of them has stated that unplugging is not switching off, so they're alright jack.
In a lot of other cases it's turned out that they cannot read (these are people handling dangerous chemicals FFS) and often blag their way through life trying to cover it up
Using an _obviously_ incompatible plug/socket system for critical kit doesn't help. They'll unplug it anyway to check
It's worth having penalty clauses in contracts for external organisations making them liable for damage caused by their staff for any reason and then insisting that the managers read/sign off on site rules/safety instructions. That way when the inevitable "nobody told me..." crops up, you can pull up the evidence that they WERE told and failed to pass it on or send their new staff to the safety briefings as required in the contract
"One of the places*. The writer knows what's meant to happen. And what every step does."
In my last job I was expected to write the instructions and inflict them on users with no further in-house testing
I know full well that marking your own work is a deadly mistake, but the manager REFUSED POINT BLANK to assign someone else to handling this part of the job
Unsurprisingly there were lots of user complaints about stuff and documentation issues took years to be addressed
The same problem cropped up with in-group procedures - even worse, after going through instruction scripts, finding the holes (missing steps. assumptions, etc) I was roundly criticised for treading on people's toes (they were having to write their own docs too, but resented suggested edits being handed back and refused to add them to their official versions, believing the instructions were complete enouigh as they were - this also applied to stuff they'd written for the users).
The result (unsurprisingly) was lots of do-overs and support requests
These are the same people who wouldn't document all the user support they were doing ("stopped in hallways" was a common way of users filing issues instead of using the ticketing system and our people woudln't create/close a ticket when they got back to their desk), resulting in manglement coming down hard from on high about the staff supposedly sitting around idle and not doing much - wanting to reduce headcount as a result.
I'm less surprised about Arnie not going back to the site, than I am about the senior manager not getting his marching orders
My experience with NHS (and other state health systems) is that they take unauthorised changes to critical equipment extremely seriously - particularly the installation of unauthorised servers and alterations of sitewide configurations
Even back in the 1990s the privacy and liability ramifications of this kind of issue would have accountants and lawyers blanching
"And besides, I wouldn't wear one anyway ... these days, it's hard to find a place where one can not see the time."
I've seen a couple of editorials which point out that the rise of mobile phones (even the humble Nokia 3100) has resulted in near extinction of wristwatches - and if you look around you'll see that's pretty accurate (compare videos of people on the streets in the 80s/early 90s with observations today)
I gave up on mechanical wristwatches very early. As a leftie and wearing it on my RIGHT hand, cheap watches would inevitably self destruct when the winder would snag on something and rip clean out of the case (you'd be amazed how often you brush your wrist against things)
recessed winders solve that, but so do lcd watches and they were MUCH cheaper
Or ignoring a perfectly valid message, saying it doesn't exist, even when it's on the screen in front of them and then - after reading it out loud - saying they don't understand it (file not found)
Having a PhD doesn't imply actual ability to solve problems