Re: Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates
Nope, that's not the standard, expected procedure. It is always better to have someone else verify a fix, it's sometimes not feasible though. "While not ideal it is also possible for the uploader of the fix to perform the verification of the package in *-proposed" - https://wiki.ubuntu.com/StableReleaseUpdates#Verification On Mon, Aug 19, 2019 at 4:31 AM Julian Andres Klode < julian.kl...@canonical.com> wrote: > On Fri, Aug 16, 2019 at 01:07:18PM +0200, Andreas Ronnquist wrote: > > Forwarding to Ubuntu-devel, and posting as a reminder to the SciTE > > mailinglist. > > > > It would still be nice to have this in 18.04, but I cannot review my > > own work. > > Why not? Verifying your own SRU is the standard, expected procedure. > > > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
The mentioned Debian bug #880507 is one of the advantages of moving from cron to systemd units -see proposed unit file in [1]. The timers in systemd are really perfect for this... I use locate all the time. I really like how much simpler it is then find. I don't have to think to usually get what I'm looking for. I'm going to experiment with using grep /var/lib/dpkg/info/*.list as the majority of files I run locate for are from packages.. >From a product perspective it does make sense to remove: * Desktop has tracker installed by default. The majority of users will use that instead as it's integrated with the GUI. * The majority of cloud/server deployments aren't interactive these days. It's a waste there. They key group I can see wanting it are developers - who can install it. My 2 cents, Bryan [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882993 On Wed, May 22, 2019 at 7:09 PM Brian Murray wrote: > The Ubuntu Foundations team was recently looking at an issue with > mlocate[1] and the effect it has on all users of Ubuntu. While that > specific issue is fixable there are also issues[2,3] with keeping > PRUNEFS and PRUNEPATHS current in updatedb.conf. So we ended up > questioning the usefulness of installing mlocate by default on systems > at all. We believe that find is an adequate replacement for mlocate but > want to hear from you about use cases where it may not be. I'll start > with a personal example: > > "I don't remember (because I need to know so infrequently) where the > meta-release file is cached on disk by update-manager and use locate to > find it. The find command itself is inadequate because the cached file > exists in both /home and /var." > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880507 > [2] http://launchpad.net/bugs/827841 > [3] http://launchpad.net/bugs/1823518 > > Thanks, > -- > Brian Murray > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposal: Let's drop i386
I definitely should have included more links to previous discussions - including this survey I did 4 years ago - https://bryanquigley.com/posts /crazy-ideas/32-bit-usage-survey-results.html. Is it ethical to continue to support a platform that we may not be able to provide meaningful security support for? Ignoring meltdown for a moment, Spectre V2 requires microcode updates to protect against it - I'm not sure they will ever come for hardware from 2006. b) Those, who do not want to consume more resources due to ethical considerations (that's the one for me): how many people could fed or how much CO2 prevented, if all systems were some percent smaller on disk/RAM, including IT-system production and operation related resource usage? Wasting resources is also about freedom, as we deprive others who cannot afford them/fight for them in the same way we can do. My laptop is from 2009 (albeit upgraded).. I like holding on to devices myself. If we fully drop the port, every i386 user still has some level of Ubuntu support until 2023. In any case as you go back further processors become much less power efficient - are you sure that you aren't the one wasting resources? It happens that Energy Star requirements significantly increased requirements in 2007 especially around idle power usage which is one of the biggest wasters of power in computers generally (see https://www.energystar.gov/index.cfm?c=archives.computer_spec_version_4_0). Kind regards, Bryan On Fri, May 11, 2018 at 11:32 AM, Fiedler Roman wrote: > > Von: ubuntu-devel [mailto:ubuntu-devel-boun...@lists.ubuntu.com] Im > > > > Hello, > > > > Less and less non-amd64-compatible i386 hardware is available for > > consumers to buy today from anything but computer part recycling centers. > > The last of these machines were manufactured over a decade ago, and > > support from an increasing number of upstream projects has ended. ... > > > > ... > > > > We still have a relatively high number if i386 downloads but that doesn't > > mean users machines are not capable of amd64. For the flavors remaining > > today on i386 here are some i386 to amd64 ratios for 18.04: > > > > Lubuntu cdimage - 0.87 > > Lubuntu tracker - 0.64 > > ... > > This decision is not only about numbers, but somehow also about ethics. > The number of e.g. wheel-chair users or other disabled persons might not be > relevant for a society/economy in terms of numbers. But we honor the value > of freedom, also for those, who are not that well off than we are. Those > would not be able to participate in the same way, if we would not assist > them by providing support for that minority. > > So for the i386 discussion, there might be only two distinct groups of > users worth considering: > > a) Those, who cannot afford newer systems due to economical reasons. > > b) Those, who do not want to consume more resources due to ethical > considerations (that's the one for me): how many people could fed or how > much CO2 prevented, if all systems were some percent smaller on disk/RAM, > including IT-system production and operation related resource usage? > Wasting resources is also about freedom, as we deprive others who cannot > afford them/fight for them in the same way we can do. > > > Those two groups could be seen apart from a third one: those, who do not > want to change for convenience (parking on the wheel-chair parking space, > because it is closer to the entrance), thus depriving others from resources > (in our case developers having to care for one platform more). > > How to value all those arguments might be more something for a Ubuntu > ethics board (if existing), not just the mailing list? But first to get > more insight, add some online survey link beside each i386-download asking > users for their reasons? > > LG Roman > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposal: Let's drop i386
Nice catch! I just looked for error stack traces that matched between the i386 version and amd64 and then compared them. I only removed duplicates that we're in the flavors I was comparing - my mistake. Xubuntu error (thunar) - 0.10 - thunar also included in Ubuntu studio The general process was taking these two links, and finding and comparing the same stacktrace: https://errors.ubuntu.com/?release=Ubuntu%2018.04&packageset=xubuntu&period= week&pkg_arch=i386 https://errors.ubuntu.com/?release=Ubuntu%2018.04&packageset=xubuntu&period= week&pkg_arch=amd64 engrampa was a very bad choice. i386 for the Ubuntu kylin package set doesn't seem to have enough specific bugs for another comparison: https://errors.ubuntu.com/?release=Ubuntu%2018.04&; packageset=ubuntukylin&period=week&pkg_arch=amd64 https://errors.ubuntu.com/?release=Ubuntu%2018.04&; packageset=ubuntukylin&period=week&pkg_arch=i386 Thanks, Bryan On Thu, May 10, 2018 at 6:01 PM, Brian Murray wrote: > On Wed, May 09, 2018 at 04:07:23PM -0400, Bryan Quigley wrote: > > Hello, > > > > Less and less non-amd64-compatible i386 hardware is available for > consumers > > to buy today from anything but computer part recycling centers. The last > of > > these machines were manufactured over a decade ago, and support from > > an increasing > > number of upstream projects has ended. > > > > Ubuntu and flavors just completed the 18.04 release cycle. This released > > version will either be supported until 2021 or 2023, depending on the > > product, team, and willingness to support it. At that point in time, the > > majority of these machines are approaching two decades old. > > > > >>Previous 2016 thread: And in 2018, the question will come if we can > > effectively provide security support on i386. > > We can't. Machines running i386 Ubuntu which are capable of running > amd64 > > Ubuntu are vulnerable to the critical Meltdown vulnerability where they > > wouldn't be if they were running amd64. (Some actual i386 hardware simply > > isn't vulnerable, but some is). > > > > We still have a relatively high number if i386 downloads but that doesn't > > mean users machines are not capable of amd64. For the flavors remaining > > today on i386 here are some i386 to amd64 ratios for 18.04: > > > > Lubuntu cdimage - 0.87 > > Lubuntu tracker - 0.64 > > Lubuntu error (pcmanfm) - 0.11 > > Xubuntu cdimage - 0.49 > > Xubuntu tracker - 0.30 > > Xubuntu error (thunar) - 0.10 > > Kylin tracker - 0.30 > > Kylin error (engrampa) - 0.10 > > Kubuntu cdimage - 0.14 > > Kubuntu tracker - 0.12 > > Kubuntu error (kinit) - 0.07 > > > > The data retrieved from cdimage is for a limited time period on May 7th. > All > > cdimage statistics included many hundreds to thousands of downloads > (except > > Ubuntu Kylin due to it using it's own CDN, so not being included here). > The > > torrent tracker results are available here: http://torrent.ubuntu.com: > 6969/ > > . > > The error tracker statistics come from comparing top bugs shared between > > i386 and amd64 over last week. Bugs that affect multiple flavors are not > > included. > > It's not fully understood why there is a large discrepancy between the > > error tracker and other sources - but it's possible apport doesn't work > as > > well in low memory. > > Could you elaborate on the methodology you used to create these Error > Tracker statistics? > > I'm not certain engrampa was a representative choice given that it is > also part of the xubuntu-desktop and ubuntu-mate-desktop tasks. > > -- > Brian Murray > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubiquity NG - was Re: ubiquity migrated to git
On Tue, May 8, 2018 at 7:31 PM, Simon Quigley wrote: > Hello Mark, > > On 05/05/2018 01:15 AM, Mark Shuttleworth wrote: > > > First, we have Curtin, which knows how to take a description of a > > machine and do-the-right-thing; partitioning, installing, and cleaning > > up. Curtin is neat and efficient, super-fast, and it's used by both MAAS > > and the new Ubuntu Server installer, Subiquity. It knows how to install > > a couple of different flavours of Linux, including Ubuntu and CentOS, > > which could be handy. It's probably the best place for us to handle new > > kinds of partitioning and root filesystem and network storage. > > > > Second, we have MAAS, which has some very nice HTML interfaces for > > configuring network and storage on a machine. All of that lines up with > > Curtin, because MAAS uses Curtin to do the actual install. So we have > > the beginnings of an HTML5 installer. > > Would we be able to customize this in a way that's fit for desktop users > rather than server users? A fork might need to happen there. > There are no technical reasons why MAAS/Curtin can't be used for desktop installs. I'm not sure how much sense it makes to reuse the MAAS UI bits though.. We only ask for network bits if you are not connected to a wireless network. I'd love if we at least move to subiquity/curtin because that means we have to publish desktop MAAS images which has been something I've been pushing for a while now [1]. This would push us in the direction of "one" best practice way to install Ubuntu on almost everything. It may even be possible with subiquity to have a text based fallback on a normal live image. If possible this might allow an Alternate style install (like Lubuntu has) for all flavors for free. > > > Third, we have Electron, which is the HTML5 app framework used by world > > class app developers. Skype, Spotify and a ton of GREAT apps on Ubuntu > > are Electron apps. > > I respectfully disagree that this is the correct approach for a system > installer. With all due respect to these very popular applications, > Electron uses quite a bit of system resources and could be interesting > to get working correctly. If you are absolutely certain that this is the > way to go, I won't argue this point too much, but I believe that you > would have triple the speed (and/or it would use a third of the memory) > by writing a native application rather than an Electron one, and with > proper testing and organization (perhaps by using a compiled language > rather than an interpreted one, etc.), it would be a very welcome speed > jump over the current Ubiquity codebase. > Additionally, we'd have to bring Chromium up to the requirements (snappy edition) for Main. (which I wouldn't mind, but doesn't make sense just for this) Kind regards, Bryan [1] https://bugs.launchpad.net/maas/+bug/1584949 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Proposal: Let's drop i386
Hello, Less and less non-amd64-compatible i386 hardware is available for consumers to buy today from anything but computer part recycling centers. The last of these machines were manufactured over a decade ago, and support from an increasing number of upstream projects has ended. Ubuntu and flavors just completed the 18.04 release cycle. This released version will either be supported until 2021 or 2023, depending on the product, team, and willingness to support it. At that point in time, the majority of these machines are approaching two decades old. >>Previous 2016 thread: And in 2018, the question will come if we can effectively provide security support on i386. We can't. Machines running i386 Ubuntu which are capable of running amd64 Ubuntu are vulnerable to the critical Meltdown vulnerability where they wouldn't be if they were running amd64. (Some actual i386 hardware simply isn't vulnerable, but some is). We still have a relatively high number if i386 downloads but that doesn't mean users machines are not capable of amd64. For the flavors remaining today on i386 here are some i386 to amd64 ratios for 18.04: Lubuntu cdimage - 0.87 Lubuntu tracker - 0.64 Lubuntu error (pcmanfm) - 0.11 Xubuntu cdimage - 0.49 Xubuntu tracker - 0.30 Xubuntu error (thunar) - 0.10 Kylin tracker - 0.30 Kylin error (engrampa) - 0.10 Kubuntu cdimage - 0.14 Kubuntu tracker - 0.12 Kubuntu error (kinit) - 0.07 The data retrieved from cdimage is for a limited time period on May 7th. All cdimage statistics included many hundreds to thousands of downloads (except Ubuntu Kylin due to it using it's own CDN, so not being included here). The torrent tracker results are available here: http://torrent.ubuntu.com:6969/ . The error tracker statistics come from comparing top bugs shared between i386 and amd64 over last week. Bugs that affect multiple flavors are not included. It's not fully understood why there is a large discrepancy between the error tracker and other sources - but it's possible apport doesn't work as well in low memory. With Ubuntu MATE, Ubuntu Budgie, and Ubuntu Studio joining Ubuntu Desktop and Server in not offering i386 support in order to focus their efforts, and these statistics in mind, we (flavors) should all join them. Now is the ideal time to do so, because it's before the Cosmic cycle is really under way, and if support were continued for i386, we don't want users to meet a dead end with respect to upgrade paths, and would support it until 20.04 (which means either five or seven more years of i386). Users still have the support cycle of 18.04 to use their machines and get full support, so these machines will still be able to function. But with no new machines being manufactured, we have to deprecate support at some point. The first step would be to all agree on dropping images/installers but we should keep the end goal of dropping the port in mind ideally soon as well. On the list of known blockers for removing the i386 port are Steam and Wine. Solus' snapped Steam is progressing nicely and Steam deb is difficult to maintain as is [See removal bug]. That leaves coming up with a good way forward for Wine. Thanks! Simon Quigley Bryan Quigley [2016 email thread] https://lists.ubuntu.com/archives/ubuntu-devel/2016-June/039420.html (was Installation Media and supportability of i386 in 18.04 LTS Re: Ubuntu Desktop on i386) [removal bug] https://pad.lv/1759715 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Make systemd journal persistent | remove rsyslog (by default)
On Thu, Jan 12, 2017 at 11:20 AM, Jamie Strandboge wrote: ... > There are two things here: > 1. make systemd journal persistent > 2. avoid duplicate logs from rsyslog > > Why not just do '1' and let rsyslog remain? The standard logs are rotated so > this shouldn't be overly burdensome. Have you measured how much the duplicate > logs would take on a typical system? Just doing '1' completely solves my problem and I have not been able to find any significant performance issues when looking at just boot time. That also could lend itself to interim options like logging less to rsyslog but keeping it for now, which might work around any issues that come up. So yes, I'm totally open to just doing '1'. Kind regards, Bryan >> On Wed, Jan 11, 2017 at 5:32 PM, Jamie Strandboge >> wrote: >> > >> > On Wed, 2017-01-11 at 08:29 +0100, Martin Pitt wrote: >> > > >> > > Jamie Strandboge [2017-01-10 16:27 -0600]: >> > > > >> > > > >> > > > Remote logging. Rsyslog is far superior in this regard. Granted, remote >> > > > logging >> > > > is not enabled by default but it is a requirement in many environments. >> > > The systemd-journal-remote package does provide the necessary tools and >> > > is >> > > reasonably flexible (push or pull, builtin https or using arbitrary ports >> > > which >> > > you e. g. could forward through ssh). It might not be as flexible as >> > > rsyslog, >> > > but as one needs to set up remote logging manually anyway, you always >> > > have >> > > the >> > > possibility of picking rsyslog, journal, or even something else. >> > > >> > Yes, but the 'logged to' system needs to be running systemd[1]. rsyslog >> > speaks >> > the standard syslog protocol on 514/udp, but systemd-journal does not. >> > >> > [1]https://www.freedesktop.org/software/systemd/man/systemd-journal-remote.h >> > tml >> > >> > -- >> > Jamie Strandboge | http://www.canonical.com >> > >> > >> > -- >> > ubuntu-devel mailing list >> > ubuntu-devel@lists.ubuntu.com >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo >> > /ubuntu-devel >> > > -- > Jamie Strandboge | http://www.canonical.com > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Make systemd journal persistent | remove rsyslog (by default)
On Tue, Jan 10, 2017 at 7:07 PM, Jeremy Bicha wrote: > On 10 January 2017 at 17:04, Bryan Quigley > wrote: >> I'm sure I missed some positives/negatives. Thoughts on doing this for >> Zesty? > > We would need to install gnome-logs instead of gnome-system-log on > Ubuntu Desktop. Indeed. Nice catch. > And probably have gnome-system-log removed on upgrade. Those who > manually enabled syslog could then install gnome-system-log after if > they want. I believe that if we drop gnome-system-log from main (and having nothing depend on it), do-release-upgrade will give users the options to remove it. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Make systemd journal persistent | remove rsyslog (by default)
We could explicitly keep rsyslog supported in main for at least 18.04 for the for those who need it (or indefinitely if we find it's still needed for remote enterprise logging). I was thinking that we might have to keep it in main until 18.04 anyway for upgrades. Kind regards, Bryan On Wed, Jan 11, 2017 at 5:32 PM, Jamie Strandboge wrote: > On Wed, 2017-01-11 at 08:29 +0100, Martin Pitt wrote: >> Jamie Strandboge [2017-01-10 16:27 -0600]: >> > >> > Remote logging. Rsyslog is far superior in this regard. Granted, remote >> > logging >> > is not enabled by default but it is a requirement in many environments. >> The systemd-journal-remote package does provide the necessary tools and is >> reasonably flexible (push or pull, builtin https or using arbitrary ports >> which >> you e. g. could forward through ssh). It might not be as flexible as >> rsyslog, >> but as one needs to set up remote logging manually anyway, you always have >> the >> possibility of picking rsyslog, journal, or even something else. >> > Yes, but the 'logged to' system needs to be running systemd[1]. rsyslog speaks > the standard syslog protocol on 514/udp, but systemd-journal does not. > > [1]https://www.freedesktop.org/software/systemd/man/systemd-journal-remote.html > > -- > Jamie Strandboge | http://www.canonical.com > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Make systemd journal persistent | remove rsyslog (by default)
Hi, In debugging a shutdown issue I came across a bug [1] that indicates for us to get better logs [2] during shutdown we really need to make the systemd journal persistent. We would also need to remove rsyslog by default so we don't have duplicate writing of logs to disk. Aside from shutdown logs we also get a lot of other nice metadata. For instance, you can ask for all the logs since a certain date. You can trivially view the logs from 2 boots ago. The negative is it is in a binary format and you have to use journalctl to read it. I'm sure I missed some positives/negatives. Thoughts on doing this for Zesty? To try it out: sudo mkdir /var/log/journal reboot twice and now you can view old boots (journalctl --list-boots) (then optionally) apt-get remove rsyslog Kind regards, Bryan [1] https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1618188 [2] http://pastebin.ubuntu.com/23776783/ -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Keep or remove software-center?
I'd say we should remove it, especially because we really don't want anyone stumbling on to using it at this point. $ reverse-depends src:software-center Reverse-Recommends == * mythbuntu-desktop [powerpc] (for software-center) - looks like an old depends as mythbuntu doesn't appear to do powerpc builds anymore * oneconf (for software-center) - for syncing package lists in software center, also a candidate to be removed? Reverse-Depends === * ti-omap4-software-channel (for software-center) - Hasn't been updated since initial release in 2011, not sure if it's still needed. - It actually is a desktop file that installs this outdated PPA - https://launchpad.net/~tiomap-dev/+archive/ubuntu/release?field.series_filter=precise. It also appears to hardcode the maverick release. I think we can definitely drop this.. Packages without architectures listed are reverse-dependencies in: amd64, arm64, armhf, i386, powerpc, ppc64el, s390x bryan@desktop:~$ reverse-depends -b src:software-center No reverse dependencies found Kind regards, Bryan On Mon, Oct 10, 2016 at 9:38 AM, Barry Warsaw wrote: > On Oct 10, 2016, at 03:15 PM, Martin Pitt wrote: > >>I just noticed that we still have software-center in yakkety. It >>hasn't been maintained for several cycles, we never found anyone who >>wanted to port it to Python 3, the desktop team moved to >>gnome-software a while ago, and it isn't shipped on any image/flavor. >> >>Is there still some reason to keep it, or someone who wants to >>maintain it in Ubuntu? If not, I think we should remove it. >>(This doesn't prevent it from reentering Ubuntu in a later release, of >>course). > > We decided to drop it many cycles ago, which is why it's not seen any > significant development in a long while. I used to track its removal > (i.e. occasionally remember to ping ;) but I pretty much assumed it was going > away once the switch to g-s was complete. > > I'd vote for removing it as soon as possible from Zazzy Zorilla. There are a > couple of revdeps and revrecs and it's not worth chasing down any unintended > fallout this close to the Yakkety release. > > Cheers, > -Barry > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Installation Media and supportability of i386 in 18.04 LTS Re: Ubuntu Desktop on i386
On Fri, Jul 8, 2016 at 2:34 PM, Josh DuBois wrote: > On Tue, Jun 28, 2016 at 9:54 AM, Dimitri John Ledkov > wrote: > >> 18.10+: >> * Stop providing i386 port >> * Run legacy i386 only application in snaps / containers / virtual >> machines > > In terms of running legacy i386 applications in > snaps / containers / VMs only, Wine is a major user of 32-bit > libraries which I didn't seen mentioned on this thread. Many of the > apps people run with Wine are legacy 32-bit only Windows applications > where recompiling to 64-bit is simply not an option. Wine hasn't been mentioned publicly but it was definitely mentioned a lot in the survey I did. We certainly want to make sure users can keep using it. > Wine users should be fine using a 64-bit .iso image for install purposes, > but the need to package a full set of 32-bit libraries would be a major > burden for wine packagers. In particular Wine needs access to the graphics > stack, the 32-bit version of which was mentioned in this thread as possibly > expendable. That's certainly something we would need to look into. > By way of disclosure, I am the product manager for CodeWeavers' CrossOver, a > commercial wrapper for Wine. I think all Wine users would be negatively > impacted > if 32-bit libraries were no longer available from Ubuntu, however. Please > keep > that in mind as you decide when and whether to drop 32-bit libraries or > merely > cease building 32-bit install .isos. > > We'd really like to have the libraries stick around. It's actually even more complicated than that. Wine depends on Multiarch for building itself in Debian/Ubuntu. For instance when I install wine, I'm actually installing both a 32-bit and 64-bit binary of wine. I could see us: * Determine Snappy is the best way to distribute Wine (which would require the bundling of 32-bit libs I think). * Keep a small amount of i386 libs/apps in 18.10+ including whatever it takes to build/run Wine (but drop the majority of packages) * Change Wine a bit to make this easier (no idea what this would entail, but we have 2+ years). In any case, I'm not going to push for dropping the i386 port until we have a good way for Wine to work. As mentioned we aren't planning to really consider that until 2018. The focus now is purely on dropping 32-bit install isos and select related packages. Thanks! Bryan -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Installation Media and supportability of i386 in 18.04 LTS Re: Ubuntu Desktop on i386
Survey is done. Please only fill this out if you are running a i386 Ubuntu (any flavor Kubuntu, Lubuntu, Server, Cloud, etc). I'm going to wait for a few a bit before posting it on news sites to see if I made any mistakes in the survey. Let me know if anything is amiss. http://goo.gl/forms/UfAHxIitdWEUPl5K2 On Tue, Jun 28, 2016 at 11:31 AM, Dimitri John Ledkov wrote: > Hello, > > > On 28 June 2016 at 16:02, Bryan Quigley > wrote: > > Hi Dimitri, > > > > I'll work on creating a new public survey (and possibly a separate > > partner/customer one). > > > > Thank you! > > > Based on my previous one, my biggest concerns were for Lubuntu/Xubuntu. > > With recent memory testing [1] it's even more true for Lubuntu. (And if > you > > only <512 MB of Ram - Docker, ZFS and system intensive games likely won't > > matter to you, and Firefox is much better in low-memory than Chrome > anyway) > > > > I don't see any point in continuing to build i386 cloud-images for > > 16.10/17.04/17.10 if we're just going to drop them for 18.04. If we're > > concerned with memory usage in small cloud instances we could just work > to > > provide something like zram by default. > > > > From the survey it makes sense to investigate our memory usage and > figure out if we can lower steady state committed memory throughout. > Offering zram to cloud instances sounds interesting, this sounds a bit > like the swapfile package for cloud. > > > I'd like to see most flavors drop i386 before 18.04 (might as well do it > > now..) but we keep the 18.04 kernel and d-i (and Lubuntu) for i386. I > don't > > see much reason to separate the userspace security support, but we will > see > > what the surveys say. > > > > Anyway next steps I see: > > * We discussed dropping Ubuntu-desktop i386 images for 16.10+ previously. > > That seems like the obvious one to drop i386 first. Anyone against doing > > that now? > > Well Ubuntu Desktop should weigh in what they want to do. > > > * I'll write and distribute the surveys. > > +1 > > > * Ask specific flavors if they want to drop i386 ahead of these plans > being > > finished. > > > > Or even more broadly, what is each flavor current vision w.r.t. i386 > over the next LTS cycle. > > > Kind regards, > > Bryan > > > > [1] > > > https://bryanquigley.com/memory-usage/ubuntu-16-04-livecd-memory-usage-compared > > > > On Tue, Jun 28, 2016 at 9:54 AM, Dimitri John Ledkov > > wrote: > >> > >> Hello Bryan, > >> > >> Let me resurrect this thread. In the context of what we should be > >> doing in 18.04 and what to do between now and then. > >> > >> In 2018: > >> - it will be over 2 years since 3rd party ISVs stopped supporting > >> software on i386, or even never had it officially > >> - e.g. Google Chrome, ZFS, Docker, etc > >> - with both desktop and server software developed, tested and deployed > >> on amd64 only > >> > >> And in 2018, the question will come if we can effectively provide > >> security support on i386. > >> > >> Between now and 2018, it would be logical to limit amount of new > >> installations of i386, because cross-grading between i386->amd64 is > >> not something we can reliably ship. > >> We must continue provide the i386 port, to support multiarch and 3rd > >> party legacy application that are only available as i386 binaries. > >> > >> Building i386 images is not "for free", it comes at the cost of > >> utilizing our build farm, QA and validation time. Whilst we have > >> scalable build-farms, i386 still requires all packages, autopackage > >> tests, and ISOs to be revalidated across our infrastructure. As well > >> as take up mirror space & bandwidth. > >> > >> Thus the question is what can we and what should we do to limit i386 > >> installations before they become unsupportable? > >> > >> Here is an example draft plan to bikeshed over: > >> > >> 16.10, 17.04, 17.10: > >> * continue to provide i386 port to run legacy applications on amd64 > >> * continue to build i386 d-i / netboot installer > >> * continue to build i386 kernel > >> * continue to build i386 cloud-images > >> * stop producing i386 ubuntu-desktop.iso > >> * stop producing i386 ubuntu-server.iso > >> > >> 18.04 LTS: > >> * continue to provide i386 port to run lega
Re: Installation Media and supportability of i386 in 18.04 LTS Re: Ubuntu Desktop on i386
Hi Dimitri, I'll work on creating a new public survey (and possibly a separate partner/customer one). Based on my previous one, my biggest concerns were for Lubuntu/Xubuntu. With recent memory testing [1] it's even more true for Lubuntu. (And if you only <512 MB of Ram - Docker, ZFS and system intensive games likely won't matter to you, and Firefox is much better in low-memory than Chrome anyway) I don't see any point in continuing to build i386 cloud-images for 16.10/17.04/17.10 if we're just going to drop them for 18.04. If we're concerned with memory usage in small cloud instances we could just work to provide something like zram by default. I'd like to see most flavors drop i386 before 18.04 (might as well do it now..) but we keep the 18.04 kernel and d-i (and Lubuntu) for i386. I don't see much reason to separate the userspace security support, but we will see what the surveys say. Anyway next steps I see: * We discussed dropping Ubuntu-desktop i386 images for 16.10+ previously. That seems like the obvious one to drop i386 first. Anyone against doing that now? * I'll write and distribute the surveys. * Ask specific flavors if they want to drop i386 ahead of these plans being finished. Kind regards, Bryan [1] https://bryanquigley.com/memory-usage/ubuntu-16-04-livecd-memory-usage-compared On Tue, Jun 28, 2016 at 9:54 AM, Dimitri John Ledkov wrote: > Hello Bryan, > > Let me resurrect this thread. In the context of what we should be > doing in 18.04 and what to do between now and then. > > In 2018: > - it will be over 2 years since 3rd party ISVs stopped supporting > software on i386, or even never had it officially > - e.g. Google Chrome, ZFS, Docker, etc > - with both desktop and server software developed, tested and deployed > on amd64 only > > And in 2018, the question will come if we can effectively provide > security support on i386. > > Between now and 2018, it would be logical to limit amount of new > installations of i386, because cross-grading between i386->amd64 is > not something we can reliably ship. > We must continue provide the i386 port, to support multiarch and 3rd > party legacy application that are only available as i386 binaries. > > Building i386 images is not "for free", it comes at the cost of > utilizing our build farm, QA and validation time. Whilst we have > scalable build-farms, i386 still requires all packages, autopackage > tests, and ISOs to be revalidated across our infrastructure. As well > as take up mirror space & bandwidth. > > Thus the question is what can we and what should we do to limit i386 > installations before they become unsupportable? > > Here is an example draft plan to bikeshed over: > > 16.10, 17.04, 17.10: > * continue to provide i386 port to run legacy applications on amd64 > * continue to build i386 d-i / netboot installer > * continue to build i386 kernel > * continue to build i386 cloud-images > * stop producing i386 ubuntu-desktop.iso > * stop producing i386 ubuntu-server.iso > > 18.04 LTS: > * continue to provide i386 port to run legacy applications on amd64 > * stop producing i386 d-i / netboot installer > * stop producing i386 kernel > * stop producing i386 cloud-images > * stop producing i386 ubuntu-desktop.iso > * stop producing i386 ubuntu-server.iso > > 18.10+: > * Stop providing i386 port > * Run legacy i386 only application in snaps / containers / virtual machines > > Or some other variation of above things and/or adjusted timelines. > What do you think is appropriate? Can we survey and/or somehow > validate if above would be appropriate or needs to be extended or can > be shortened? > > The key point here is lack of upstream software support and upstream > security support on i386, rather than actual hardware being out of > stock and/or old. > > In essence this would mean April 2021 as the sunset for i386 as the > host/base OS architecture. And April 2023 to run legacy i386 > applications with security support. > > Regards, > > Dimitri. > > > On 2 February 2016 at 02:12, Bryan Quigley > wrote: > > The plan from the session we did over a year ago was: > > "Specifically the Ubuntu (x86_32) desktop CD will be moved to cdimage > > around opening of 16.10". The argument is that it was easy to build > > the CD and it was cheap to do. It would be a community build that > > wouldn't be promoted on the Ubuntu website or officially tested. > >I think we could drop Ubuntu desktop, server and cloud images tomorrow > > It doesn't make sense to stop building the CD unless: > > * We make the unity packages x86_64 bit only (what's the point in > > having less easy to test latest 32-b
Re: Ubuntu Desktop on i386
On Tue, Feb 2, 2016 at 1:28 PM, Dimitri John Ledkov wrote: > Hi, > > could you please drop the HWE enablement stack out of this? Hmm.. Let me make it clearer and drop a lot of it. > The cost of: testing, validation, release, and bandwidth to mirror it > is IMHO large. And costs more than the benefit it will provide. Agreed. > > On 2 February 2016 at 17:26, Bryan Quigley > wrote: >>> Kernel support is a separate vector. E.g. in Debian it is common to >>> install 32-bit userspace with the 64-bit kernel. Thus using all the >>> CPU/kernel features, access all the memory, yet have lower memory >>> utilisation. >> >> Right, but depending on what we decide it will also impact how tested >> the HWE stack is on Unity. Say we stop building the x86_32 image >> starting with 16.10. Would backporting the x86_32 bit kernel from >> 16.10 to 16.04.2 HWE release still happen? >> > > Out of scope for this thread. I disagree.. .let me reprase. If we build Ubuntu 16.04 LTS x86_32 Desktop image will we update it with the HWE stack from 16.10/17.04/17.10/18.04 at the point releases (16.04.2) like usual? I'm not saying that other desktops (Like Kubuntu, and Unity x86_64) will still get the HWE like normal. Just will we respin the 32-bit Unity CD? >>> My argument for dropping .iso, but keeping the packages/archive is as >>> follows: >>> >>> * we would like to support upgrades, for those that have 32 bit install >>> >>> * but we would like to prevent any new installations >> >> I just want to prevent further bit root for those upgrade users. >> There will be even less people testing those now, so I do think we >> need a plan to eventually remove Unity from the archive and maybe >> migrate those users to another DE? (Unity8 seems to be doing x86_32 >> releases? the obvious choice for me would be Xubuntu/Mate/Lubuntu but >> we don't need where to move today) >> > > No need to provide upgrade path. The hardware will simply EOL. What do you mean by that exactly? Is this with us eventually dropping Unity7 from archive? We still need to take some action even if it's just saying.. Sorry Ubuntu x86_32 with Unity can't be upgraded any further. But then I don't see the harm in saying click here to install Desktop Environment X. >>> >>> * because any new installation is amd64 capable, or such is the Ubuntu >>> Desktop ISO installer requirement for 16.04 LTS >>> >>> * reduce releases.ubuntu.com mirror costs by about a third >>> >>> Otherwise, all survey results will remain constant. >>> >>> Building images is cheap, however I do not believe we can actually >>> adequately support i386 ones for ubuntu desktop: >>> >>> * there is no i386-only certified hardware >>> * image manual testing has a cost >>> * no ubuntu developers use them =) >>> >>> Could we start the sunset period with removing flavour dropdown from >>> the ubuntu desktop download pages for 16.04? (But keep the i386 images >>> on releases.ubuntu.com?) >> I'm 100% for that. Still supported (although not certified), but you >> really have to know you want to get it. >> >> So maybe a basic plan like: >> 1. Announce that Ubuntu 16.04 LTS will be the last officially >> supported release of Unity. Keep it on releases.u.c but remove from >> main download page. Also announce that x86_32-bit Ubuntu (server >> too?) won't be getting HWE? > > server is out of scope for this discussion, HWE is out of scope. I > don't think we ever announce any ubuntu.com website changes. And the > website has links to reach to reach the releases.u.c and cdimage.u.c > anyway. I meant to announce in the schedule/release notes the plan for the x86_32 release. Last LTS with x86_32 Unity. Make it clear that if you go with it, you might not have an upgrade path to the next LTS. > >> 2. Drop to cdimage for 16.10 with not tested/supported caveat >> (continue based on usage numbers) > > Ack. > >> 3. For 17.04 evaluate migration options and consider dropping Unity7 >> from x86_32 archive > > I'd rather say, no action. Reinstall is the best way to "upgrade" > those machines to a different ubuntu flavor, or like buy a new > hardware. So is there a point in not just dropping x86_32 Unity from archive in 16.10? If we drop Unity7 from the archive we aren't going to produce the CD anymore. Kind regards, Bryan -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Desktop on i386
> Kernel support is a separate vector. E.g. in Debian it is common to > install 32-bit userspace with the 64-bit kernel. Thus using all the > CPU/kernel features, access all the memory, yet have lower memory > utilisation. Right, but depending on what we decide it will also impact how tested the HWE stack is on Unity. Say we stop building the x86_32 image starting with 16.10. Would backporting the x86_32 bit kernel from 16.10 to 16.04.2 HWE release still happen? >> I'm also happy to revisit my survey [2] and see where people are today. > > I'm not sure it's about where people are, but rather where we want people to > be. I mean I want us to just drop 32-bit kernels and images entirely and just keep 32 bit compat libraries. But I also want to give lots of notice so the soonest I'd want to that would be after 18.04 at this point. > My argument for dropping .iso, but keeping the packages/archive is as follows: > > * we would like to support upgrades, for those that have 32 bit install > > * but we would like to prevent any new installations I just want to prevent further bit root for those upgrade users. There will be even less people testing those now, so I do think we need a plan to eventually remove Unity from the archive and maybe migrate those users to another DE? (Unity8 seems to be doing x86_32 releases? the obvious choice for me would be Xubuntu/Mate/Lubuntu but we don't need where to move today) > > * because any new installation is amd64 capable, or such is the Ubuntu > Desktop ISO installer requirement for 16.04 LTS > > * reduce releases.ubuntu.com mirror costs by about a third > > Otherwise, all survey results will remain constant. > > Building images is cheap, however I do not believe we can actually > adequately support i386 ones for ubuntu desktop: > > * there is no i386-only certified hardware > * image manual testing has a cost > * no ubuntu developers use them =) > > Could we start the sunset period with removing flavour dropdown from > the ubuntu desktop download pages for 16.04? (But keep the i386 images > on releases.ubuntu.com?) I'm 100% for that. Still supported (although not certified), but you really have to know you want to get it. So maybe a basic plan like: 1. Announce that Ubuntu 16.04 LTS will be the last officially supported release of Unity. Keep it on releases.u.c but remove from main download page. Also announce that x86_32-bit Ubuntu (server too?) won't be getting HWE? 2. Drop to cdimage for 16.10 with not tested/supported caveat (continue based on usage numbers) 3. For 17.04 evaluate migration options and consider dropping Unity7 from x86_32 archive 4. For 18.04 have migration options well tested for 16.04 upgraders. Kind regards, Bryan -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Desktop on i386
On Tue, Feb 2, 2016 at 6:27 AM, Jean-Baptiste Lallement wrote: > Hi, > > On 02/02/2016 08:58, Stefan Bader wrote: >>> >>> >My guess is that: all currently shipped hardware, with enough support >>> >to run full Unity (7) Desktop, is amd64. Tested with amd64 kernel, and >>> >amd64 graphics drivers. And hardware validation is done on amd64 too. >>> > >>> >In 2016, people with i386-only hardware are unlikely to be capable to >>> >run Unity 7 Desktop, and probably run other Ubuntu variants. I guess >>> >there are some accidental i386 users, e.g. those that have installed >>> >i386 variant on amd64 hardware. >> >> Just wondering whether you considered netbooks here. Not that old (maybe >> 6y?) >> and at least the two specimens I would have around are early Atoms (i386 >> only) >> but with (also early) i915 Intel graphics. They used to be reasonably >> accelerated to cope. Not sure about unity 7. But maybe some reason to >> allow at >> least for 16.04 some i386 iso (by 18.04 the problem might be resolved >> through >> the crappy life-span recent hw seems to have)... > > For such hardware, 16.04 LTS is supported until Apr. 2019 (the notebook will > be 9y old) or if you want to use a more recent release probably a > lightweight flavour of Ubuntu would be a good alternative. Unless I missed something the Ubuntu 16.04 LTS Desktop release will be supported until Apr. 2021. (so the notebook would be 11y old). > > From a QA point of view, supporting a Desktop i386 LTS for 5 years means > testing 1 release and 4 or 5 point releases. Testing a release involves > maintaining automated tests of the installer (read manual review of the > failures), and manual testing of the images. I don't think it is worth the > cost if the target is the hardware you mention. > I'd rather beef up the test suite to cover common multiarch i386 scenarios. > > JB. > > -- > Jean-Baptiste Lallement > irc: jibel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Desktop on i386
The plan from the session we did over a year ago was: "Specifically the Ubuntu (x86_32) desktop CD will be moved to cdimage around opening of 16.10". The argument is that it was easy to build the CD and it was cheap to do. It would be a community build that wouldn't be promoted on the Ubuntu website or officially tested. It doesn't make sense to stop building the CD unless: * We make the unity packages x86_64 bit only (what's the point in having less easy to test latest 32-bit unity packages?) * We drop x86_32 bit kernel support (guessing not something to consider until after 18.04?) I think it also makes sense to see if other derivatives want to go x86_64-bit only like maybe Kubuntu (like I believe project Neon targets just 64 bit). At some point we are going to want drop x86_32 kernel support and just have 32-bit compatibility libraries, but I don't know when that makes sense. Also, does Valve Steam product rely on i386 multiarch binaries? Yes, it does, but it also downloads it's own Steam runtime with it's own libraries. And Netflix - does that run on amd64-only without i386 multiarch? I believe that runs completely with libs if you use Google Chrome. Oh, and also Google Chrome is dropping Linux x86_32 bit support. I'm also happy to revisit my survey [2] and see where people are today. Thanks for bringing this up again! Bryan [1] https://blueprints.launchpad.net/ubuntu/+spec/development-1411-drop-x86-32 [2] https://bryanquigley.com/crazy-ideas/32-bit-usage-survey-results [3] http://summit.ubuntu.com/uos-1411/meeting/22353/when-should-we-stop-making-32-bit-images/ On Mon, Feb 1, 2016 at 5:14 PM, Dimitri John Ledkov wrote: > Hello, > > Ubuntu has an i386 port which is fully supported. > > There a bunch of 3rd party applications that rely on the Multi-Arch > technology to support/use i386 binaries on amd64 (e.g. Skype from the > partner archive). BTW, can we ask Microsoft to publish native amd64 > binaries, rather than those that rely on multi-arch i386? Also, does > Valve Steam product rely on i386 multiarch binaries? or is it fully > amd64? (and e.g. downloads/bundles/ships any required i386 binaries > that it needs)? And Netflix - does that run on amd64-only without i386 > multiarch? > > However, it seems to me that this is done specifically on otherwise > full amd64 installations. > > My guess is that: all currently shipped hardware, with enough support > to run full Unity (7) Desktop, is amd64. Tested with amd64 kernel, and > amd64 graphics drivers. And hardware validation is done on amd64 too. > > In 2016, people with i386-only hardware are unlikely to be capable to > run Unity 7 Desktop, and probably run other Ubuntu variants. I guess > there are some accidental i386 users, e.g. those that have installed > i386 variant on amd64 hardware. > > Does it still make sense to build ubuntu-desktop-i386.iso? Validate > it? Test it on amd64 hardware? Ship it? > > To me this seems like a futile effort. Imho, we should only test the > relevant multiarch i386 pieces that are there to support 3rd-party, > i386-only apps on amd64 desktop. > > This is specifically about building, validating and shipping > ubuntu-desktop-i386.iso, specifically for the Ubuntu Desktop flavour. > Which I am suggesting should be dropped. Without any other changes to > the archive and/or publishing i386 binaries. > > -- > Regards, > > Dimitri. > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: ntp by default on servers in Vivid
> Would it be acceptable to move ntpdate to the desktop-common seed or something? Could we just switch everything over to ntp? Is their a downside to this I'm missing? Thanks, Bryan On Wed, Oct 22, 2014 at 9:51 AM, Robie Basak wrote: > I'd like to seed ntp in both server and cloud-image in Vivid. Servers > should maintain the correct time by default. Please make any objections > now. > > Right now, ntpdate is seeded in minimal. It makes little sense to have > both ntpdate and ntp installed. > > So is there some mechanism I can use to have ntpdate not appear in > server and cloud images? I think we need to move ntpdate out of minimal > for this. Would it be acceptable to move ntpdate to the desktop-common > seed or something? > > To try and confirm that this is sensible for all use cases, here's a > brainstromed list. It seems to me that the only downside is a little > extra used space in the LXC case. > > * "Traditional" bare metal server installation from server ISO > > It makes sense to be running ntp here. > > * MAAS-deployed server using d-i > > It makes sense to be running ntp here. Additionally, MAAS can choose to > configure the system to point at a MAAS-managed NTP server. > > * MAAS-deployed server using curtin > > It makes sense to be running ntp here. Additionally, MAAS can choose to > configure the system to point at a MAAS-managed NTP server. > > * Hand (or other tool) -deployed VM using a cloud image > > It makes sense to be running ntp here[3]. > > * Hand (or other tool) -deployed VM using d-i or a debootstrapped image > > It makes sense to be running ntp here[3]. > > * Juju-deployed VM using a cloud image > > It makes sense to be running ntp here[3]. There may be some interference > with existing charms. When these charms are updated to Vivid (or to X), > then they can start assuming that ntp is already available. A > hypothetical "ntp" subordinate charm could be used in cases where some > other NTP server should be used and the deployer wants to manage it more > directly via a relation; in this case, the subordinate charm could just > rewrite /etc/ntp.conf to change the default accordingtly. > > * Hand (or other tool) -deployed LXC using a cloud image > > It probably doesn't make sense to run ntp here. We could amend the ntp > init script to skip startup when in a container by default. > > * Hand (or other tool) -deployed LXC using a debootstrapped image > > It probably doesn't make sense to run ntp here. We could amend the ntp > init script to skip startup when in a container by default. > > * Juju-deployed LXC using a cloud image > > It probably doesn't make sense to run ntp here. We could amend the ntp > init script to skip startup when in a container by default. > > Are there any use cases I've missed here? > > Previous discussions: > > [1] https://lists.ubuntu.com/archives/ubuntu-server/2013-April/006556.html > [2] https://lists.ubuntu.com/archives/ubuntu-devel/2013-December/037874.html > [3] > https://help.ubuntu.com/community/KVM/FAQ#Should_NTP_be_used_for_time_synchronisation.3F > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
