Posts by thames

Re: Isolate

Actually, all of the products listed are just managed Ethernet switches. The main reason that people buy stuff like this is that the mounting method and package profiles fit with other industrial hardware and the operating voltage is compatible with standard industrial voltages.

The specifications include a long alphabet soup list of standards and management protocols which most users probably don't understand. Most users probably just plug them in and if they work out of the box they don't bother configuring them.

I can't imagine a valid reason for connecting the management interface to the Internet for most applications these switches would be used in. If it is, then you probably already have much bigger problems than the software bugs in question.

Personally I am of the opinion that adding security features and protocols to most industrial hardware is a waste of time, and is even counter productive in most cases as it creates the illusion of security. Industrial control companies are never going to be security experts and industrial control system designers are never going to be IT security specialists. You are probably better off relying upon isolating networks and if you need connections outside the machine boundaries to add IT industry standard hardware which has been configured by someone who does that sort of thing for a living.

Re: So where would they move it to?

Some traditionally US conferences have been talking about moving to Vancouver specifically because of visa issues. You might want to add Singapore to your list of desirable locations as well.

I also wouldn't rule out London just on the basis of Brexit. That issue might be all consuming so far as people in the UK are concerned, but most of the rest of the world really couldn't care less about it unless they are running a business who are directly affected. Conference goers are more concerned about the availability of direct flights, hotel rooms, decent restaurants, low crime, and good conference venues.

Pretty much any potential location will have some drawbacks, and no destination will be completely free of visa problems for at least some attendees. It's all relative though, and at present holding international conferences in the US is becoming difficult enough that more than a few organizers are seriously looking for alternatives.

We know for a fact that the US is doing everything they claim that Huawei might be doing. The NSA monitors communications on a mass scale. The US routinely hacks into the communications infrastructure of Europe to spy on senior European politicians. The US NSA has direct access to major data links which connect data centres in the US, giving them access to unencrypted data stored there, and they do take advantage of it. US networking hardware gets equipped with backdoors in a targetted fashion. Under US law, American companies must hand over any data they have access to to the US security services on demand, and they can be imprisoned if they tell anyone about it. This has all been in the news over the past few years and so isn't in dispute.

Should the rest of the world therefore ban all US networking equipment and US companies from anything related to communications or critical IT systems? I mean if you are going to be consistent, then that is pretty much where your argument leads.

Meanwhile the US has declared Canada to be a "national security threat" because Canadian steel and aluminium might do something bad to the US. They also say that Germany is a "national security threat" because German cars might suddenly start goose stepping down American streets when Angela Merkel presses a button on her desk.

And now the US president has recently announced that he wants US industry to lead the world in 5G technology. I think it's pretty clear how the US determines what constitutes a "national security threat". It's called mercantilism, and it dominates US policy making these days.

Most of the rest of the world seems to be saying "thanks but no thanks", as they don't see any reason for making themselves poorer in order to bail out American companies who have fallen behind in the technology race.

If there is a genuine argument to be made for security in telecommunications hardware, then it is an argument which says that each country should only being installing kit made within their own borders by companies controlled by their own citizens and monitored closely by their own security services acting under the control of their own parliaments. Perhaps that doesn't sound like the best of ideas, but it's exactly where this anti-Huawei argument leads for those willing to be honest and consistent about it.

Re: Its's just .....

I'm not sure what article you are responding to, but this one is about Canonical announcing their support for the industry standard, which is Containerd.

As for Mir and Unity, neither of these are in their current LTS release as standard features.

Re: Stalling?

I think it has to do with they want to stall 5G adoption until they figure out how to get American companies at the heart of 5G standards.

I believe that I read a while ago that royalties on standards patents accounted for roughly 40% of the cost of a DVD player, while the companies that actually manufactured them made razor-thin margins. Most of those standards were owned by American or Japanese companies.

If IoT and 5G really lives up to their billing, then the big money from 5G is going to be made by the companies who will collect royalties on the standards for everything which incorporates them, which means nearly everything made for any purpose (look at the latest overpriced crap from Nike to see IoT shoes for example). The American government will see it as their duty to ensure that it is American companies collecting that economic rent on nearly everything made and sold. They have said repeatedly and clearly that they want the US to be the global "leaders" in all things.

