"So... I discover a TOTAL lack of authorisation and type-checking on the backend API methods?"
You raise a bug report and get it fixed instead of trying to hide the problems.
42665 publicly visible posts • joined 16 Jun 2014
"Sadly, that is one truth most *nix people still don't grep to this day."
I'd like to disagree with you on the basis that most Unix folk do grok it because historically Unix was developed by people who wanted to use it. But while the "still ...to this day" is the wrong way to look at it there are some damn peculiar un-Unixy people coming into Linux these days. Whilst I disagree with your historical perspective you have a point about the situation as it is now.
"I doubt that an ill-conceived feature exists in the kernel."
"If it DOES then Linus would swear at HIMSELF."
I wouldn't go quite as far as that.
Some Via processors allow processor throttling and some don't. Googling a log message from one that didn't all I found was a comment from Linus saying that the worst that could happen was that it would just write a message to the log. It did. About once a second.
"If it DOES then Linus would swear at HIMSELF."
I take it that his comment about "What moron let that in" was just that when it was discovered that an early file system was letting stuff sit in buffers for far too long without being flushed to disk when memory capacities increased.
"But then you hit Trolley Problem territory where you CAN'T have both, because of stuff like true zero-day vulnerabilities which are UNKNOWN bugs that are being ACTIVELY exploited."
I'm not sure how you drag the Trolley Problem into it and am utterly uninterested to find out because what you're banging on about isn't the subject of Linus's post and no amount of Bob capitals will change that. It doesn't concern bugs which are unknown.
It concerns bugs which are known because security researchers found them and submitted patches which attempt to treat the symptoms (by amputation, as it were) instead of either submitting a patch to fix the bug or raising a bug report for someone else to fix it. To the extent that it takes up time to fend them off these guys become part of the problem, not the solution.
BTW, if a bug is completely unknown it can't be actively exploited because nobody knows it to exploit it.
"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.
"Maybe we need to bypass BT completely next time regarding full fibre FTTP rollout"
You really think anyone else is going to find the finance a roll out a full FTTP network instead of just the areas where there are easy returns?
"These days, we should be plugging our telephone handsets into our routers."
And what does your router plug into? If you think you shouldn't pay for that connection back to the ISP get it discontinued and see how well your internet service works.
"We're well passed the point where we need to replace the USO for phone service with a USO for broadband that includes VoIP."
The USO, AIUI, requires the phone service to continue to operate in the event of power failure. POTS does this by being powered down the line by UPSs at the switch. Your router isn't going to be powered over fibre. Even if this is dropped you still need a connection back to your ISP. That needs to be paid for. If you're not to be billed direct your ISP will be billed instead and pass the cost on to you. Neither your telco nor your ISP are charities dedicated to supplying you with a free connection.
As a public sector entity they had an un or under-funded pension scheme, but that "didn't matter" because like all public sector pensions, the cost would be stiffed to future tax payers.
You are right to lay the blame for the pension black hole at govts. door but not at that particular door. At one stage the fund was deemed to be in surplus and HMRC - or probably IR back then - ordered BT to take a contribution holiday. Over funding is considered to be a form of tax evasion.
As all state pensions, including Civil Service pensions, are run as a Ponzi scheme the tax authorities don't really grok the extreme long term nature of pensions funds. The valuation of a pension fund is based on what it would cost to turn the liabilities into annuities and this is based on interest rates. Annuities are also based on life expectancies and increases in those need to be allowed for when looking to the long term.
What's not taken into consideration is that interest rates can go down as well as up. So when interest rates went down and stayed down as a result of a financial bubble, for which Treasury policy and their sometime political head Brown must accept some responsibility, the valuation on which the taxman's decision was based was shown to be wildly optimistic. Increased life expectancy has further hit annuity rates. In consequence BT is committed to making large contributions trying to catch up. It's not simply a matter of paying what it wasn't allowed to pay before because the fund has lost any stock market and income gains from the contributions that weren't made back then and that also has to be covered.
Another factor was the withdrawal of pension funds tax relief on dividends*, another of Brown's bright ideas. The dividends contribute to growth of the funds and this contribution was cut by removal of the tax relief. It clearly amounted to taxing the future and that future is here. It did a lot of damage to pension funds in general, not just BT's, and is one reason why there are few defined benefits schemes left.
As things stand the best we can hope for is that as interest rates rise the annuities will offer better prospects and the hole will be at least partly dealt with due to that.
* I thought then, and still think, that the pension funds were culpably supine back then. They had offered projections of future value based on the tax regime as it then was. When the regime altered they should have presented members with valuations which showed the difference between what was now projected and what would have been projected under the old legislation if only to cover their own backs and explain why things were looking less rosy. The fact that it might have put political pressure on Brown by exposing the long term consequences of his actions would, of course, have been a fortunate by-product. I notice reports suggesting that the recent budget has sneaked in another technical looking change that will affect some saving schemes in the long run. The Treasury got away with in 20 years ago, why would they not expect to succeed again?
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.
I and my small team had adjacent desks. The conversation between us was fairly continuous - there may have been complaints from surrounding teams. One year I got a bad report for not holding meetings with my team. This was written by my line manager who never held such meetings with me and countersigned by his manager who also never held such meetings with me. Do as I say!
"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' [1], 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.
"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.
"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.