Re: Fragile. Very fragile.
"Someone came in at that point and stopped him before he fried himself."
There's always a spoilsport.
16426 posts • joined 16 Jun 2014
"It included a database application"
The company was bought by Informix for no good reason except that their (Informix's) then management suffered from a lack of BOFH and openable windows in their offices. They did some work to use Informix as a back end. But only as a back end to the spreadsheet.
"'Data Science Ethical Framework' , a document which betrays not the slightest understanding of ethics, is ethics-free and provides no framework whatever, ethical or otherwise."
The difficult bit was got rid of in the title. It sounds like a very competent piece of work.
"The ICO needs to get real about the size of it's fines and should pursue criminal trials against the directors of the companies too."
The ICO has to operate within the limits that the law allows. One aspect of fines is how cooperative the company is - a company that admits the offence will be fined less for example. In the case of this company it sounds as if there might be scope for increasing the fine. With any luck they'll take their appeal to court.
"in order to be considered a different species, the most important factor was cross-fertility, not mating habits."
What TFA didn't say is that the different song is a factor in mating habits. The two lots of finches don't recognise each other as being the same species. If the Big Bird species survives there'll eventually be sufficient genetic drift to break cross-fertility even if it technically exists at present.
Hybridisation has been recorded as a factor in speciation before, e.g. Spartina anglica.
Deciding whether two things are a separate species are not is a black art. Taxonomists can be regarded as two separate species, lumpers and splitters or as two sub-species of Homo sapiens.
AFAICS the situation is this:
For reasons of promoting competition BT was shut out of cable provision for years. When it became clear that the competitive situation wasn't going to deliver anything like a nationwide service once the cherry-picking was done BT was allowed in and started the much bigger investment of building a much wider FTTC network. Being an experienced telecoms company they laid capacity for expansion; much of the cost is in all the field operations so including the spare capacity now is a relatively small investment compared to what it would cost to do it later.
Now everyone who didn't make such investments in the past and don't want to do so now or in the future want to be able to leech off BT's investment. And if that happens then at some future point when BT needs the capacity that they laid but no longer have and thus fails to provide some service whose fault will it be? BT's!
But infrastructure builders, such as Virgin Media and CityFibre, are less keen on the idea. "They have invested heavily in fibre, and concerned that opening up dark fibre would send the wrong message as it undermines the investment case for rolling out more fibre. It is also arguably at odds with Ofcom's position that it wants to incentivise more fibre investment,"
Maybe. But maybe their objection is that what's source for the goose is source for the gander. If BT's fibre is to be opened up for all comers the same argument can be applied to theirs.
"Which would you rather have: a system that doesn't work or can't be trusted?"
It's a false dichotomy. The effort that goes into the break it now fix should go into the fix it properly fix. What I want, and which I expect Linus to provide, because of this approach, is a system that works and can be trusted.
"So why is it right when Linus says effectively the same thing?"
Linus isn't saying the same thing. What he's saying is fix the problem instead of hiding it.
AFAICS what's happening is that the security researchers are sending in patches which will throw an error if a dubious bit of code is hit even if it wouldn't cause a problem in that instance. They're then expecting him to incorporate that code in the kernel tree for the next release.
What he wants is that the code itself is fixed. That can then be backported into older kernel versions* (that, of course, could also be done with the just kill it fix). However the effort that goes into the just kill it patch could either be put into a proper fix by the researcher or, if that's too difficult, into a proper bug report so it can be fixed. Either fix is likely to go into the same kernel release cycle anyway and it's vastly preferable that it's a real fix. If he allowed just kill it fixes in the real fixes are likely to be delayed.
* Linux distributions don't always run the same kernel version. These appeal to different types of user.
Production systems tend to be very conservative with LTS vernel versions and only security fixes made available as kernel updates. Consistency of operation is highly valued.
More adventurous distros exist for those who must have the latest, greatest, coolest toys. These value novelty over consistency and can expect breakages from one release to the next. A release will have the latest kernel available at the time of packaging.
Users who want to test new stuff - equivalent to the Windows Insider Fast Ring can either go for a bleeding edge distro or install RC kernels in other distros.
"If there are other people in the car, they *should* be making/receiving the phone call instead of the driver."
If use of the hands-free distracts the driver then listening to one end of the call, telling the passenger what to say or even conversing with the passenger when not on a call is likely to be at least as distracting.
"The real issue is not scripts but a lack of a proper life cycle including a rudimentary spec (why are you doing this), peer review, testing, version control, and documentation."
You say that as if they're good things - which they are, of course, as is repeatability. Because, as you say, scripts are small programs these can be applied and more easily than into manual operations; even if the latter are written down in your ops manual as an - errrm - script you still rely on the operator following them.
You should not be relying on them for everyday tasks, or even "every year" tasks, because you're just opening yourself up to problems.
This is just what you should be using them for. As you say, you can get them ratified, check into the source code revision system of your choice or whatever in order to have a repeatable set of operations on which you can rely. For rarely performed operations this is even more important than daily ones.
Effectively you are then doing software development, whether you're a tiny one-man operation or a huge multi-national, and the same standards as you'd expect a software developer to use should apply - testing, verification, dummy-runs, early bail-outs, stop on every error, etc.
Yes. Why would you fly by the seat of your pants doing operations manually when you have this option?
I would also suggest that the differences between scripting an operation and performing it manually is little different from performing it "manually" (on a computer) and actually doing the operations in person.
1. It can be reviewed by yourself and others. That way it can be checked for errors, including typos such as rm -rf ~fred /*
2. It's repeatable. If you have a saved script that was successfully yesterday you know it will perform exactly the same operations today and tomorrow which you might not do yourself if sitting there thinking "Now what did I do next?".
"That's no different to saying that thieves operate a better service than the original manufacturers."
The journals get their material written for free, edited for free and refereed for free. Then they sell it back to the sorts of people who wrote, edited and refereed it and, they hope, will write, edit and referee the next issue.
I'm finding it difficult to decide just where to place the idea of theft here, especially when I see JStor charging for access to stuff I wrote for a very cheaply produced and distributed publication.
"have shared storage"
Genuine question...what's that got to do with a router?
It's something a lot of routers offer these days - stick a USB socket on the side of the router and let the punters plug a thumb drive into it and it appears on the network. The good news is you don't have to use it.
"My Google Nexus 5X is pretty much everything. It''s my plane ticket, train ticket, bus ticket, tram ticket, taxi ride and method of paying for most transactions < £30 (and many other things)."
Looks on with sympathy - but not much.
"A voxel is a point on a 3D grid."
It's actually a small volume, not an actual point, just as a pixel is an area on your screen. https://en.wikipedia.org/wiki/Voxel
Hence the description: "a group of points within each voxel" (my emphasis).
OTOH what's a "trainable deep architecture"? It sounds like a ventilation shaft above a railway tunnel.
Biting the hand that feeds IT © 1998–2019