Keep in mind that this is the same American government who claim that the Canadian and European steel and aluminium industries are a threat to national security and imposed massive import tariffs on them, and are preparing to do the same with automobiles.

If there were genuinely some serious threat posed by Huawei equipment, then I would imagine that we would be seeing some actual evidence for it by now. There are enough independent security researchers out there that could have found something if there were even a hint of something to find that was at all credible.

If the American government have some clear evidence, then let's see it. Just saying "trust me" isn't going to convince many people outside of the US about "national security threats" whether we're talking about bars of aluminium, cars, or 5G equipment. The American record so far doesn't exactly inspire trust.

Re: Too simplistic

Much of what determines what a programming language is selected for an application has to do with economics, and that in turn has to do with how it is being deployed and managed as well as what libraries are available to implement it.

I've just had a glance at the report, and while I have not read the whole thing, it's pretty clear the authors have pointed out some gaping holes in the original study. One obvious problem is that actual programming languages don't fit into the neat pigeon holes that the original study assumed. For example, functional languages may have procedural features and visa-versa, so users will commonly combine the two methods in the same project, making any conclusions based on a neat separation of the methodologies void. There are more examples, including the fact that large chunks of data the original study was based on was nowhere to be found.

The studies themselves were based on comparing the number of bug fix Github commits to the number of total commits. In other words, what proportion of commits were bug fixes. A "bug" was determined by scanning for the words "bug", "error", etc. in the commit message.

One pretty obvious problem that neither of the authors appear to have addressed is the relative maturity of projects compared to languages. Projects that have been around for a long time and are relatively stable are likely to be written in languages that have been popular for a long time, and it is possible to hypothesise that commits are more likely to be focused on bug and security fixes rather than new features. On the other hand, projects that are more recent have a greater probability of being written in languages that have become popular only more recently, and to be in a phase in which they are receiving more feature commits rather than bug or security commits. And if we examine how the languages cluster in the study, they seem to fit that pattern. Of course correlation doesn't equate to causation (as the second study points out), but it is yet another possible explanation which should be considered.

And as the study itself points out, there are many "bug" commits which are just fixing cosmetic, style, or comment issues rather than fixing actual functional bugs. The methodology is not able to distinguish these despite some "communities" being more obsessed about these issues than others.

What is noticeable is that most of the well established and popular programming languages appear to cluster pretty closely together while the "boutique" languages are in another cluster. It is not obvious to me how this could be explained simply by language feature rather than being a reflection of who is using them and how.

There are two interesting outliers however, these are C and Perl. C supposedly has an abnormally high number of bugs, while Perl has an abnormally low number of bugs (see figure 5). If we want to make any language superiority claims based on the study, then evidently if we want bug free software we should be writing it all in Perl. Or perhaps it's all just bollocks after all.

Re: "Trusty command interpreter"?

Ubuntu works the same as Debian, as Ubuntu is a close derivative of Debian. There are two shells, the interactive shell and the non-interactive shell. If you simply open a terminal to type commands in you get the interactive shell, which is Bash. If you run a script with #!/bin/sh, then you get Dash. If you want your script to run with Bash, then you need to specify #!/bin/bash.

Bash has features which make it easier to use interactively as well as more advanced syntax with which to write complex scripts. On the other hand, since Dash lacks those features the executable is smaller and so it starts up faster, which is useful if you are running lots of small simple scripts (like in the pre-Systemd init system when this combo originated).

The main thing you have to look out for is when you specify #!/bin/sh in a script but then try to use advanced Bash features and get very unhelpful Dash error messages. This is not that uncommon if you google for scripting examples since so many people just assume that everyone uses Bash. If you are using a Debian derivative and get baffling syntax error messages in a third party script, it's worth a try to change the #! to specify Bash to see if that helps.

Generally, I prefer working in Bash because the more user friendly syntax for advanced features means that I am less likely to make errors which have to be debugged. For really basic scripts however it doesn't make much difference.

Re: My take?

