On Sunday, June 28, 2020 5:14:14 PM MST Gerald Henriksen wrote:
> On Sun, 28 Jun 2020 09:59:52 -0700, you wrote:
>
>
> >Has that actually been explored? How does Canonical get around the legal
> >issues with OpenZFS' licensing?
>
>
> For a start they aren't a US company, and unlike Red Hat the
On Sunday, June 28, 2020 11:31:15 PM MST Mark Otaris wrote:
> The master branch for cp now defaults to copy-on-write on filesystems
> that support reflinks, which should make copies more efficient if
> Fedora starts using btrfs:
> https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=25725f9d4
On Sunday, June 28, 2020 7:51:40 PM MST Matthew Miller wrote:
> On Sun, Jun 28, 2020 at 10:32:34AM -0700, John M. Harris Jr wrote:
>
> > > Fine :) https://github.com/gwsw/less/issues/72
> >
> > See Markus Larsson's comment on this above...
>
>
> Yeah, but as Michael points out, that doesn't rea
The master branch for cp now defaults to copy-on-write on filesystems
that support reflinks, which should make copies more efficient if
Fedora starts using btrfs:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=25725f9d41735d176d73a757430739fb71c7d043.
Dolphin and KIO also seem like the
On Sunday, June 28, 2020 5:37:08 PM MST Chris Adams wrote:
> Once upon a time, John M. Harris Jr said:
>
> > XFS proved to be troublesome, and still is up to the latest of RHEL7. It's
> > not uncommon to have to run xfs_repair on smaller XFS partitions,
> > especially / boot. I'm not sure if btr
On Sunday, June 28, 2020 6:06:06 PM MST Michael Catanzaro wrote:
> 3. Users should not be expected to customize anything or use the
> command line, ever, period. So for the purposes of figuring out what's
> causing this performance issue, it sounds very useful to test different
> mount options. Bu
Sorry for duplicate, it was already answered.
On 6/29/20 7:10 AM, Zdenek Dohnal wrote:
> Spoiler alert :)
>
> It already does.
>
> On 6/26/20 3:41 PM, Jaroslav Skarvada wrote:
>> - Original Message -
>>> Adam Williamson < adamw...@fedoraproject.org > 于 2020年6月26日周五 上午9:32写道：
>>>
>>>
>>> On
Spoiler alert :)
It already does.
On 6/26/20 3:41 PM, Jaroslav Skarvada wrote:
>
> - Original Message -
>>
>> Adam Williamson < adamw...@fedoraproject.org > 于 2020年6月26日周五 上午9:32写道：
>>
>>
>> On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote:
>>> What about to provide a prompt to the user
On 6/26/20 2:22 PM, Przemek Klosowski via devel wrote:
Even though technically dnf system-upgrade can --download-dir to a
location off / it doesn't seem to work with the actual upgrade, so the
only way I know is to delete largest packages (flightGear*, piglit*,
KiCAD*, ...) and reinstall them a
> I'd like to propose a few guidelines:
>
> 1. If btrfs causes noticeable performance issues for users, that's not
> OK. It's understood and expected that it might be slower at many
> workloads, but if the difference is large enough that users notice a
> significant regression in desktop respon
On Sun, Jun 28, 2020 at 10:32:34AM -0700, John M. Harris Jr wrote:
> > Fine :) https://github.com/gwsw/less/issues/72
> See Markus Larsson's comment on this above...
Yeah, but as Michael points out, that doesn't really apply: it takes up
literally zero additional screen space.
--
Matthew Miller
Hi folks! Sorry for the late notice, forgot I didn't send this out on
Friday. I know it's been a while since we met, but I'm proposing we
cancel the QA meeting for Monday, as I still don't have anything really
for the agenda. Everything seems to be moving along smoothly, Rawhide
is working fairly w
On Sun, Jun 28, 2020 at 07:28:34PM +0100, Peter Robinson wrote:
> Technically yes, see the fedora-release-* for one of the Editions, all
> the spins should have the equivalent now, not sure if there's a FESCo
> policy on it though.
The Council talked about this at our meeting in Minneapolis in 201
> You didn't make a mistake. Pretty sure it's a blocker bug too so I've
> proposed it as such.
Thank you for doing that, I appreciate it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproje
On Sun, Jun 28, 2020 at 9:07 PM Michael Catanzaro wrote:
>
> On Sun, Jun 28, 2020 at 3:40 pm, Chris Murphy
> wrote:
> > And yeah, how would anyone know all of this? And is it an opportunity
> > for docs (probably) or desktop integration? Detect this workload or
> > ask the user? I'm not sure.
>
>
Already done as seen on the spec file:
https://download.copr.fedorainfracloud.org/results/luya/openshadinglanguage/fedora-rawhide-x86_64/01506931-openshadinglanguage/openshadinglanguage.spec
Yet LLVM-10 still requires C++14.
On 2020-06-28 8:55 a.m., Ian McInerney wrote:
It's failing because OSL
On Sun, Jun 28, 2020 at 3:40 pm, Chris Murphy
wrote:
And yeah, how would anyone know all of this? And is it an opportunity
for docs (probably) or desktop integration? Detect this workload or
ask the user? I'm not sure.
I'd like to propose a few guidelines:
1. If btrfs causes noticeable perfor
Once upon a time, John M. Harris Jr said:
> XFS proved to be troublesome, and still is up to the latest of RHEL7. It's
> not
> uncommon to have to run xfs_repair on smaller XFS partitions, especially /
> boot. I'm not sure if btrfs has the same issue there?
[citation needed]
I haven't run xfs_
On Sun, Jun 28, 2020 at 5:42 PM John M. Harris Jr wrote:
>
> On Sunday, June 28, 2020 6:45:24 PM MST Alexandre de Farias wrote:
> > *snip*
> >
> > At this point, I'm fine with what I have and BTRFS usage would be
> > strictly for testing. Also, is there any reason as to why RHEL went
> > with XFS
On Sun, Jun 28, 2020 at 4:54 PM Alexandre de Farias
wrote:
>
> On Sun, 2020-06-28 at 15:40 -0600, Chris Murphy wrote:
> > On Sun, Jun 28, 2020 at 9:04 AM wrote:
> >
> > > I'm willing to perform further testing. There shouldn't be anything
> > > very special about my workload. I was working mostly
Thanks for the reply Justin, but that doesn't answer my two concerns which
I reposted earlier. I don't believe the questions I asked were
unreasonable for something we're making a distribution default, regardless
of spin, and they shouldn't be hard questions to answer. Everyone knows
that if BTRF
On Sun, 28 Jun 2020 09:59:52 -0700, you wrote:
>Has that actually been explored? How does Canonical get around the legal
>issues with OpenZFS' licensing?
For a start they aren't a US company, and unlike Red Hat they aren't
the same tempting target for a lawsuit.
_
On Sunday, June 28, 2020 6:45:24 PM MST Alexandre de Farias wrote:
> *snip*
>
> At this point, I'm fine with what I have and BTRFS usage would be
> strictly for testing. Also, is there any reason as to why RHEL went
> with XFS as a default and Fedora stayed with ext4? I mean, if it was a
> consciou
On Sun, 2020-06-28 at 15:40 -0600, Chris Murphy wrote:
> On Sun, Jun 28, 2020 at 9:04 AM wrote:
>
> > I'm willing to perform further testing. There shouldn't be anything
> > very special about my workload. I was working mostly with NodeJS 12
> > and React Native. VS Code (I should mention I make
On Sun, Jun 28, 2020 at 3:50 PM Tom Seewald wrote:
>
> > The context of that is: the default when the user does not specify. If
> > the user chooses 'raid1' in the installer, they get 'raid1' for both
> > data and metadata.
> This does not seem to be the case, and from what I can tell Garry experi
On Fri, 26 Jun 2020 13:23:17 -0400, you wrote:
>Heres a thought that I hadn't considered before though, and it might be useful.
>Apple at one point (and still may), shiped iphones without the itunes (or some
>common) app on it,
>and they did so intentionally, because they knew it was an app that p
---
title: CPE Weekly status email
tags: CPE Weekly, email
---
# CPE Weekly: 2020-06-218
Background:
The Community Platform Engineering group is the Red Hat team combining
IT and release engineering from Fedora and CentOS. Our goal is to keep
core servers and services running and maintained, build
On 6/28/20 10:03 AM, John M. Harris Jr wrote:
On Saturday, June 27, 2020 1:06:01 PM MST Igor Raits wrote:
On Sat, 2020-06-27 at 09:58 -0700, John M. Harris Jr wrote:
I definitely agree on taking out "rhgb quiet", that's annoying as all
hell,
not knowing what's going on during the boot process.
On Sat, Jun 27, 2020 at 5:17 PM Gerald B. Cox wrote:
>
>
>
> On Sat, Jun 27, 2020 at 2:30 PM Chris Murphy wrote:
>>
>> On Sat, Jun 27, 2020 at 2:53 PM Gerald B. Cox wrote:
>>
>> > Why would we be installing something by default that has widely known
>> > broken functionality?
>>
>> Because the
> The context of that is: the default when the user does not specify. If
> the user chooses 'raid1' in the installer, they get 'raid1' for both
> data and metadata.
This does not seem to be the case, and from what I can tell Garry experienced
this problem as well.
I tested this in a VM with two d
On Sun, Jun 28, 2020 at 9:04 AM wrote:
> I'm willing to perform further testing. There shouldn't be anything very
> special about my workload. I was working mostly with NodeJS 12 and React
> Native. VS Code (I should mention I make use of TabNine, which can be a huge
> drain on system resource
On Fri, Jun 26, 2020 at 12:10 AM Iñaki Ucar wrote:
> Yesterday I fixed a FTBFS, but it's still showing in my dashboard. I
> suppose that it takes some time to update, but how long should I
> expect it to show there until I should suspect that there's some bug?
>
> Iñaki
>
Yeah, we are having som
On Sun, Jun 28, 2020 at 3:11 PM Tom Seewald wrote:
>
> > For btrfs, it's raid0 data, raid1 metadata.
> Surely this is considered a serious installer bug? Users who choose an option
> called "raid1" with btrfs would, and should, expect to have data redundancy.
The context of that is: the default
> For btrfs, it's raid0 data, raid1 metadata.
Surely this is considered a serious installer bug? Users who choose an option
called "raid1" with btrfs would, and should, expect to have data redundancy.
Even if this bug has existed for a long time, it doesn't make it any less
dangerous.
__
On Sunday, June 28, 2020 12:18:32 PM MST Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Jun 27, 2020 at 03:34:17PM -0400, Matthew Miller wrote:
>
> > On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote:
> >
> > > Jesus Christ, this actually got approved. It's time to fork Fedora. This
On Sun, Jun 28, 2020 at 1:25 PM Antti wrote:
>
> However the most commendable thing he wrote here is the part where he
> honestly admits that they also do have many real data loss bugs in btrfs and
> wishes that people would not spread rumors of non-existential ones.
I asked him about the "have
> And you are taking his quote out of the context, which is in the message
> you quote: the false / unsupported claim of data loss.
> That context includes that he trusts Btrfs more than other file
> systems, and he's been using Btrfs in production all day long for a
> long time now. By all means
On Sat, Jun 27, 2020 at 03:34:17PM -0400, Matthew Miller wrote:
> On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote:
> > Jesus Christ, this actually got approved. It's time to fork Fedora. This is
> > really getting out of hand.
>
> As mentioned earlier, there's no need to "fork F
On Sun, Jun 28, 2020 at 9:04 AM wrote:
>
> >(if Alexandre is willing to do some further
> >testing to put numbers on the problem)?
>
> I'm willing to perform further testing. There shouldn't be anything very
> special about my workload. I was working mostly with NodeJS 12 and React
> Native. VS
On Wed, Jun 24, 2020 at 10:45 AM Vít Ondruch wrote:
>
>
> Dne 24. 06. 20 v 15:47 Miro Hrončok napsal(a):
> > On 24. 06. 20 14:41, Vít Ondruch wrote:
> >> Having python27 and python36 modules is fail, because these should be
> >> 2.7 and 3.6 streams of python module.
> >
> > Oh. We are so sorry for
> On Saturday, June 27, 2020 12:34:17 PM MST Matthew Miller wrote:
> > On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote:
> >
> > > Jesus Christ, this actually got approved. It's time to fork Fedora. This
> > > is really getting out of hand.
> >
> >
> >
> > As mentioned earlier, th
On So, 28.06.20 11:15, Chris Murphy (li...@colorremedies.com) wrote:
> On Sun, Jun 28, 2020 at 12:39 AM Gabriel Ramirez wrote:
> >
> > On 6/27/20 11:09 PM, Chris Murphy wrote:
> > > On Sat, Jun 27, 2020 at 9:25 PM Gabriel Ramirez
> > > wrote:
> > >> On 6/27/20 9:06 PM, Chris Murphy wrote:
> > >
> Fedora does not currently have a default terminal text editor, because
> the $EDITOR environment variable is unset by default. But a common
> scenario where users wind up in a terminal text editor is when using
> 'git commit'. By default, git picks vi. You need to spend time
> learning how to use
Thanks for the response, but you talked around my two main questions
without addressing them. Chris asked to "state it clearly" so I put my
main questions after
the ===>. I've reposted that initial reply in full, and then I responded
to your specific comments.
I have no problems with BTRFS being
On Friday, June 26, 2020 10:53:59 AM MST David Cantrell wrote:
> On Fri, Jun 26, 2020 at 01:23:17PM -0400, Neil Horman wrote:
>
> >On Fri, Jun 26, 2020 at 10:03:12AM -0700, Adam Williamson wrote:
> >
> >> On Fri, 2020-06-26 at 12:58 -0400, Neil Horman wrote:
> >>
> >> > > From this thread you can
On Friday, June 26, 2020 11:09:31 AM MST Matthew Miller wrote:
> On Fri, Jun 26, 2020 at 12:50:52PM -0500, Michael Catanzaro wrote:
>
> > That actually works really well, and we should seriously consider
> > doing it. Or at least suggesting it to upstream.
> >
> > It doesn't even take extra space
On Sun, Jun 28, 2020 at 11:15:01AM -0600, Chris Murphy wrote:
> On Sun, Jun 28, 2020 at 12:39 AM Gabriel Ramirez wrote:
> >
> > On 6/27/20 11:09 PM, Chris Murphy wrote:
> > > On Sat, Jun 27, 2020 at 9:25 PM Gabriel Ramirez
> > > wrote:
> > >> On 6/27/20 9:06 PM, Chris Murphy wrote:
> > >>>
> > >
On Thursday, June 25, 2020 1:27:06 PM MST Michael Catanzaro wrote:
> On Thu, Jun 25, 2020 at 8:40 pm, Ian McInerney
> wrote:
>
> > Are you sure this will work? I just ran a test, and putting a new
> > config file inside /usr/lib/environment.d only works for Gnome, and
> > doesn't work for Mate
On Sun, Jun 28, 2020 at 12:39 AM Gabriel Ramirez wrote:
>
> On 6/27/20 11:09 PM, Chris Murphy wrote:
> > On Sat, Jun 27, 2020 at 9:25 PM Gabriel Ramirez wrote:
> >> On 6/27/20 9:06 PM, Chris Murphy wrote:
> >>>
> >>> Just a PSA: btrfs raid1 does not have a concept of automatic degraded
> >>> moun
Hello again,
I forgot to mention my fas account: trasher
Le 28/06/2020 à 15:39, Johan Cwiklinski a écrit :
> Hello,
>
> I'm going to stop packaging, so I've orphaned the following packages I
> was "maintaining":
> - iipsrv
> - glpi
> - php-elvanto-litemoji
> - php-IDNA_Convert
> - php-markdown
https://bugzilla.redhat.com/show_bug.cgi?id=1851257
Emmanuel Seyman changed:
What|Removed |Added
Status|NEW |CLOSED
Fixed In Version|
On Saturday, June 27, 2020 12:34:17 PM MST Matthew Miller wrote:
> On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote:
>
> > Jesus Christ, this actually got approved. It's time to fork Fedora. This
> > is really getting out of hand.
>
>
>
> As mentioned earlier, there's no need
On 2020-06-29 03:03, John M. Harris Jr wrote:
On Saturday, June 27, 2020 1:06:01 PM MST Igor Raits wrote:
On Sat, 2020-06-27 at 09:58 -0700, John M. Harris Jr wrote:
> I definitely agree on taking out "rhgb quiet", that's annoying as all
> hell,
> not knowing what's going on during the boot proc
On Saturday, June 27, 2020 9:50:20 AM MST John M. Harris Jr wrote:
> On Thursday, June 25, 2020 10:18:59 AM MST Ben Cotton wrote:
>
> > https://fedoraproject.org/wiki/Changes/UseNanoByDefault
> >
> > == Summary ==
> >
> > Let's make Fedora more approachable, by having a default editor that
> > d
On Saturday, June 27, 2020 1:06:01 PM MST Igor Raits wrote:
> On Sat, 2020-06-27 at 09:58 -0700, John M. Harris Jr wrote:
> > I definitely agree on taking out "rhgb quiet", that's annoying as all
> > hell,
> > not knowing what's going on during the boot process.
>
>
> Why does the user need to kn
On Friday, June 26, 2020 8:22:49 AM MST Matthew Miller wrote:
> On Fri, Jun 26, 2020 at 11:15:24AM -0400, Michael Watters wrote:
>
> > Why not zfs?
>
>
> We cannot include ZFS in Fedora for legal reasons. Additionally, ZFS is not
> really intended for the laptop use case.
Has that actually been
On Sun, Jun 28, 2020 at 5:56 AM Antti wrote:
>
> "We have far too many real data loss bugs in btrfs already."
>
> Source:
> https://lore.kernel.org/linux-btrfs/20200619050402.gn10...@hungrycats.org/
Zygo Blaxell is a linux-btrfs@ list and #btrfs channel regular, and
contributor to the kernel. And
On Sun, 2020-06-28 at 09:36 -0600, Chris Murphy wrote:
> On Sun, Jun 28, 2020 at 9:04 AM wrote:
> Do you recall what mount options you were using? In particular this
> sounds like a side effect of using the discard mount option with
> certain SSDs. This is a significant motivation of the new
> dis
On Sunday, June 28, 2020 3:21:17 AM MST Antti wrote:
> Hello,
>
> I'm in total opposition to this proposal as a long-time Fedora user. The
> btrfs is unstable and not ready for production. Most of what I'm about to
> write is admittedly anecdotal but it's the only file system in Linux which
> has
On Sa, 27.06.20 08:45, W. Michael Petullo (m...@flyn.org) wrote:
> /dev/uinput presently bears the permissions 0600, and it is owned by
> root. Has anyone ever thought about assigning ownership of /dev/uinput to
> the user associated with the console? It seems it might be appropriate
> for pam_con
It's failing because OSL needs C++14 or higher for LLVM 10 (as the CMake
error hints at). Try passing in "-DCMAKE_CXX_STANDARD=14" to you CMake
arguments.
-Ian
On Sun, Jun 28, 2020 at 4:48 PM Luya Tshimbalanga
wrote:
> Hello team,
>
> I am getting OpenShadingLanguage package needed for Blender
On Sun, Jun 28, 2020 at 12:04 AM Tom Seewald wrote:
>
> > I'm not sure where it is in the priority list.
> >
> > If you're doing a preemptive replace, there's no degraded state. Even
> > if there's a crash during this replace, all devices are present, so
> > it'll boot normally. The difficulty is
On Sun, Jun 28, 2020 at 9:44 AM Luya Tshimbalanga
wrote:
> Blender somehow failed to build within cmake on Rawhide even though it
> succeeded on other branches. I don't know what exactly changed. Here is
> the repository and the scratch build for examination:
The blender breakage seems to have b
Hello team,
I am getting OpenShadingLanguage package needed for Blender to review
soon but encounter an build issue:
https://download.copr.fedorainfracloud.org/results/luya/openshadinglanguage/fedora-rawhide-x86_64/01506931-openshadinglanguage/build.log.gz
COPR build source:
https://download
Hello team,
Blender somehow failed to build within cmake on Rawhide even though it
succeeded on other branches. I don't know what exactly changed. Here is
the repository and the scratch build for examination:
Spec file:
https://src.fedoraproject.org/rpms/blender/commits/master
Scratch resu
On Sun, Jun 28, 2020 at 9:04 AM wrote:
>
> >(if Alexandre is willing to do some further
> >testing to put numbers on the problem)?
>
> I'm willing to perform further testing.
Do you recall what mount options you were using? In particular this
sounds like a side effect of using the discard mount o
On Sun, Jun 28, 2020 at 8:11 AM Fabio Valentini wrote:
>
> From what I remember about Android Studio / Simulator, it uses qemu and disk
> images under the hood. Setting the nodatacow attribute (chattr +C, I think?)
> on VM images should improve performance by a fair bit.
chattr +C (nodatacow) i
>(if Alexandre is willing to do some further
>testing to put numbers on the problem)?
I'm willing to perform further testing. There shouldn't be anything very
special about my workload. I was working mostly with NodeJS 12 and React
Native. VS Code (I should mention I make use of TabNine, which can
On Sun, Jun 28, 2020 at 09:20:32AM -0500, Michael Catanzaro wrote:
> On Sun, Jun 28, 2020 at 4:11 pm, Fabio Valentini
> wrote:
> > Maybe libvirt / gnome-boxes / virt-manager should do that by default if
> > it detects that the backing storage for an allocated VM image is on
> > btrfs (if it doesn'
On Sun, Jun 28, 2020 at 4:11 pm, Fabio Valentini
wrote:
Maybe libvirt / gnome-boxes / virt-manager should do that by default
if it detects that the backing storage for an allocated VM image is
on btrfs (if it doesn't do that already)?
Yeah that's the plan:
https://gitlab.gnome.org/GNOME/gnom
On Sun, Jun 28, 2020, 16:04 Neal Gompa wrote:
> On Sun, Jun 28, 2020 at 9:57 AM Michael Catanzaro
> wrote:
> >
> > (fixing the subject line to not mention nano)
> >
> > On Sun, Jun 28, 2020 at 5:16 am, alexandrebfar...@gmail.com wrote:
> > > Don't expect much love on this, since my opinion has b
On Sun, Jun 28, 2020 at 2:05 am, Stasiek Michalski
wrote:
There is no gui for basically anything btrfs related anywhere, since
SUSE has had close to 0 interest in desktop for around 10 years.
Since I
heard there is nobody maintaining gnome-disk-utility, I might have
some
motivation to help
On Sun, Jun 28, 2020 at 9:57 AM Michael Catanzaro wrote:
>
> (fixing the subject line to not mention nano)
>
> On Sun, Jun 28, 2020 at 5:16 am, alexandrebfar...@gmail.com wrote:
> > Don't expect much love on this, since my opinion has been downvoted
> > on reddit by many of those who don't want to
(fixing the subject line to not mention nano)
On Sun, Jun 28, 2020 at 5:16 am, alexandrebfar...@gmail.com wrote:
Don't expect much love on this, since my opinion has been downvoted
on reddit by many of those who don't want to hear bad news about
btrfs. And no, I don't have any benchmarks and di
On Sat, Jun 27, 2020 at 8:58 pm, Konstantin Kharlamov
wrote:
Btw, I should also add here: it may be clear that in ideal situtation
BTRFS will
always be slower than non-COW file systems. The problem however, it
is not even
on par with the other open-source COW file system, which is ZFS.
Setti
Hello,
I'm going to stop packaging, so I've orphaned the following packages I
was "maintaining":
- iipsrv
- glpi
- php-elvanto-litemoji
- php-IDNA_Convert
- php-markdown
- php-scssphp-scssphp
- php-simplepie
- php-true-punycode
I've removed myself on all packages I was "admin" on, I'd also like t
On Sat, Jun 27, 2020 at 08:06:26PM -0600, Chris Murphy wrote:
> Just a PSA: btrfs raid1 does not have a concept of automatic degraded
> mount in the face of a device failure. By default systemd will not
> even attempt to mount it if devices are missing. And it's not advised
> to use 'degraded' moun
On Sat, Jun 27, 2020 at 6:25 pm, Gerald B. Cox wrote:
Making something the default is a high bar to clear. There needs to
be a compelling reason why? The things listed in the proposal may be
nice for some people, but the uninformed masses don't care.
There is a large list of benefits, liste
> This has happened to me because OpenSUSE and Jolla's Sailfish OS use btrfs as
> their
> default file system. I've tried using btrfs from time to time in various
> environments
> to see how it's progressing. However there hasn't been fixes for long-standing
> issues in btrfs when it comes to des
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Sun, 2020-06-28 at 10:21 +, Antti wrote:
> Hello,
>
> I'm in total opposition to this proposal as a long-time Fedora user.
> The btrfs is unstable and not ready for production. Most of what I'm
> about to write is admittedly anecdotal but it'
> Yes, BtrFs was very unstable, but before. Every software has this process.
> I have talked to one of the maintainer of BtrFs, she thinks that BtrFs
> is ready to production usage. (few years before, she is strongly
> against using BtrFs for production purpose).
It's true that every piece of soft
And to add, since zfs can't be supported by Fedora by now, the only
filesystem that can identify file corruption and bit flip in your memory.
So, if btrfs is stable enough, this will be absolutely a benefit to users.
___
devel mailing list -- devel@lists.
* Richard Hughes:
> On Fri, 26 Jun 2020, 22:21 Florian Weimer, wrote:
>
> Is FirmwareUpdate.efi really firmware in Fedora's sense? Won't it run
> on the host CPU?
>
> This is flashed hardware!? Can't mellanox just use the LVFS to
> distribute firmware rather than having to install a package of
Yes, BtrFs was very unstable, but before. Every software has this process.
I have talked to one of the maintainer of BtrFs, she thinks that BtrFs
is ready to production usage. (few years before, she is strongly
against using BtrFs for production purpose).
But after all, this is an open-topic we sh
If this change will be accepted I think need to modify anaconda
partition dialog for BTRFS scheme.
It has difficult and not obvious behavior when user want to change
automatically created partition scheme and resize BTRFS volumes.
See this bugreport https://bugzilla.redhat.com/show_bug.cgi?id=18512
Hello,
I'm in total opposition to this proposal as a long-time Fedora user. The btrfs
is unstable and not ready for production. Most of what I'm about to write is
admittedly anecdotal but it's the only file system in Linux which has actively
and regularly caused me to lose data on desktops, lap
OpenZFS is frequently lagging behind in support for newer kernels which would
work against Fedora's "rolling" approach to kernel releases.
Proxmox and Ubuntu don't feature rolling kernel releases. That's why they can
ship OpenZFS (without legal problems, btw).
___
Hello,
I decided to register just so I could offer my humble take on this. First
of all, I have many years of Linux experience (mostly on Debian and
Gentoo), but after years without having Linux on my desktop environments
(though I did use it on all servers I have managed, mostly on the Debian
sid
Il 27/06/20 19:20, Artur Iwicki ha scritto:
> So I'm trying to package the Free Pascal Compiler and Lazarus (the most
> popular IDE + GUI framework for FPC) for EPEL8. I have requested an epel8
> branch for fpc and for fpc-srpm-macros; both of those have been built,
> submitted to bodhi, and are
89 matches
Mail list logo
