Re: Adjusting what fstypes df displays
I agree with being able to customize this and Bryce's solution is easy to work with (either profile.d or a df config in /etc). We use tmpfs to create ramdisks on the fly as part of our video analytics solution (megh.com), and need to monitor the tmpfs we create. Tobin On Fri, May 29, 2020 at 7:03 AM Robie Basak wrote: > +1 for Bryce's approach. > > On Fri, May 29, 2020 at 10:56:34AM -0300, Rafael David Tinoco wrote: > > Perhaps this environment variable should be set by snapd package ? > > I think this could be surprising - because we would be hiding all > squashfs filesystems from df, not just snapd ones. I think it would be > cleaner to consider that users don't generally want to see squashfs > stuff in df output by default anyway, and so hide it Ubuntu-wide. > > I'm less sure about tmpfs. I can think of occasions where I have wanted > to see tmpfs usage (since it can run out, and has run out on me before). > But that's perhaps too much of a specialist case, and so I think it's > also OK to hide tmpfs by default from df on Ubuntu. > -- > 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've been following this thread for a while, and have some questions. Are we talking about dropping Ubuntu x86 images or i386 packages from the repo? If the former, I don't see an issue here, as the subs (Lubuntu, core, etc) can still build release images. But if Ubuntu is dropping i386 packages, that brings up a huge issue with software compatibility, at a very bad time (at least for me and the projects I support). I work with FPGA accelerators, both at Intel and for a startup. A majority of the tools we use (Quartus, Modelsim in particular) only support 32bit (and very old at that). The companies developing these tools are all too happy to ONLY support Redhat Enterprise 6 (and barely RHEL 7), and so far refuse to budge. A wide variety of our customer base prefer Ubuntu and have their infrastructure geared towards this, so I have had to be very creative in getting everything working for them (adding 32bit support, swapping out the linker that ships with these tools, etc). If Ubuntu drops i386 all together, this can have a major impact on the whole FPGAaaS model. Outside of that, I also have a large collection of older software (games mainly) that are still fun, but also 32bit only. Dropping i386 would render them entirely useless, or force people away from Ubuntu. The real issue is the costs of maintainership. I know for a fact that Ubuntu uses automation for everything in disposable VMs, so the overhead is minimal (far less than ArmHF or Armel). That leaves the FTBFS issues, which if it is in Universe and obscure (Haskell), can safely be ignored or reported upstream. Main should be very well supported on all architectures the packages upstream were designed for, so that should minimize issues. This leaves image and installer testing. My vote is to drop the images (except core as it is very useful for embedded projects which Intel still sells 32bit only chips for IoT. This at least keeps Ubuntu as a prime development environment for these devices. This is just my opinion based on what I see in the market outside of desktops, and not representative of the companies I work for. Tobin Davis On Sat, May 12, 2018 at 8:31 AM, Dimitri John Ledkov wrote: > On 11 May 2018 at 16:32, 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. > > > > "Consume more resources" is a bit vague. Environmental impact is > correlated with performance-per-watt measurements. That improves with > the newer generation of lithography, better support of newer and more > efficient instruction sets, ability to dynamically clock-down cpu > cores etc. Thus newer generation CPUs are better performance wise on > environment front. Depending on how much newer it is, it may even make > economic sense to upgrade old hardware. Unless one operates complete > off-grid, on self-harvested renewable energy, e.g. > https://identi.ca/joeyh/note/mSMKXM3gSluoeC5mP1xIsw > > An example of this is compa
Re: Should Ubuntu systemd journal logs be persistent by default?
I fully understand the need to minimize redundancy and performance degradation that this incurs, which you don't want on every desktop or embedded system. But for production or test servers, this could prove invaluable (I work in a high volume system validation lab where system crashes are the norm). My suggestion (at least for existing releases) is to document the process for enabling persistent logging from the commandline, as this will allow sysadmins to easily implement it for post reboot reviews on a selective basis. Having it documented in a central location that is easily searched in google helps new sysadmins that would otherwise have to wade through tons of documentation and google searches of irrelevant information (sorry, not volunteering for this - too busy). For 18.04, maybe a separate package or a package install prompt during installation (similar to unattended-updates) could be implemented. Just my suggestion. Tobin Davis, Lab Engineer Intel Corp On Tue, Nov 7, 2017 at 12:11 PM, Mark Stosberg wrote: > Some time around the 15.04 release, a policy change was made to quit > making some logging persistent by default. > > A number of users did not realize there was a policy change until they > went to debug something that happened on a previous boot, only to find the > logs were missing. Some of these user responses are captured in the bug > report below [1], which prompted this policy discussion. > > The change was made because of the introduction of systemd and the > introduction of the `systemd journal` in addition to the existing `rsyslog`. > > The concern about making the systemd journal persistent by default is that > some logs could end up duplicated between the systemd journald and rsyslog, > along with disk space and performance concerns of the additional logging. > > On the other hand, having systemd journal logs persist seems to be a safer > option: It a malicious app could cause or entice a reboot, it could erase > logs of it's earlier activity. Also, deleting key logs at shutdown breaks a > decades-log precedent of system logs persisting through reboots. > > The compromise option seems to be make the systemd journal persistent by > default, but minimize the amount of logging that is sent to both rsyslog > and systemd to mitigate resource considerations of duplicate logging. > > So the policy question here is: *should the systemd journal be persistent > by default?* > > Mark > > https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1618188 > > > -- > 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: Ubuntu Server seeded package review
On Fri, 2013-12-06 at 11:43 -0800, Seth Arnold wrote: > On Thu, Dec 05, 2013 at 05:15:41PM -0600, C de-Avillez wrote: > > Although I am probably hammering a rather cold iron, I still fail to > > understand why ntp is not installed by default. I would expect precise > > timekeeping to be something important on a server (instead of allowing > > the time to drift slowly). > > I would like to hear from An Expert if ntpd, ntpdate, ptpd, etc., are > reasonable things to install in virtual machine guest environments. > > My personal suspicion is that when a virtual machine host runs ntpd, > guests should not run ntpd, since two daemons attempting to skew the > clock sounds like a recipe for highly chaotic behavior. ntpdate would > be alright since it does not attempt to manage clock skew. ptpd no idea. > > When the virtual machine host does not run ntpd, I suspect ntpd, ntpdate, > ptpd, are all fine things to run in the guests. > > I'd love to know for certain what the best practices are. It might > influence the default package installs. > > Thanks My personal experience with a VM server running 12.04 and multiple VMs with various Linux and Windows distros is that while the server is running ntpd, the guests don't appear to get updated correctly from the host. Some of the systems that I have taken the time to point ntpd to an internal server (we're behind a corporate firewall) are ok, the others tend to get skewed after a bit. No idea why. -- -- Tobin Davis Yes, we will be going to OSI, Mars, and Pluto, but not necessarily in that order. -- George Michaelson -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Let's Discuss Interim Releases (and a Rolling Release)
On Fri, 2013-03-01 at 16:52 +, Colin Watson wrote: > On Thu, Feb 28, 2013 at 12:12:34PM -0500, Barry Warsaw wrote: > > Long gone are the days where a `apt-get upgrade` has broken my system > > (knock on wood) and while I do inspect dist-upgrades a little more > > carefully, they are usually pretty reliable too. > > FWIW, I have come to believe that nobody should use 'apt-get upgrade' as > a general rule. In particular, since it tries its best to install as > much as it can under the constraint that it never installs new packages > or removes installed ones, it will carry merrily on without installing > any new Recommends introduced by the upgrade set, and you will never > hear about them again unless some other package starts recommending the > same target packages. > > Just using 'apt-get dist-upgrade' all the time, or something with closer > semantics to that, is better. > > -- > Colin Watson [cjwat...@ubuntu.com] > Oh, then you've fixed the issue where dist-upgrade removes packages due to unmet dependencies (aka pool churn)? dist-upgrade should only be used within a release, not during development (your words a few years ago). I quit tracking the Ubuntu daily builds shortly after 12.04 release (Canonical people know why). Have the issues of missing dependencies been resolved during library update induced pool churn? Have the issues of systems not booting due to lack of 3D driver support been addressed? These are serious issues, and frankly I haven't seen any progress to indicate otherwise. Tobin Davis "One Architecture, One OS" also translates as "One Egg, One Basket". -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
Thought I would chime in with my thoughts on freezes, snapshot testing, and QA in general. Freezes: When I was testing the Arm images, there were times when I would go for weeks without an image. And if I remember correctly, there was a period during Natty where there were no images between milestones due to pool skew. And there were image specific changes being made at the time (jasper-initramfs, Ubiquity/oem-config, etc). When those changes can't be tested without an image, failures become critical at milestone, causing a lot of needless stress. Manual QA: Having been in a QA role for most of my career in computers (+25 years), I can site areas where automated QA can and will fail. Sure, repetitive tests can be automated, especially server stacks and background libraries. But how do you automate testing a GUI for usability (Evolution STILL has option windows that flow past the bottom of my netbook screen). Plus there are tests that find the oddball combination that most developers don't think users will select (enabling autologin & encrypted home directory during install was found this way). When developing automation scripts for tests, they really should be designed to test on all platforms, not just simulated/virtualized environments. Otherwise others have to constantly reinvent the wheel to run the same test on systems that don't support that test environment. Snapshot retention: I set up my own internal mirror so that I could keep daily images between milestones. This way if I missed something during daily testing and we needed to determine how far back it went, I had a complete image history to go back to (Mono/Banshee in Oneiric). This also helped to determine if one package or a combination of package updates caused issues. As to testing 15 arm images during milestones, my secret was to take a daily image for one platform (panda) and focus on it over a period of 2-3 days, testing everything. Most bugs in applications there were the same on all arm platforms. That left hardware specific testing on other platforms to be done only when testing kernel/xorg updates, or (in the case of Mono not supporting SMP on arm) reproducing a bug found on the main test environment. I would also try to reproduce the bug on x86/amd64 to determine if the bug was arch specific. Often times, an application bug found on the panda would also be found on other architectures. While I no longer have the time to test Ubuntu images, I am saddened by the failures I do see on a daily basis on the LTS release (anyone try to run a remote desktop lately using rdesktop?). These issues should have been found prior to release. -- -- Tobin Davis The "cutting edge" is getting rather dull. -- Andy Purshottam -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: vim on DVD
On Wed, 2011-12-07 at 23:25 +, Colin Watson wrote: > On Wed, Dec 07, 2011 at 08:39:19PM +0100, Benjamin Drung wrote: > > it would be nice if we would have the full "vim" binary package > > installed on the DVD version of Ubuntu. It's not to huge for the DVD > > version and I often have to install it when using the live CD for more > > than a few minutes. > > Sounds reasonable to me. Not having it there seems like an oversight to > me. (I've learned to get by with vim-tiny, but boy is it irritating to > not have syntax highlighting easily to hand.) > > -- > Colin Watson [cjwat...@ubuntu.com] > Not to mention the cursor movement keys in vim-tiny are wonky. Pressing should send you to the end of the line, not change the caps of the current character (just to name 1 major irritation of mine). -- Tobin Davis There is no grief which time does not lessen and soften. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UDS-O About onscreen keyboard - display manager dwelling
;triaging bugs there, and looking for anything to sponsor/fix. > > > > * 742857 > > * non-translated help documentation tweaks, reviewed, committed, > >uploaded > > * 678421 > > * reviewed code back and forth with developer in IRC > > * needs-fixing, gave him a cleaner/simpler function to use > > * will revisit when he updates merge proposal > > * 717166 > > * eucalyptus task invalid, but looks like there is a fix required > >against isc-dhcp > > * turns out this was fixed elsewhere, in another bug not linked to > >this one > > * 747090 > > * updated triage correctly > > * 732759 > > * FFe was granted on 3/15 > > * Checked with developer, this was already uploaded and in Natty, > >bug just wasn't closed > > * Marked fix-released > > * 716689 > > * Researched and confirmed fix has already landed in Natty > > * Marked fix-released > > * 610597 > > * eCryptfs related bug, talked to assigned dev (jjohansen) > > * was milestoned against b2, but not practical to fix in that > >timeframe, so updated milestone to ubuntu-later > > * 726572 > > * added cloud-initramfs-tools to uec seed > > * processed MIR archive promotion > > * 751807, 752910 > > * likewise bug fixes > > * comment added to 751807, as he's using /etc/init.d/* in a > >postinst, which is not recommended, but is consistent with ~30 other > >calls in the package's maintainer scripts; I directed the patch > >author to the Debian Policy Manual section 9.3.3: > > * http://www.debian.org/doc/debian-policy/ch-opersys.html > > * otherwise, approved and uploaded > > * 757540 > > * handled at ScottK's request > > * was kind of a pain, as the developer submitted a tarball of their > >debian packaging directory, rather than a debdiff or a merge proposal > > * also, I had to grab the upstream release tarball, extract it, > >rename the contained directory, and repack it > > * imported dsc to bzr packaging branch and uploaded > > > >-- > >:-Dustin > > > >Dustin Kirkland > >Ubuntu Core Developer > > > > > > > >-- > > > >Message: 6 > >Date: Mon, 11 Apr 2011 14:34:49 -0400 > >From: Elliot Murphy > >To: Dustin Kirkland > >Cc: James Page , James Troup > > , ubuntu-devel@lists.ubuntu.com > >Subject: Re: Using something better than Gobby for session notes at > > UDS > >Message-ID: > >Content-Type: text/plain; charset=UTF-8 > > > >On Mon, Apr 11, 2011 at 11:28 AM, Dustin Kirkland > > >wrote: > >> Looks like Elliot Murphy owns the etherpad project in Launchpad -- > we > >> should probably hook up this team/project together. ?Elliot -- I > also > >> added you as an administrator of team ~etherpad. ?Perhaps you can > >> transfer ownership of project etherpad to team ~etherpad? > > > >Yep, I just happened to be the one who registered a Launchpad code > >import of etherpad back when it was released as open source, the > >Launchpad project is only used for that purpose AFAIK. I've just > >changed the administrator/owner of the project to be team ~etherpad. > >-- > >Elliot Murphy | https://launchpad.net/~statik/ > > > > > > > >-- > > > >Message: 7 > >Date: Mon, 11 Apr 2011 15:46:25 -0700 > >From: Scott Ritchie > >To: Martin Owens > >Cc: ubuntu-desk...@lists.ubuntu.com, ubuntu-devel@lists.ubuntu.com > >Subject: Re: Default Desktop Experience for 11.04 > >Message-ID: <4da384c1.5050...@open-vote.org> > >Content-Type: text/plain; charset=UTF-8 > > > >On 04/11/2011 06:26 AM, Martin Owens wrote: > >> On Mon, 2011-04-11 at 04:22 -0700, Scott Ritchie wrote: > >>> I think it's the height of arrogance for us to tell a user that > we're > >>> going to deliberately break his application because it wasn't > updated > >>> to > >>> use our new indicator library. > >> > >> We tell users all the time that we've broken their windows > application > >> by not implementing any windows apis. No guarantees. > >> > > > >The difference here is their application worked on a previous version > of > >Ubuntu. Regressions for current users are worse than other kinds of > >problems. > > > >> So, do we guarantee completely that gnome 2.x apps will function in > >> Unity? If we do, then we should support the entire API (somehow), > >> otherwise we be honest and say we support a major subset which may > >mean > >> your app won't work completely. > >> > >> It can hardly be arrogance so long as we're honest about what we > >> support. > >> > >> Martin Owens > >> > > > >There's a difference between supporting something and not > intentionally > >breaking it. > > > > > > > >-- > > > >Message: 8 > >Date: Tue, 12 Apr 2011 01:01:16 -0500 > >From: Kate Stewart > >To: ubuntu-rele...@lists.ubuntu.com > >Cc: ubuntu...@lists.ubuntu.com, ubuntu-devel@lists.ubuntu.com > >Subject: 11.10 Ubuntu Release - Call for Topics > >Message-ID: <1302588076.1985.1007.camel@veni> > >Content-Type: text/plain; charset="UTF-8" > > > >Hi all, > > > > As we go into the last phases of releasing Natty, please keep a set > >of side notes on things you would like to see improved in our release > >processes for Oneiric (and beyond). > > > > We will have a release feedback session again, early in UDS, to go > >over what worked well, and what can be improved for Oneiric. > >However there may be some topics that are wider in scope than that > >one feedback session. > > > >Looking at what some of the other teams are doing, a revised version > of > >their process should work: > > > >1. Send a call for topics the Ubuntu community (this is it) > > > >2. Have an exchange over irc and email to discuss the requirements in > >depth > > > >3. Produce a resulting UDS plan which summarizes the topics going > >into UDS, and feeds into blueprints > > > >4. Provide a final roadmap post-UDS > > > > > >Here is the schedule with some details. > > > >= April 12th: Request for Topics = > >This email is the request for topics. Please send topics that you > would > >like the Ubuntu Release team to consider for this cycle to the > >**ubuntu-release** mailing list [1] with > >"[Oneiric-Release-Topic]" in the subject line. > > > >These are not specific requirements, but high-level ideas or > concepts. > > > >Some areas to consider: > > * Development Release Processes (freezes, testing, etc.) > > * Stable Release Updates (proposed, updates, testing, etc.) > > * Long Term Support Release Processes (testing, freezes, etc.) > > * Inter team dependencies ( Toolchain freeze, etc. ;) ) > > * End of Life Processes (advance notice, transitions ) > > * Release support infrastructure (archive, builders, etc.) > > > >= April 12th through April 19th - Requirements discussions held = > >We will discuss topics in the ubuntu-release irc channel and > >ubuntu-release mailing list. The goal will be to identify and > >document specific requirements. > > > >= April 19th through April 28th - Getty Natty out! = > > > >= May 2nd - UDS Oneiric Topics Review = > >A couple of days before UDS Oneiric we will present a plan. This is > >essentially a review of what topics we have planned for further > >discussion at UDS. > > > >= May 9th through May 13th - UDS = > > > >= Approximately two weeks post UDS - Oneiric Plan Review = > >About two weeks after UDS, we will revise the UDS Oneiric Plan to > >capture what was actually decided as the plan of record at UDS, and > >present that information. This info will feed into the Ubuntu Release > >planning for Oneiric and beyond > > > >Thanks, > >-Kate > > > >[1] https://lists.ubuntu.com/mailman/listinfo/ubuntu-release > > > > > > > > > > > > > >-- > > > >-- > >ubuntu-devel mailing list > >ubuntu-devel@lists.ubuntu.com > >Modify settings or unsubscribe at: > >https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > > > >End of ubuntu-devel Digest, Vol 80, Issue 20 > > > > > > > > > >-- > > > >-- > >ubuntu-devel mailing list > >ubuntu-devel@lists.ubuntu.com > >Modify settings or unsubscribe at: > >https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > > > >End of ubuntu-devel Digest, Vol 81, Issue 7 > >*** > > > > > Free POP3 Email from www.gawab.com > Sign up NOW and get your account @gawab.com!! -- Tobin Davis "Who cares if it doesn't do anything? It was made with our new Triple-Iso-Bifurcated-Krypton-Gate-MOS process ..." -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: New Date/Time for the ARM IRC Meeting
On Tue, 2010-12-07 at 11:00 -0200, Ricardo Salveti wrote: > Hi, > > Just to inform that from now on the ARM IRC Meeting will happen on new > day and time, changed from the usual Tuesday 13:00 UTC. > > The new meeting time is now Thursday at 15:00 UTC, as pointed out by > our latest meeting wiki page: > https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20101130 > > We'll keep sending the meeting reminder, and a new one should appear > tomorrow or thursday, before the meeting. > > Thank you, > -- > Ricardo Salveti de Araujo > Due to conflicting obligations and holiday travels, this meeting will be canceled until next week, December 16, 2010. Sorry for any inconvenience. If anyone has pressing issues that they would liked to have brought up at the meeting, please feel free to update the meeting wiki page at: https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20101209 Thanks, -- Tobin Davis Systems programmers are the high priests of a low cult. -- R. S. Barton -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