There seems to be a general rule of thumb that when US intelligence departments leak alarming stories via compliant press contacts, it's usually the case that the US is already doing this themselves and are sweating buckets over the thought that someone else might be doing it as well. We saw exactly this in the run-up to the Stuxnet reveal, and we saw exactly this in the backdoors being installed in Cisco networking equipment.

I remember the same sort of vague but alarming stories claiming that foreign powers were infiltrating SCADA systems and could use that do destroy utility equipment. They even built a lab type setup of a diesel generator with attacked SCADA system and demonstrated it. Meanwhile the utility industry scratched their heads in puzzlement, because despite the alarm and panic in government, industry couldn't pry any actual details out of them so they could take preventive action and nobody was seeing it in the wild. And then the Stuxnet story came out and we found out the panic was about how the US (with the assistance of Israel) had infiltrated the SCADA systems controlling Iranian enrichment equipment and was using it to conduct sabotage and the US were afraid they would be hacked back.

To go back to the mysterious motherboard chips, if this was real, I would expect someone to present actual hacked hardware along with demonstrations of what it did. After all, if the story were real then it's not like Chinese wouldn't already know everything about it, so what's the point of hiding it?

And Amazon's and especially Apple's denials are pretty strong. If they were obfuscating the issue, then they would just release their usual vague waffle.

I suspect this story is complete bullshit. The use of a security company in Ontario Canada is also very interesting. At this very moment the US is putting lots of pressure on Canada to try to get them to ban Huawei equipment from important Canadian networks. It would not be surprising if this whole story were to be an exercise intended to pressure allies into stepping into line behind the US in freezing Chinese tech companies out of western markets in favour of equipment that has the backdoors of "friendly" countries in it.

Or Amazon. One of the major cloud providers likely will, in order to provide a seamless path from development to deployment and so increase sales to their cloud.

They don't need to make GetLab exclusive to their cloud in order to do that. They just need to be able to direct development to ensure that it supports all features of their cloud and that any operating assumptions built into GitLab mirror the ones in their cloud architecture.

Re: Wait and see

Redis Labs are going to what is called an "Open Core" model. This is where the main software project is open source (in this case Redis itself), but add-on modules are proprietary (adding the Commons Clause to Apache is equivalent to). If you don't use the add-on modules then it doesn't really affect you.

A number of other companies do this, Oracle MySQL is perhaps the best known. There aren't however many well known examples because there simply aren't that many successful examples of Open Core as a business model. It really only seems to work in cases where the main software system has a very narrow and specialised market where there is direct contact between the software creator and the customer, and there aren't many third parties interested in creating add-ons. Perhaps the most successful "open core" example is Google Android where the base OS is open source but Google Play Services is proprietary. There aren't a lot of other successful large examples however.

I'm not sure this is really such a big change to what Redis was already doing however. The reason that most companies use an AGPL license rather than a standard GPL license is so they can charge customers a fee for selling them a non-AGPL version (unlike standard GPL, AGPL is less convenient to use on proprietary web services).

