Ubuntu Pro(ubuntu.com)
ubuntu.com
Ubuntu Pro
https://ubuntu.com/pro
8 comments
Shots directly fired at Rehat. If you're not in the "world" of Linux distributions this is a genuinely impressive commitment that, if they pull it off, makes Ubuntu Pro the most set and forget distro.
Not very open though.
Livepatch is closed, unlike kpatch.
And probably they are going to be using some kind of snap packages somewhere.
Which are annoying to deal with and centralized.
However since many of the things they support are using a GPL license, then its a matter of time until we get a Ubuntu Pro clone.
Also its free for 5 Devices, RHEL is free for 16 but you need to renew every year manually, which is really annoying, looks like Ubuntu Pro doesn't require to do such a thing.
I like the RHEL philosophy in software more, as they tend to make everything open, unlike canonical which is currently pushing a centralized package format and has a history of trying to do things their own way.
This is coming from someone who is using Debian everywhere.
Livepatch is closed, unlike kpatch.
And probably they are going to be using some kind of snap packages somewhere.
Which are annoying to deal with and centralized.
However since many of the things they support are using a GPL license, then its a matter of time until we get a Ubuntu Pro clone.
Also its free for 5 Devices, RHEL is free for 16 but you need to renew every year manually, which is really annoying, looks like Ubuntu Pro doesn't require to do such a thing.
I like the RHEL philosophy in software more, as they tend to make everything open, unlike canonical which is currently pushing a centralized package format and has a history of trying to do things their own way.
This is coming from someone who is using Debian everywhere.
> Livepatch is closed, unlike kpatch.
It's the same. For example https://ubuntu.com/security/livepatch/docs/faq links to https://github.com/torvalds/linux/blob/master/Documentation/....
It's the same. For example https://ubuntu.com/security/livepatch/docs/faq links to https://github.com/torvalds/linux/blob/master/Documentation/....
All of the Linux live patching efforts are paid services. I think Gentoo might have some open stuff, but no patch generation/distribution service. IIRC the reason is that you basically need full-time staff knowledgeable in Linux kernel internals to be able to generate the Linux live patches.
Kpatch is fully open
https://github.com/dynup/kpatch
But if you mean the Kernel patch packages themselves, then you are right, looks like there are no free patch packages that one can just download and use.
https://github.com/dynup/kpatch
But if you mean the Kernel patch packages themselves, then you are right, looks like there are no free patch packages that one can just download and use.
Right, kpatch itself is open, but the infrastructure to run it is generally proprietary (except for Gentoo's) and the patches themselves are paywalled (and Gentoo produces no patches).
s/format/repository
With Red Hat becoming more and more IBM [1], this is really a good time to launch this.
[1]: https://access.redhat.com/announcements/6978646
[1]: https://access.redhat.com/announcements/6978646
And Ubuntu more and more Microsoft. At least IBM sells also AIX.
idk i think if forced i would rather throw my hat in with MS than IBM.
An independent Redhat was truly a jewel I took too much for granted now that it’s gone. They were incredible stewards of any project they adopted, they pushed Linux userspce forward for 20 years, had an obsessive commitment to backporting, did literally the best systems integration work, and basically all of it was FOSS.
An independent Redhat was truly a jewel I took too much for granted now that it’s gone. They were incredible stewards of any project they adopted, they pushed Linux userspce forward for 20 years, had an obsessive commitment to backporting, did literally the best systems integration work, and basically all of it was FOSS.
They might be feeling the heat from Debian LTS too.
Is it a rule that enterprise software sales pitches must be really hard to understand? Maybe I’m tired but what is Ubuntu pro - a longer lts?
I've always wondered if these sales pitches were made to be intentionally vague so you have to call a sales rep before you could make a decision.
Interesting to me that it includes Python 2 support. I guess some things never die.
Wow, how reading this makes me hope Ubuntu Pro fails catastrophically.
Supporting Python 2 so publicly at this point is actively damaging to the Python ecosystem. I don't wish to open a flamewar here, it's been debated to death already. Nothing wrong in giving paid Python 2 support to individual companies, but doing so on a distribution scale offloads the consequences of that support to the rest of the ecosystem -- an ecosystem which does not benefit from the money Ubuntu Pro will make.
How this works concretely: because it's Ubuntu (Pro) and because they decided to support Python 2, we in the Python community will continue to receive random bug reports, random feature requests, random crash reports, and more things we aren't paid to deal with. It's a hidden cost, and we're going to pay with our time.
Fuck. That.
Supporting Python 2 so publicly at this point is actively damaging to the Python ecosystem. I don't wish to open a flamewar here, it's been debated to death already. Nothing wrong in giving paid Python 2 support to individual companies, but doing so on a distribution scale offloads the consequences of that support to the rest of the ecosystem -- an ecosystem which does not benefit from the money Ubuntu Pro will make.
How this works concretely: because it's Ubuntu (Pro) and because they decided to support Python 2, we in the Python community will continue to receive random bug reports, random feature requests, random crash reports, and more things we aren't paid to deal with. It's a hidden cost, and we're going to pay with our time.
Fuck. That.
You shouldn't blame Ubuntu here. The Python development community did this to itself.
It offloaded a huge cost of porting literally everything in the universe mostly for syntactic niceties like print and parenthesis. That was an astronomical unfunded downstream mandate. Now, it's paying the consequences. There are codebases which couldn't afford to do that, who are suffering. For example, there's a lot of academic code which was grant-funded, which is widely-used, but with no more funding. Python is used a lot for numerics. That code had better keep working, if you want scientific replicability and apples-to-apples comparison of results.
There are ones who _can't_ do that, for a variety of reasons (many regulatory). Like FORTRAN, Python 2 needs to be around for a long, long time. If I have a system with a multimillion dollar audit / certification process, I can't just up-and-port to Python 3 like a web app.
Bless Ubuntu and other organizations who simply didn't say F-U to all legacy codebases.
I might not even mind if Python 3 was designed to do anything useful: supporting compiled code better, multicore, GPGPU, JIT, or whatever. However, it was mostly minor syntactic sugar. The only breaking change in Python 3 which made sense was probably unicode, and that one didn't have to be so breaking.
It was just so random, stupid, and arbitrary.
Yes, the Python community should deal with "receive random bug reports, random feature requests, random crash reports" and other crap. This should be a very visible failure, or we'll see this again with other projects (not to mention Python 4).
It offloaded a huge cost of porting literally everything in the universe mostly for syntactic niceties like print and parenthesis. That was an astronomical unfunded downstream mandate. Now, it's paying the consequences. There are codebases which couldn't afford to do that, who are suffering. For example, there's a lot of academic code which was grant-funded, which is widely-used, but with no more funding. Python is used a lot for numerics. That code had better keep working, if you want scientific replicability and apples-to-apples comparison of results.
There are ones who _can't_ do that, for a variety of reasons (many regulatory). Like FORTRAN, Python 2 needs to be around for a long, long time. If I have a system with a multimillion dollar audit / certification process, I can't just up-and-port to Python 3 like a web app.
Bless Ubuntu and other organizations who simply didn't say F-U to all legacy codebases.
I might not even mind if Python 3 was designed to do anything useful: supporting compiled code better, multicore, GPGPU, JIT, or whatever. However, it was mostly minor syntactic sugar. The only breaking change in Python 3 which made sense was probably unicode, and that one didn't have to be so breaking.
It was just so random, stupid, and arbitrary.
Yes, the Python community should deal with "receive random bug reports, random feature requests, random crash reports" and other crap. This should be a very visible failure, or we'll see this again with other projects (not to mention Python 4).
Yes the python 3 upgrade was a failure. The python community has learned from the mistakes. What do you want it to do now? This was long enough ago that some Python devs weren’t born yet.
And it wasn’t “all for a print statement” or something, that’s not the pain of the upgrade nor what’s blocking anyone. You would know that, if you had more than passing knowledge about the upgrade.
Pulling scientific reproducibility as an example is a funny one. Python is the least of the issues in that sector. Maybe let’s introduce Docker there, that would be a good, you know, FIRST step. And then python version is irrelevant anyway.
If you want something reproduced, the entire environment should be reproduced, including library versions, compiler versions, etc. Reproducing independently on newer systems will involve updates anyway.
And it wasn’t “all for a print statement” or something, that’s not the pain of the upgrade nor what’s blocking anyone. You would know that, if you had more than passing knowledge about the upgrade.
Pulling scientific reproducibility as an example is a funny one. Python is the least of the issues in that sector. Maybe let’s introduce Docker there, that would be a good, you know, FIRST step. And then python version is irrelevant anyway.
If you want something reproduced, the entire environment should be reproduced, including library versions, compiler versions, etc. Reproducing independently on newer systems will involve updates anyway.
What would I want the Python 3 community to do now? For a start, I would like the Python 3 community not to post attacks like yours. To quote you: "Wow, how reading this makes me hope Ubuntu Pro fails catastrophically."
This suggests the Python 3 community did *not* learn.
To your point about science: that's not quite how science works. I rarely want to run your code + data + system wholesale. You already ran your code on your data, and unless you fabricated something, I can see the results you got from your publication.
In most cases:
- I want to try your algorithm on new data.
- I want to improve upon your algorithm
- I want to try a new algorithm on your data
... and so on. This allows apples-to-apples comparisons.
I sometimes want to be able to replicate results from the 1900's, and commonly going back to the sixties and eighties. You're on a warpath against people using Python for anything not designed for tech-industry style ephemeral code.
Before Python 2 -> Python 3, this was could usually be done either without changes, or with sufficiently minimal changes that it wasn't outside of the realm of a grad student. The whole docker-style mess of dependencies isn't typically a problem; most code uses numpy+pandas, and occasionally, scipy+pylab.
We have decades of experience with this just working with C, C++, Java, and Fortran code, and it more-or-less works okay at this point.
To your conversation style: I'm very familiar with the differences between Python 2 and Python 3. Insulting people isn't a good substitute for an argument. Docker is less than a decade old. Even if it solved the problems you think it solves (it doesn't), and was usable by non-CS grad students (it isn't), this kind of technology churn is exactly what you want to *avoid*.
I hope Ubuntu Pro succeeds spectacularly, to the point where I'd be glad to pay Ubuntu for my *personal* desktop.
If the Python community accepted Python 2 needs to be maintained for a long time (decades, at least), that would go a long ways.
This suggests the Python 3 community did *not* learn.
To your point about science: that's not quite how science works. I rarely want to run your code + data + system wholesale. You already ran your code on your data, and unless you fabricated something, I can see the results you got from your publication.
In most cases:
- I want to try your algorithm on new data.
- I want to improve upon your algorithm
- I want to try a new algorithm on your data
... and so on. This allows apples-to-apples comparisons.
I sometimes want to be able to replicate results from the 1900's, and commonly going back to the sixties and eighties. You're on a warpath against people using Python for anything not designed for tech-industry style ephemeral code.
Before Python 2 -> Python 3, this was could usually be done either without changes, or with sufficiently minimal changes that it wasn't outside of the realm of a grad student. The whole docker-style mess of dependencies isn't typically a problem; most code uses numpy+pandas, and occasionally, scipy+pylab.
We have decades of experience with this just working with C, C++, Java, and Fortran code, and it more-or-less works okay at this point.
To your conversation style: I'm very familiar with the differences between Python 2 and Python 3. Insulting people isn't a good substitute for an argument. Docker is less than a decade old. Even if it solved the problems you think it solves (it doesn't), and was usable by non-CS grad students (it isn't), this kind of technology churn is exactly what you want to *avoid*.
I hope Ubuntu Pro succeeds spectacularly, to the point where I'd be glad to pay Ubuntu for my *personal* desktop.
If the Python community accepted Python 2 needs to be maintained for a long time (decades, at least), that would go a long ways.
WinAmp 2 (1998) was widely liked. WinAmp 3 (2002) was considered bloated, and flopped.
So Nullsoft followed it up with WinAmp 5 – because 2+3=5 – in 2003, which was very broadly the codebase of WinAmp 2 (small and lean) plus the skin support from WinAmp 3 (the only part people liked).
This won people back, and WinAmp is still around and got an update this year, 20 years on.
I think it's too late for there to be a Python 5, but I did read a blog post long ago – which I can't find again, or I'd link to it – which proposed a similar compromise fix to Python, in considerable technical detail.
I am with @blagie on this: the Python world handled the 2→3 transition spectacularly badly. V3 didn't deliver enough, and strong-arming people by just end-of-lifing Python 2 and expecting the world to move on was foolhardy and short-sighted.
(And I don't even use the language myself. I'm just observing.)
It's a real shame Tauthon didn't get more traction and support.
https://github.com/naftaliharris/tauthon
If it had got enough support and continued, maybe the Python maintainers would have learned something, but I've not seen any sign that they have.
This is nothing new. For comparison, Perl 6 went so badly that Perl 5 now looks likely to continue as Perl 7:
https://www.perl.com/article/announcing-perl-7/
And PHP 6 didn't really happen -- AFAICT as a total outsider, Unicode support proved too hard and it was never released; the community backported the important bits to PHP 5, and then a new PHP 7, more modest in scope, developed from PHP 5.
The Python world could have done the same, and Tauthon was an effort in that direction.
It's too late now. I suspect that, just as Perl has lost a massive amount of interest and use, partly from the nearly-two-decade-long effort to release Perl 5, Python has done the same -- sabotaged its own community with this high-handed "your leaders know best" approach.
So Nullsoft followed it up with WinAmp 5 – because 2+3=5 – in 2003, which was very broadly the codebase of WinAmp 2 (small and lean) plus the skin support from WinAmp 3 (the only part people liked).
This won people back, and WinAmp is still around and got an update this year, 20 years on.
I think it's too late for there to be a Python 5, but I did read a blog post long ago – which I can't find again, or I'd link to it – which proposed a similar compromise fix to Python, in considerable technical detail.
I am with @blagie on this: the Python world handled the 2→3 transition spectacularly badly. V3 didn't deliver enough, and strong-arming people by just end-of-lifing Python 2 and expecting the world to move on was foolhardy and short-sighted.
(And I don't even use the language myself. I'm just observing.)
It's a real shame Tauthon didn't get more traction and support.
https://github.com/naftaliharris/tauthon
If it had got enough support and continued, maybe the Python maintainers would have learned something, but I've not seen any sign that they have.
This is nothing new. For comparison, Perl 6 went so badly that Perl 5 now looks likely to continue as Perl 7:
https://www.perl.com/article/announcing-perl-7/
And PHP 6 didn't really happen -- AFAICT as a total outsider, Unicode support proved too hard and it was never released; the community backported the important bits to PHP 5, and then a new PHP 7, more modest in scope, developed from PHP 5.
The Python world could have done the same, and Tauthon was an effort in that direction.
It's too late now. I suspect that, just as Perl has lost a massive amount of interest and use, partly from the nearly-two-decade-long effort to release Perl 5, Python has done the same -- sabotaged its own community with this high-handed "your leaders know best" approach.
I didn't know about tauthon. If I had, I would have thrown my support behind it. That makes a lot of sense.
With programming languages, I feel like there's so much dumb, blind luck involved in which ones win. I personally dislike Perl, but Larry Wall is so clearly and obviously a genius. Everything he does has good, logical reasons, and the Perl 6 mess was at least an understandable mistake and well-reasoned. I can see myself making similar mistakes.
The Python one was just dumb and obnoxious. So much of Python 2→3 feels like a random walk, with things changing, rather than improving.
Changes since then have felt equally half-baked. async is important, but no one thought through how it might work in a terminal, compatibility with non-async code, and especially with coroutines using yield. I would have the rate of progress be half, but see things implemented correctly and intelligently.
With programming languages, I feel like there's so much dumb, blind luck involved in which ones win. I personally dislike Perl, but Larry Wall is so clearly and obviously a genius. Everything he does has good, logical reasons, and the Perl 6 mess was at least an understandable mistake and well-reasoned. I can see myself making similar mistakes.
The Python one was just dumb and obnoxious. So much of Python 2→3 feels like a random walk, with things changing, rather than improving.
python2
>>> map(lambda x: 2 * x, [1, 2, 3, 4])
[2, 4, 6, 8]
python3
>>> map(lambda x: 2 * x, [1, 2, 3, 4])
<map object at 0x7f3df5693310>
Changes since then have felt equally half-baked. async is important, but no one thought through how it might work in a terminal, compatibility with non-async code, and especially with coroutines using yield. I would have the rate of progress be half, but see things implemented correctly and intelligently.
> With programming languages, I feel like there's so much dumb, blind luck involved in which ones win
Very true.
Among my favourites:
Apple's Dylan was an amazing language with an amazing development environment. Ignored.
Oberon, the last scion of Pascal, is a great clean blindingly fast language, and simple too, and the OS of the same name is a thing of beauty.
Both ignored.
It's OSes too.
I mean, UNIX was good, for its time... but Plan 9 was better, in terms of network and GUI integration, but the world ignored it. Inferno is better than Plan 9, in terms of integrating the Taos virtual-processor CPU-independence (and a saner GUI than Plan 9, too) but it went nowhere either.
(Yes, licence agreements had something to do with this, but Linux was neither the first nor the last free UNIX. Before it was BSD, notably 386BSD, and before 386BSD was Coherent (not free, but cheap, and showed it was doable.) After Linux... there are dozens.
If people learned from the model, then even if Plan 9 was under some restrictive licence conditions, it could have been cloned, just as UNIX was, repeatedly.
Concurrent DOS was pretty amazing in its day.
GEM was amazing, but only Atari ST fans noticed.
EPOC, EPOC32 and Symbian were great OSes. Symbian is FOSS now. Nobody cares.
Taos was amazing and should have been the new Amiga.
QNX still is amazing, but Blackberry 10 flopped. Huawei's HarmonyOS is vapourware and marketing: it should just licence BB10. It's real and it works.
Very true.
Among my favourites:
Apple's Dylan was an amazing language with an amazing development environment. Ignored.
Oberon, the last scion of Pascal, is a great clean blindingly fast language, and simple too, and the OS of the same name is a thing of beauty.
Both ignored.
It's OSes too.
I mean, UNIX was good, for its time... but Plan 9 was better, in terms of network and GUI integration, but the world ignored it. Inferno is better than Plan 9, in terms of integrating the Taos virtual-processor CPU-independence (and a saner GUI than Plan 9, too) but it went nowhere either.
(Yes, licence agreements had something to do with this, but Linux was neither the first nor the last free UNIX. Before it was BSD, notably 386BSD, and before 386BSD was Coherent (not free, but cheap, and showed it was doable.) After Linux... there are dozens.
If people learned from the model, then even if Plan 9 was under some restrictive licence conditions, it could have been cloned, just as UNIX was, repeatedly.
Concurrent DOS was pretty amazing in its day.
GEM was amazing, but only Atari ST fans noticed.
EPOC, EPOC32 and Symbian were great OSes. Symbian is FOSS now. Nobody cares.
Taos was amazing and should have been the new Amiga.
QNX still is amazing, but Blackberry 10 flopped. Huawei's HarmonyOS is vapourware and marketing: it should just licence BB10. It's real and it works.
A lot of that was not technical, but I think I'd call roughly half of those random.
For example, I feel like what Linux did uniquely well was the development process. The Linux development process, circa 1995-2000, was unparalleled:
- The community was incredibly open and welcoming. Don't let brash and harsh language be confused with being unwelcoming. Anyone could join.
- There was thorough code review. Low-quality code was not let in. This was an amazing learning process.
- The design decisions were all brilliantly documented on LKML. The quality of discussion there was exceptional.
I attribute a lot of this to Linus' leadership, as well as that of lieutenants like Alan Cox. On top of that, you had really robust corporate support in Red Hat (and, for a while SuSE), and an amazing community, package management, etc. around Debian. There were friendly IRC channels for tech support.
The social components were super-important. And yes, licenses too: The GPL was the right license to prevent parasites.
For example, I feel like what Linux did uniquely well was the development process. The Linux development process, circa 1995-2000, was unparalleled:
- The community was incredibly open and welcoming. Don't let brash and harsh language be confused with being unwelcoming. Anyone could join.
- There was thorough code review. Low-quality code was not let in. This was an amazing learning process.
- The design decisions were all brilliantly documented on LKML. The quality of discussion there was exceptional.
I attribute a lot of this to Linus' leadership, as well as that of lieutenants like Alan Cox. On top of that, you had really robust corporate support in Red Hat (and, for a while SuSE), and an amazing community, package management, etc. around Debian. There were friendly IRC channels for tech support.
The social components were super-important. And yes, licenses too: The GPL was the right license to prevent parasites.
companies need stability, stability implies long-term support. Like it or not, Python 2 is still widely used.
> we in the Python community will continue to receive random bug reports, random feature requests, random crash reports, and more things we aren't paid to deal with.
Can you just close those with “won’t fix?”
Can you just close those with “won’t fix?”
That’s the best case scenario (and still one where we might get complaints, and which takes brainspace). Other cases might be, for example, time taken to debug an issue impossible to reproduce only to find out a week later that it only happens on py2.
Canonical exists to support Ubuntu customers/community, not Python community.
And if the python community has to suffer from the actions needed to support said customers, fuck em right? It’s not like python ever did anything for canonical (a company that has been entirely built by python from the ground up), eh?
“F you got mine” got us climate change. Be constructive.
“F you got mine” got us climate change. Be constructive.
> And if the python community has to suffer from the actions needed to support said customers, fuck em right?
Nobody is asking the python community to do anything. Canonical isn't sending stalkers after their members. They're just providing support for the software made by a community for whom backwards-compatibility isn't a big priority.
> a company that has been entirely built by python from the ground up
I don't think your knowledge of Canonical is very accurate.
> “F you got mine” got us climate change.
Climate change... Next you'll tell me how this move is related to MAGA.
Nobody is asking the python community to do anything. Canonical isn't sending stalkers after their members. They're just providing support for the software made by a community for whom backwards-compatibility isn't a big priority.
> a company that has been entirely built by python from the ground up
I don't think your knowledge of Canonical is very accurate.
> “F you got mine” got us climate change.
Climate change... Next you'll tell me how this move is related to MAGA.
> Free for personal use
> Anyone can use Ubuntu Pro for free on up to 5 machines, or 50 if you are an official Ubuntu Community member.
This is pretty neat. Will have to check it out.
> Anyone can use Ubuntu Pro for free on up to 5 machines, or 50 if you are an official Ubuntu Community member.
This is pretty neat. Will have to check it out.
I'd like to call it Enterprise rather than Pro. Professional sysadmin may not want to keep the same OS version for a decade.
A decade of CVE coverage for all of universe? Colour me skeptical that they can actually pull that off.
Also they support complete Software projects, like WordPress, which is truly impressive.
I dont know how they will do it, especially when comparing with RHEL, which only supports around 3000 packages, and then you have to rely on EPEL which has "community" support.
I dont know how they will do it, especially when comparing with RHEL, which only supports around 3000 packages, and then you have to rely on EPEL which has "community" support.
Maybe I don't fully understand this:
does this mean that they would manually backport/reimplement fixes to whichever (old) version of software X that has implemented security fixes for its higher version (but not for the lower version used by the "Ubuntu Pro version Y", assuming that Ubuntu Pro would stick to a specific version of software X)?
does this mean that they would manually backport/reimplement fixes to whichever (old) version of software X that has implemented security fixes for its higher version (but not for the lower version used by the "Ubuntu Pro version Y", assuming that Ubuntu Pro would stick to a specific version of software X)?
Yes, that's what backporting is.
Porting a patch back to an older version.
Since Ubuntu and Debian preserve stability by not doing any feature upgrades.
Which is done apperantly differently in RHEL land, podman gets updated to the latest version regularly, I couldn't find a clear answer to RHEL's update policy and how it works.
Ubuntu also has exceptions for packages like Firefox, which need to get updated often, and is something Debian struggles with regularly.
However Ubuntu is snapping up everything lately, I was surprised the `pro` utility was a normal package instead of a snap.
Porting a patch back to an older version.
Since Ubuntu and Debian preserve stability by not doing any feature upgrades.
Which is done apperantly differently in RHEL land, podman gets updated to the latest version regularly, I couldn't find a clear answer to RHEL's update policy and how it works.
Ubuntu also has exceptions for packages like Firefox, which need to get updated often, and is something Debian struggles with regularly.
However Ubuntu is snapping up everything lately, I was surprised the `pro` utility was a normal package instead of a snap.
Pardon my ignorance, but what even is this?
From my understanding, it's Ubuntu selling more LTS updates. By "five machines" for free, they mean you can apply a free subscription token to up to five machines.
It sounded like they were handing out VMs/VPS instances for use, but you need to already own/run a VM with Ubuntu on it to apply your free token onto.
From my understanding, it's Ubuntu selling more LTS updates. By "five machines" for free, they mean you can apply a free subscription token to up to five machines.
It sounded like they were handing out VMs/VPS instances for use, but you need to already own/run a VM with Ubuntu on it to apply your free token onto.
I don't mind paying $25/year/desktop nearly as much as I mind the twenty clicks to find out the $25 is an annual fee.
Look at it: https://ubuntu.com/pricing/pro
Whoever did this web design should be shot.
I had to go partway through placing an order to find out this is an annual (as opposed to monthly, quarterly, or lifetime) fee. I still have no idea which fees are per-machine, and which are one-time.
The server pricing is messed up too:
(1) I would never pay $225/year for my nano instances.
(2) I have no idea how to count licenses in my cloud, where servers spin up and down all the time in response to load.
(3) I'd pay a lot more for uber-large instances (if I were currently using them, which I'm currently not).
The server pricing ought to just take a flat cut of my EC2 costs. I'd gladly pay Ubuntu a flat markup.
Look at it: https://ubuntu.com/pricing/pro
Whoever did this web design should be shot.
I had to go partway through placing an order to find out this is an annual (as opposed to monthly, quarterly, or lifetime) fee. I still have no idea which fees are per-machine, and which are one-time.
The server pricing is messed up too:
(1) I would never pay $225/year for my nano instances.
(2) I have no idea how to count licenses in my cloud, where servers spin up and down all the time in response to load.
(3) I'd pay a lot more for uber-large instances (if I were currently using them, which I'm currently not).
The server pricing ought to just take a flat cut of my EC2 costs. I'd gladly pay Ubuntu a flat markup.
What a mess indeed. I did manage to find this:
> Priced for the cloud
> Ubuntu Pro pricing tracks the underlying EC2 cost, starting at 20% for the smallest t3.nano instances, and ramping down to less than 1%.
That probably means it’ll be in the AWS Marketplace and will factor in to your instance rate. For example: https://aws.amazon.com/marketplace/pp/prodview-uy7jg4dds3qjw
> Priced for the cloud
> Ubuntu Pro pricing tracks the underlying EC2 cost, starting at 20% for the smallest t3.nano instances, and ramping down to less than 1%.
That probably means it’ll be in the AWS Marketplace and will factor in to your instance rate. For example: https://aws.amazon.com/marketplace/pp/prodview-uy7jg4dds3qjw
Yes, I can't work out if this is free for virtual servers?? Would imagine not, but what applies then?
Yes it is.
Up to 5 instances.
[deleted]
> Whoever did this web design should be shot.
I think this kind of wording should not be normalized on this website, and asking for someone to be shot is a gross exaggeration. The amount of disrespect for the developers, designers and victims and families of those affected by gun violence (including women affected by domestic violence).
I suggest you expand your lexicon in the future and use the appropriate choice of words.
I think this kind of wording should not be normalized on this website, and asking for someone to be shot is a gross exaggeration. The amount of disrespect for the developers, designers and victims and families of those affected by gun violence (including women affected by domestic violence).
I suggest you expand your lexicon in the future and use the appropriate choice of words.