Are you aware that you've been running a version that hasn't been getting updates since July of last year? If not, then having your OS actually get updates again might be a surprise. You'll have to update to 20.04 first, though, and then 20.10 before you can update that to 21.04. There's no direct update path (another known surprise, one might say). If you don't want to update every six months, just stick to the long-term support version (LTS, currently 20.04).
The bootloader was broken for this laptop model in 19.10 and I've been deferring going through the same pain upgrading to 20.04. Totally aware of the support situation and upgrade sequence, but an unsupported machine sure beats a bricked machine
Only every second xx.04, to the best of my knowledge. 20.04 was an LTS release, the next LTS will be 22.04. 21.04 is a standard release supported for 6 months.
Edit: Ninja'd by jpace121, should have refreshed before commenting.
I don't run Ubuntu. If I did, your question has convinced me I would be happiest on an LTS version. 5 years of not changing much is more in line with my level of interest in puttering around my OS settings than every 9 months.
The 19.10 bump was to get some fresh base libraries to build something as I recall. I think it might have for Remmina. Otherwise totally agree with you, LTS is always preferable
It would probably only take a handful of engineers to mount a solid DoS attack by requesting approval for every shell script they write, home Ubuntu ISO they install, or neighbour's printer they fix to get this policy a little more sensibly refined. In any case whoever wrote that e-mail to him is not someone I would possibly tolerate working for
This is not a DoS attack -- this is business as usual, in some environments. And the employees cannot proceed with releasing scripts, patches, or other software until they have approval (this is the case we're talking about, not "ISO installs" or "neighbor printer fix").
This sounds like a needlessly strict interpretation of GDPR. Taken from the UK regulator's site:
> The lawful bases for processing are set out in Article 6 of the UK GDPR. At least one of these must apply whenever you process personal data:
> (a) Consent: the individual has given clear consent for you to process their personal data for a specific purpose.
> (b) Contract: the processing is necessary for a contract you have with the individual, or because they have asked you to take specific steps before entering into a contract.
> (f) Legitimate interests: the processing is necessary for your legitimate interests or the legitimate interests of a third party, unless there is a good reason to protect the individual’s personal data which overrides those legitimate interests. (This cannot apply if you are a public authority processing data to perform your official tasks.)
...
> Legitimate interests is the most flexible lawful basis for processing, but you cannot assume it will always be the most appropriate. It is likely to be most appropriate where you use people’s data in ways they would reasonably expect and which have a minimal privacy impact, or where there is a compelling justification for the processing.
> The processing must be necessary. If you can reasonably achieve the same result in another less intrusive way, legitimate interests will not apply.
> You must include details of your legitimate interests in your privacy information.
I included the legitimate interests bits because they seem most relevant to testing, but even if testing is not considered "necessary" in a particular use case, there still remain at least two more criteria that might satisfy the use of live data in testing, including explicit user consent. Much of the focus of GDPR is on privacy-invasive intrusive processing and prevention of harm, I think a lot of fuss around it can be dispelled when viewed from this angle.
I admit that using real person-related data in a test database for ordinary software development (not considering fixing a production system here) might be legitimate according GDPR based on contract and consent. But the hurds are so high that I cannot think of any realistic use case that involves more than a couple of people at the maximum. Contract and consent are subject to specific requirements here. The constent must typically be voluntarily, i.e. without any pressure or coercion, it must not be coupled to another condition and it must be given for each specific purpose indivdually. And I doubt that it is permitted to completely exlude the principle of "privacy by design" in a contract. And even if this were the case, you need this consent from each customer whose data is in the database, while you must not make your service to the customer dependant on his consent.
As to legitimate interest, Recital 47 of GDPR states: "The legitimate interests of a controller, including those of a controller to which the personal data may be disclosed, or of a third party, may provide a legal basis for processing, provided that the interests or the fundamental rights and freedoms of the data subject are not overriding, taking into consideration the reasonable expectations of data subjects based on their relationship with the controller. Such legitimate interest could exist for example where there is a relevant and appropriate relationship between the data subject and the controller in situations such as where the data subject is a client or in the service of the controller. At any rate the existence of a legitimate interest would need careful assessment including whether a data subject can reasonably expect at the time and in the context of the collection of the personal data that processing for that purpose may take place. The interests and fundamental rights of the data subject could in particular override the interest of the data controller where personal data are processed in circumstances where data subjects do not reasonably expect further processing."[1]
Typically one does not have a contract about software development with a customer whose personal data is stored in a database, but about a specific service, such as for example selling something to him via a Web-shop. So if Uncle Joe is buying something from the Web-shop, can he reasonably expect that his personal data is used in developing the Web-shop software? Most likely not. Ergo, there is no legitimate interest to use his data for that pupose.
The biggest difficulty I've experienced is "librification", where some common code ends up in a little library, and soon that library is not so little any more, and not long after starts to look like half of every service. I can maintain discipline when working on small systems alone, but on a team there will always be one lazy person or urgent need which means eventually some shared component gains enough gravity to start sucking code out of their nice isolated homes
Giving up and dumping everything into a monorepo, that's not going to help at all. At that point probably better off just giving up any hope of carefully split up and individually managed services
These libraries already exist whether you write them or you use someone else's. In our case most of our micro services are node.js based so Koa is in every microservice and we use middleware for authentication -- and thus if the authentication system evolves (moving to JWT or a microservice gateway) we have to evolve that middleware everywhere.
Same with our consistent logging system.
Libraries are better than unique code everywhere for the same task - allows you to fix a bug once and to do consistency checking.
The problem isn't "some code which different services use is in a library".
The problem is an not-ideal "the code which is in libraries shared by different services is tightly-coupled to particular services". e.g. changing the shared library might break some service which depends on it.
Obviously, you don't want code like that. But it's easy to write code which is slightly coupled; and then when you're in a hurry, to increase the coupling.
I don't get the first paragraph you are saying. This lazy person puts some random code into a shared component, or... ?
Wouldn't this urgent need mean that they put this code into the microservice that needs this urgent update as opposed to going through the effort to make it available for everyone to use?
I dislike RMS' opinions, therefore.. the GPL is dead? A little bit of a leap there buddy.
Cloud providers profiting from free software is an important issue, but it is largely orthogonal to the continuing need to protect free works in numerous traditional use cases
> Is there any technical reason why it is not supported?
No familiarity with these devices, but there is at least a slim chance if it was an embedded device, they needed the flash or RAM for something else. Seen this happen elsewhere before