In the case of Redis, the base database was and remains BSD. Some of the add-on modules doing things like full text search however are changing from AGPL to Apache + Commons Clause. The latter apparently achieves the same intent (from Redis Labs's perspective) as the former when used in "cloud" operations as opposed to enterprise data centres which were Redis Labs' traditional market for add-on products.

Redis Labs' main problem is that their core customer base of business enterprises is to a large extent moving from their own data centres to cloud operations. Since the cloud vendors are increasingly providing the core software infrastructure as well as the hardware to run it on that removes a lot of their traditional customer base contact, and the ability to charge support fees along with it.

This follows general long term industry trends as lower layers of the stack, from hardware to operating system to databases, increasingly become commodities. Profitability increasingly comes from more specialised software higher up the stack which has not yet become a commodity, or from services which are inherently more difficult to commoditise due to economies of scale.

Older vendors selling legacy software or software/hardware combinations with a great deal of customer lock-in such as Oracle databases or Microsoft Windows or IBM mainframes are another profitable business model. However, all of these examples face eroding revenues as new development goes elsewhere and existing customers gradually drop away through natural attrition.

Re: At what cost?

From what I can tell it's just something to let the kernel know that it is running in a VM and to use the VM's direct interfaces for storage and networking rather than using emulated interfaces. This is something that Linux versions optimised for VMs have been doing for years.

Generally, when you are running a generic kernel on a VM you lose some I/O capacity if you are talking to it as if it were emulated hardware. Most VM makers offer a way around that so that the I/O systems can talk directly to the VM bypassing the emulation features.

About size months ago Microsoft started offering a version of MS Azure with hardware accelerators for I/O (google "TCP offload engine" for examples). Such things have been available for years in things like NIC interfaces if you run directly on your own server hardware instead of using "cloud" versions.

"Cloud" versions of course require additional support from the VM so that different cloud instances can share the hardware without stepping on each others toes. The new Suse version just has added modules to use the interfaces in Azure for this.

I'm not sure what is really new in this announcement, since according to Microsoft the previous version of Suse had this, as well as Red Hat, CENTOS, and Ubuntu. It might be just that there was a delay in support for this feature in the new version of Suse that came out recently but now it's there for people looking to upgrade their version of Suse.

Re: Why?

@Anonymous Coward said: "I had a ran a Linux VM that was optimised to be a VPN server (...) These days, you'd be lucky to get away with a 4GB USB stick."

Let's see how that compares to the actual size of a popular Linux ISO.

Ubuntu desktop: size is 1,953,349,632 bytes. That includes a full GUI (Unity), office suite (LibreOffice), web browser (Firefox), email client (Thunderbird) and all sorts of media players and other odds and ends. If you just want the desktop with web browser, pick minimal install and the other stuff will get left out.

Ubuntu server: is 845,152,256 bytes. That is just over a fifth of the size of the desktop ISO.

For Debian I just have the server net install, but the installed size won't be much different than the above.

FreeBSD (not Linux, but we'll list it anyway) is 2,930,397,184

OpenSuse is 3,917,479,936 bytes, although you don't have to install everything it includes.

Those are the ones I happen to have sitting around. The Ubuntu desktop will boot directly from the ISO so you can try it out without installing it.

If you want to know the install size, then as an example a Debian 9 64 bit server has a Virtual Box VDi size of 1.7 GB. However, that includes a C compiler and a bunch of other extraneous stuff that I use for testing software, so you can probably cut that down somewhat.

Meltdown seems to be Intel specific, while Spectre is a more general problem relating to speculative execution.

For ARM, it will depend on the specific model. Some ARM chips are affected and some are not. There is a list somewhere of what models are affected.

For example, the Raspberry Pi Foundation have said that all models of Raspberry Pi are immune to both Meltdown and Spectre due to the model of CPU they use.

Generally, some of the top end ARM models are affected by Spectre, while the rest are not. What this has generally meant in practice is that the most expensive premium model mobile phones have a potential problem while the medium to low priced Android phones are largely immune. The bulk of embedded applications using ARM are also probably immune.

Re: about bl**dy time

If I recall correctly, AppEngine was stuck on using an old version of Python because they had taken a snapshot of Python and heavily hacked the source code to introduce language run-time level checks and limits on what a user program could do in order to add sandbox style isolation without using VMs.

It sounded clever, but it had several major drawbacks. The obvious one was that they were stuck on one increasingly old and obsolete version of Python while the rest of the world moved on. Another was that they could only support a subset of the Python standard library and no user C modules.

The Java version they supported also had comparable limits, but I don't know the details of that.

"GVisor" replaces the need for a custom version of Python so they can now support up to date versions without having to hack the language run-time.

Most major Python projects such as Django, SciPy, and others have either already dropped or are in the process of phasing out support for Python 2.x, and many newer libraries have never bothered supporting 2.x in the first place.

While you may not want to try running something like Django on App Engine (I don't know if it is even possible), App Engine's lack of support for modern versions of Python was leaving it increasingly isolated in terms of third party library support. Since Google was running their own version of Python, the end of life date for mainstream Python wouldn't have affected them. However, lack of third party libraries, lack of new educational material, and just generally being out of the development mainstream would. This I think was the motivation for replacing their original solution with gVisor.

And the overall motivation for the update I think is that Google are now putting more emphasis on App Engine due to the current trendiness of "serverless", the latter of which was the basic idea behind App Engine to begin with.

The usual pattern for this sort of thing is that it starts when the US do this to someone else. The US counter-intelligence department then find out what their colleges on the floor above have been up to and crap their pants over the thought that someone might do the same to them. They then stage a series of leaks into the press that someone else has been doing it to them in an effort to whip up enough publicity to spur the industry into taking some preventive measures.

Prior to the news of what the Americans did to Iran with Stuxnet, there was a long series of "confidential intelligence briefings" to selected newspapers and politicians about how US utilities may be vulnerable to being hacked. A demonstration using a specially set up diesel generator (simulating a power plant) was conducted which was supposed to show how SCADA systems could be infiltrated.

The utility industry just shrugged it off, as they weren't seeing any of this in practice. And then Stuxnet hit the news and we saw that it had done exactly the sort of SCADA infiltration that the Americans had claimed was the threat to US utilities.

And then there was the big campaign using the same PR techniques over how Chinese IT gear might have back doors in it. Nobody could find these back doors, but we were assured they might be there and it was a huge national security risk. And then it turned out that the American NSA was putting back doors in Cisco kit.

I could go on with more examples, but the pattern follows a well-worn groove by now. The US hacks someone else, they crap themselves over the thought that someone might do the same to them, they start a propaganda campaign via the channel of suitably compliant major news media to whom they give an "exclusive" in return for not asking the wrong sort of questions, and industry is left to wonder "WTF?" because the story is full of holes due to so many details being held back because of course the US doesn't want the target they had actually hacked to find out what had been done.

To address the story in particular, very likely the "air gapped" systems aren't actually air gapped. The utility has an "air gap" policy, but an exception was made for remote vendor support. The vendor isn't air gapped because they're too small to have a dedicated IT security team who could plan such a thing. And true "air gapping" probably isn't practical to begin with because the vendors are software developers who need to get software updates from Microsoft and their PCs need to connect to the Internet on a regular basis to validate software licenses, etc., etc.

And if software updates from the vendors to the utilities aren't conducted on a timely basis, ordinary bugs can crash the electric network just as surely as malicious action could.

Genuine security is probably possible, but it would require a complete overhaul of the industry and the relationships with vendors and the software development environments they use, and that simply isn't going to happen any time soon.

Re: pickle

@stephanh said: "What do you consider a known vulnerability?"

A known vulnerability is something that is supposed to be secure against attack but isn't. Pickle wouldn't count as a vulnerability, because you are essentially just serializing and unserializing executable object code and data. This is something you do between different parts of your own application, not with data from outside. The docs as you said, make this clear. If your application un-pickles data from untrusted sources, the mistake is yours since you were explicitly told not to do that.

For untrusted data you would use something like JSON. If there were a bug in the JSON decoder which allowed someone to execute arbitrary code, then that would be a vulnerability.

Most programming language libraries have something to let you execute OS shell commands. That is potentially dangerous if you were to write your application such that anyone could execute arbitrary shell commands via the web interface. However, that wouldn't be a programming language vulnerability, that would a vulnerability in your program since you should not provide a feature that does this.

Something is a vulnerability when it can do something dangerous that wasn't in the documentation.

Re: Reinventing a more limited wheel

@rgmiller1974 said: "I'm curious about the example thames posted. Is ... really any slower than ..."

The interpreter doesn't cache the results of f(x), and I doubt it would be feasible to determine if it could do so in all cases. Static analysis couldn't determine that since function "f" could be written in another language (e.g. 'C') for which you might not even have the source code and dynamic analysis would run into similar problems.

The new syntax achieves the same result under the control of the programmer as well as being useful in other applications. Plus, you can see what is going on without having to analyse the behaviour of f.

Re: Contradictory

They can replace the built-in encryption accelerators and random number generators with their own. The way the US has been putting back doors into systems is to get people who work for them (either openly or clandestinely) on industry standards boards and get subtle weaknesses introduced into the standards. They also bribed American companies to implement these backdoored standards and then certified them as "secure" in order to get them adopted in the market.

These weaknesses make encryption easier to crack. You couldn't prove the standards had a back door unless you knew what the back door was, and independent cryptographers who thought things looked more then a bit fishy were dismissed as tin foil hat wearers. Then it all came out in a set of leaks a few years ago.

How that relates to CPUs is, how do you know that the encryption acceleration or random number generator built into an Intel CPU doesn't have a similar US government backdoor built into it? You don't, which is why Linux kernel devs don't trust the built-in random number generator for use in encryption. They only use it as one of a number of different sources of randomness specifically because of the threat of US back doors.

So, the Chinese can replace the encryption accelerators and random number generators in AMD CPUs with their own. They may possibly Chinese back doors instead of American back doors, but at least they know the US government won't be reading all their encrypted messages. That isn't an assurance that the rest of the world doesn't have.

Oh, and if the Americans have back doors in Intel CPUs, then the Russians and a number of other countries probably have managed to get themselves a copy of the same keys as well, one way or another.

Yes, Boeing had been talking with both Embraer and Bombardier about some sort of acquisition or merger. Talks with Bombardier fell apart, and Boeing already had a partnership with Embraer to sell and service their military transport jets (same market segment as the Hercules). A straight out purchase of Embraer was not in the cards though because of political opposition to it in Brazil.

There is widespread speculation that Boeing's plan was to get the US government to give them a monopoly on the US market for this size of jet to sweeten the deal enough to bring Embraer back to the table.

The Canadian government then played matchmaker to get Bombardier and Airbus back to the negotiating table and a deal was made (and is now in effect). The UK government got involved as well as large parts of the CSeries are to be made in the UK. PM May held high level meetings in Ottawa about strategy and then did some high level lobbying in Washington to try to get Boeing's tariff plan killed.

There is also an upcoming major arms deal in Canada where Airbus are now in an improved position for their Typhoon due to Bombardier's local industry links. Boeing meanwhile, who once were seen as having the deal in the bag, have been told their bid will have big negative ratings all over it due to being seen as not being very friendly to Canadian interests (a criteria for this was actually added to the formal bid process because of these events).

Overall, while Boeing may have possibly have now got their partnership with Embraer, they screwed up badly overall.

Re: I have a better remedy...

Changing the license to BSD would do absolutely nothing to resolve the questions being addressed here because the BSD license does not even attempt to address the issue of what happens if you were found to be exceeding the terms of the license.

The question of "cure" is with respect to what does someone have to do to get themselves into the clear if they were caught violating copyright law with respect to a published work. GPLv2 as it stands does not address this. BSD also does not address this.

GPLv3 however lays it all out clearly that you if you bring yourself into compliance with the license then "forgiveness" (in the legal sense) is automatically instated. Under copyright law, formal "forgiveness" is required in order for copyright infringement complaint to be considered closed. The measure being adopted by Red Hat tacks that aspect of GPLv3 onto the side of GPLv2 without changing the license itself.

When you "violate copyright" you are violating copyright law. The license is your defence as a user against being sued by the copyright holders. A license that is more explicit in this respect is to the user's advantage. A license which does not address this issue leaves it up to the courts and the lawyers to argue it out.

Re: puts a dampener on rival GitLab’s claim?

This is what I'm doing. Within the next couple of weeks I will be setting up an account at GitLab, but will still keep the GitHub repo. The project will simply be hosted in two places. If that works out well, then I may look for a third location as well. I will want to automate this with proper scripting first however so I don't have to do it manually.

My plan isn't to simply switch hosting providers. I did that once before when I moved from SourceForge to GitHub. What I intend to do is to have multiple mirrors where the project is hosted so that the loss of any one of them is not a major setback. There is no point in trying to do that after you have been presented with the choice of either accepting new terms of service or being locked out of your one and only account.

So I will be moving to GitLab, but I will still be at GitHub for now as well. This is what I would expect other people who are concerned about this to do as well.

The only question really is which one becomes the primary repo and which one becomes the secondary mirror. A lot of GitHub's value is in the "community" aspect of having the largest number of developers already active there. If the community becomes more dispersed then a lot of that value will fade away.

Re: Shite

@J. R. Hartley said: "Wonder which new and exciting way they're gonna fuck it up."

They'll integrate it with Linkdin, Skype, Azure and MS developer tools.

Their press release said: "... bring Microsoft’s developer tools and services to new audiences."

Expect to see Github features appearing which hook your code repos directly into MS Azure for deployment. Your Github rankings will be reflected in your Linkdin profile. If you don't have a Linkdin profile, one will be automatically created for you based on your Github data. Skype will be integrated into team meetings for projects. MS Visual Studio will have deep integration into GitHub beyond just being a Git client.

So, you'll still be able to use Github via the web interface and via the command line Git client, but every possible Microsoft service that can be integrated into Github will be to the degree that a software developer could work through the life of an entire project without ever leaving the Microsoft walled garden.

Microsoft just paid a staggering amount for Github (three times as much as press analysts were speculating) and they will be looking for ways to make that back. Introducing a variety of forms of vendor lock-in in order to sell other goods and services is the obvious choice here.

I'm looking into what is involved in setting up a Gitlab account. I won't pull my open source projects from Github, but I won't use it as the sole public repo any more. Just like a lot of Youtubers have come to the realisation that they need to diversify their options rather than being at the mercy of Youtube's latest policies, I'm going to make sure that I can pull the plug on Github at any time if necessary just like I did with Sourceforge.

P.S. Don't be surprised if Amazon come out with some sort of response to this.

@AC said: "As a random example, lets say you're a manufactuer that has a line of custom Linux laptops. Want really good support added to them for nearly no cost? Well then, send in ten or twenty thousand entries for your stuff, randomising things to look legit and using fake source IP info."

Or just send an email to Canonical telling them that you are are a manufacturer who is planning on coming out with a line of custom Linux laptops and that you would like them to work with Ubuntu out of the box on launch. Then ask them if their developers would like some free laptops. They're happy to work with anyone who wants to support Linux.

However, just have a look at the type of information being collected. According to the story it just amounts to the following:

• Ubuntu Version.
• BIOS version.
• CPU.
• GPU.
• Amount of RAM.
• Partitions (I assume that is number and size of disk partitions).
• Screen resolution and frequency, and number of screens.
• Whether you auto log in.
• Whether you use live kernel patching.
• Type of desktop (e.g. Gnome, Mate, etc.).
• Whether you use X11 or Weyland.
• Timezone.
• Type of install media.
• Whether you automatically downloaded updates after installation.
• Language.
• Whether you used the minimal install.
• Whether you used any proprietary add-ons.

There is basically two types of information there. One is some basic parameters such as RAM, CPU, GPU, hard drive size, etc. That tells you what you should be targeting in terms of hardware resources, and so whether your desktop (e.g. Gnome) is getting too fat for the average user (as opposed to the average complainer, at which point you are far too late to be addressing the issue).

The other is what install options people changed compared to the default install. If most people don't pick live kernel patching, then you know not to make that option the default. If a lot of people are selecting Urdu as the language, then you might want to make sure that language has better default support. Etc.

Ubuntu will publish this information publicly. Personally I am looking forward to the RAM and CPU type data, as that will give me information on what CPU features to target in certain software I have been working on. I have been relying on Steam data, but that may not be very representative of the science and engineering field which my software relates to.

The article seems to be mainly buzzword bingo.

* unpatched Apache Struts.

* Heartbleed

* GDPR

* IOT securtiy

None of these have anything to do with license terms. They can be related to keeping your systems patched and up to date.

However, the real issue in that case is whether you are talking about vendor support of software you have bought, or whether you are talking about supporting software you have developed in-house (or via a contractor).

In the case of vendor support, the license is irrelevant to this issue. The real issue would be the quality of service provided by that vendor. Whether that vendor is Red Hat or Microsoft, the issue is the same.

In the case of self-support of something you developed yourself (or paid a contractor to develop for you), then you need to handle this aspect yourself.

In the general case of security patches for open source libraries and components though, if all of that came from the standard repos of a Linux distro then the distro manages all of this for you. They have security teams and their distro comes with an updating system that manages security patches. They can't make you apply those patches though, that is up to you being willing to do so and having the procedures in place which prevent the issues from being ignored.

This though is really just another variation on the vendor support question, with the license being irrelevant except that you now have a variety of competing vendors all supporting very similar systems to choose from.

Re: Got to give this punk some credit.

AZump said: "never saw a Linux distribution swap before Ubuntu, let alone suck up memory like Windows"

I'm more than a little sceptical about that claim. I'm writing this on an Ubuntu 16.04 desktop that has been been doing software development and web browsing all day long. Amount of swap being used - zero. That is typical for a system that I use on a daily basis, and I see the amount of usage on a regular basis as it is displayed incidentally to certain tests I run as part of software development.

About the only thing that pushes it into using swap is heavy memory usage from applications that are allocating a large proportion of available memory (e.g. very large arrays in the software I am working on). And that is exactly what happens in every other modern operating system since that is why swap exists in the first place.

If you want to make comments like that, I would suggest doing it on a non-IT related web site where you are less likely to run into people who actually use this stuff on a daily basis.

I have an AMD APU in the PC I am typing this on (CPU and GPU in one chip package). Before that I had always used NVidia graphics cards.

For my next PC I would definitely choose an AMD APU again. I have had zero problems with it in several years of use. It's fast, glitch-free, and reliable, as are the open-source drivers used with it by default (I'm using Ubuntu).

In contrast I always had some problems with NVidia graphics cards used with multiple Linux distros, especially when using the proprietary drivers.

Considering the AMP APU comes with CPU and GPU in the same chip package for considerably less money than I would have paid for a comparable CPU plus separate graphics card, it is pretty difficult to justify anything else for typical desktop applications.

I don't play video games so I can't speak to that field of use. I use mine for software development, full screen video playback, and web browsing. I have no complaints whatsoever about AMD APUs in my applications.

Re: New Linux poweruser here ...

I started trying to write a short summary of all the different issues, but realised there's really no way to cover even a fraction of them.

The short answer is that the basic idea is good, as it is more or less a clone of the init systems used by Solaris and Apple.

However, the implementation was sadly lacking, mainly because of what the Systemd developers were like. The Systemd developers didn't know how much they didn't know about all the obscure edge cases which exist in server applications, and wouldn't listen to the people who did know. When they made mistakes, they blamed other projects for having "bad" software, because well, Systemd is perfect so obviously the problem couldn't be there.

They also insisted that everyone else had to rewrite their own software to work "properly" with Systemd (mainly to do with network socket initiation on start up). The fact that this then made server applications incompatible with BSD and others without a lot of if-defs didn't go over well with the maintainers who were affected or with BSD people (the Systemd developers had no interest in working with the latter on these issues).

Debian had to ditch their project for a BSD based Debian distro version because they didn't have the resources to support two init systems (and all the resulting Debian specific init scripts) and the Systemd developers as mentioned above had no interest in working with the BSD people on this.

And since we are talking about Ubuntu in this story, I should also mention that the Systemd developers screamed much abuse at Ubuntu for not volunteering to be the guinea pig for the first commercial distro release of Systemd (no other commercial distro was using it at the time either). Ubuntu was bad, bad, bad, they insisted. The fact that Red Hat wasn't shipping it either at the time seemed to go right over the heads of the Systemd developers, the leaders of whom just happened to be Red Hat employees.

As for why Systemd got adopted by most distros is simple. It was backed by Red Hat and they have enough muscle in the Linux market to push through things they want. The same is true for Gnome 3 by the way.

If you are using a desktop distro that uses Systemd, or you are using bog standard server applications (e.g. LAMP, mail, SSH, standard database, etc.) then all of this probably doesn't make much difference. Your distro will have figured out the problems and fixed them. The distro that I'm using on my desktop to write this adopted Systemd a few years ago, and I didn't really notice any difference other than boot up taking longer (Systemd has the slowest boot times of any init system that I've measured).

If you are administering a complex server system, especially if you are using proprietary software that isn't packaged properly, then you have to deal with all the Systemd issues yourself instead of just hacking on an init script or installing a third party logging system. A lot of the complaints about it come from people who have to deal with this aspect of it.