Re: F35 Change: "Fedora Linux" in /etc/os-release

[Jiří Eischmann]

Ben Cotton píše v Út 09. 03. 2021 v 09:33 -0500:
> https://fedoraproject.org/wiki/Changes/Fedora_Linux_in_os-release
> 
> == Summary ==
> 
> "Fedora" is the name of our project. Our general-purpose Linux
> distribution is "Fedora Linux". Let's refer to it that way in the OS
> itself.

This change is not a big deal for me, but IMO we're better off as it is
now.

We used to write books on MandrakeLinux and Mandriva Linux. Everyone
just called them Mandrake and Mandriva, but we always had to make sure
we didn't miss the Linux part of the name anywhere in the book to call
it the right way. It felt artificial and unccessary.

It will be the same here. If the main reason for changing the name is
to emphasize that it's a Linux-based OS, then it makes sense. If the
main reason is to distinguish the community and the product, then I
don't think it's going to help much. We've already had that distiction:
Fedora Project <-> Fedora.
Many people call both Fedora and that's not gonna change with this.

Also it doesn't come together very nicely with the edition naming.
We've got Fedora Linux, but Fedora Workstation, Fedora Server, Fedora
IoT? Those are not Linux-based since the "Linux" part is dropped from
their name? It has potential to create more confusion.

Jiri

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: End of CentOS Linux: What about Fedora?

[Jiří Eischmann]

Jaroslav Prokop píše v St 09. 12. 2020 v 14:07 +0100:
> Hello,
> 
> On 09/12/2020 13:28, Peter Robinson wrote:
> > On Wed, Dec 9, 2020 at 11:12 AM Christoph Karl 
> > wrote:
> > > Hello!
> > > 
> > > On 09.12.20 04:26, Sergio Belkin wrote:
> > > > How does this (
> > > > https://blog.centos.org/2020/12/future-is-centos-stream/)
> > > > affect Fedora?
> > > I think Fedora now needs some kind of LTS.
> > Why? What would it provide that CentOS Stream doesn't?
> 
> It would provide with what is lost with CentOS Linux.
> Let's entertain an example:
> I would like to setup a home server with some locally hosted
> services, 
> but I wouldn't like to update it to new system with new software
> every 
> year just to get security updates.

I wouldn't be afraid to use Fedora for this. I've been running Fedora
Server ony my personal server with Nextcloud on LAMP and a couple of
other services such as VPN, Wireguard, TUN and it's been really
effortless. I don't remember last time I had any problem. Once 6 months
I do a snapshot and upgrade which has been really smooth. I actually
find it easier than running the same release for 3 years, but then
having to undergo a migration to a new major release. And I still get
to enjoy the latest and greatest.

Jiri 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Driverless scanning for WSD and ESCL supported scanners is coming

[Jiří Eischmann]

Zdenek Dohnal píše v St 05. 08. 2020 v 07:44 +0200:
> Hi all,
> 
> I would like to announce sane-airscan project [1] will be shipped in
> the
> official Fedora repositories from Fedora 32 [2].
> 
> sane-airscan implements a backend for Microsoft WSD and ESCL (usually
> called AirScan, originating from Apple) protocols, which are common
> in
> newer (2012+) scanners and multi-function devices for scanning.
> 
> Using sane-airscan, newer devices don't need vendor proprietary
> software
> for scanning any longer (e.g. hplip with its hp-plugin).
> 
> The project is divided into main package - sane-airscan - which
> contains
> helper tool - airscan-discover - for discovering devices in setups,
> where automatic DNS-SD discovery doesn't do the trick, and subpackage
> -
> libsane-airscan - which the main package requires and the common
> known
> project for scanning - sane-backends - will require to get the
> backend
> into common scanning stack installation.
> 
> Please feel free to test it.

 Will it be possible to use a Fedora machine as a server, so that I can
have an old scanner connected to it via USB and then shared with other
devices on the local network via those protocols?
That would be neat.

Jiri
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Firefox 78.0.2 for F32

[Jiří Eischmann]

Kevin Fenzi píše v Po 13. 07. 2020 v 16:37 -0700:
> On Tue, Jul 14, 2020 at 08:33:04AM +1000, Bojan Smojver via devel
> wrote:
> > Would someone with sufficient powers mind queueing up this update?
> 
> I would assume that person would be the one who built it... 
> 
> perhaps there's some reason for not wanting to push it yet. 
> (CCing builder here)

Jan is on holidays this week, so is the other Firefox maintainer
(Martin Stransky). We looked at the update, it built fine, runs fine,
Jan just probably forgot to push it before he left.
It's being pushed to F32/F31 updates-testing as we speak. Feedback
welcome ;)

Jiri
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Jiří Eischmann]

Adam Williamson píše v Út 30. 06. 2020 v 08:25 -0700:
> On Tue, 2020-06-30 at 16:23 +0200, Marcin Juszkiewicz wrote:
> > W dniu 30.06.2020 o 15:34, Jóhann B. Guðmundsson pisze:
> > > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream
> > > changes it beg the question if now would not be the time to stop
> > > supporting booting in legacy bios mode and move to uefi only
> > > supported boot which has been available on any common intel based
> > > x86
> > > platform since atleast 2005.
> > 
> > Will you provide replacement for laptop I bought in 2013? Still has
> > some
> > use, runs Fedora 31 just fine. BIOS mode only.
> > 
> > My other PC at home is BIOS mode only too. Sure, it is FX-6300 so
> > quite
> > old but with some hard drives and 16GB of ram it has a use.
> 
> I'm also still using a laptop from 2010:
> 
> https://www.trustedreviews.com/reviews/sony-vaio-z-series-vpc-z11z9e-b-13-1in-laptop
> 
> it has outlived one 'replacement' so far, and my 3.5 year old XPS 13
> (9360 gen) recently stopped booting so unless I can fix that, it will
> have outlived two...
> 
> it has no UEFI support either.

I maintain the following laptops in our family:
ThinkPad R61
ThinkPad T400s
ThinkPad X201
Macbook Pro 2010

All of them don't support UEFI, but run Fedora 32 just fine and are
still useful to my relatives. I think one of the important roles of
Linux distributions is that they allow you to keep using hardware that
has been obsoleted by its vendors, help you fight the planned
obsolescence.
I know that supporting old hardware comes at a cost and at some point
we just have to make a cut, but doing it for hardware that is 8-10
years old is not much better than the planned obsolescence.

Jiri
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Jiří Eischmann]

Kamil Paral píše v Út 16. 06. 2020 v 14:21 +0200:
> On Tue, Jun 16, 2020 at 12:25 PM Kevin Kofler  > wrote:
> > Kamil Paral wrote:
> > > I'll not talk about implementation, there are more suitable
> > people for
> > > that here. But I'll voice my opinion that automatically retiring
> > software
> > > from Fedora users' computers is a sane and proper thing to do. If
> > a
> > > package is removed from Fedora, it should also be removed from
> > users
> > > computers (during FN+1 upgrade). Of course, we should allow users
> > to keep
> > > it, if they want it. But the default process should happen
> > automatically,
> > > and users should opt-out of automatic retiring, instead of opt-
> > in. Only
> > > this way we can build a secure and reliable operating system.
> > > 
> > > If only power users can opt-out from retiring a package (e.g. by
> > editing
> > > dnf.conf), I don't think that's a problem. Because even though
> > general
> > > users will of course be unhappy when an application they use get
> > > permanently removed during system upgrade, they will be even more
> > unhappy
> > > when their system suddenly breaks in the future, either by
> > unresolved
> > > dependencies, or when the retired app/library causes the system
> > to not
> > > boot or breaks the desktop, because nobody at that points expects
> > and
> > > tests those software interactions. A general user can resolve a
> > missing
> > > app, but they can't resolve a broken OS. If they want to deviate
> > from the
> > > system we provide, it's reasonable to ask them to have certain
> > technical
> > > knowledge, instead of allowing them to shoot themselves in the
> > foot (even
> > > unknowingly, by not doing automatic retirement).
> > 
> > I cannot agree with these statements. I think removing working
> > software from 
> 
> You can't say whether it's working, because it has been retired in
> Fedora, it has no maintainer, no testing, no security updates or bug
> fixes.

+1
Any software which doesn't get maintenance at least on the security
level should be considered by any responsible software provider as
broken these days.

I'd also add that it creates confusion among users. I often read
questions on forums like: "I've got a package XY on my computer with
Fedora 32 upgraded from a previous version, but I cannot install the
same package on a freshly installed Fedora 32. Why?"

Jiri
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Call for testing - Firefox CSD/titlebar

[Jiří Eischmann]

Greg Evenden píše v So 16. 09. 2017 v 10:15 +:
> > On 09/15/2017 07:28 PM, Greg Evenden wrote:
> > 
> > I just looked at Chrome and it's very similar to Firefox.  There is
> > no 
> > menubar and the ALT key doesn't even bring up a menu at
> > all.  Instead of 
> > the "hamburger" menu, there is just a vertical row of 3 dots which 
> > brings up a much more limited menu.  So why is Chrome so much
> > better?
> 
> again, i use Bookmarks Bar in Chrome. i do not use the ugly Hamburger
> menu

Still, "another reason why People use Google Chrome." doesn't make
sense to me. Since both browsers have a very similar menu by default
and both allow to change it, it clearly is not another reason why
people use Chrome.

Jiri

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Jiří Eischmann]

Nico Kadel-Garcia píše v Út 18. 07. 2017 v 22:44 -0400:
> On Fri, Jul 14, 2017 at 12:59 PM, Debarshi Ray 
> wrote:
> > On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
> > > On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> > > >  F29: packagers (of graphical applications) must create
> > > > Flatpaks of
> > > >   their applications if possible. They *may* keep standard
> > > > RPM
> > > >   packaging.
> > > 
> > > At least we see where this is going.
> > > 
> > > If RPMs of the graphical application work fine now, what on earth
> > > is
> > > the point of forcing packagers to make Flatpaks?  Sandboxing
> > > isn't one
> > > of them - as already explained, sandboxing is orthogonal to
> > > packaging.
> > 
> > Huh? How would you get sandboxing without Flatpaks? Unless you are
> > proposing a different sandboxing technology.
> 
> By putting them in "/opt", the way other sanely packaged 3rd party
> components do?

How does that ensure any sandboxing?

Jiri

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Jiří Eischmann]

Neal Gompa píše v Út 18. 07. 2017 v 16:03 -0400:
> On Tue, Jul 18, 2017 at 4:00 PM, Matthew Miller
>  wrote:
> > On Tue, Jul 18, 2017 at 09:41:30PM +0200, nicolas.mailhot@laposte.n
> > et wrote:
> > > Then I'm glad there is absolutely no plan to preempt flatpack
> > > technical assessment by shipping one or more GNOME apps as
> > > flatpack-only, leaving Fedora users for whom flatpack does not
> > > work
> > > yet behind, and bypassing distribution consensus processes.
> > 
> > Please tone this inflammatory rhetoric down. It's not helpful. When
> > you
> > said you wanted this part of the thread to close, I thought that's
> > what
> > you meant and took it seriously.
> > 
> > Here, I assume you're talking about no one having packaged GNOME
> > Recipies (apparently _written_ as a Flatpak proof of concept) in
> > traditional RPM form. But, we can't make *any* upstream author
> > package
> > their stuff in RPM for us.
> > 
> > But, if you want that as an RPM in Fedora, _no one is really
> > stopping
> > you_. Go for it!
> > 
> > If you're talking about something else here, then I missed it
> > completely and encourage you to be more straightforward and stick
> > to
> > the technical.
> > 
> 
> I think he's worried that applications might intentionally get left
> behind that someone would want.
> 
> Also, GNOME upstream doesn't do the packaging for Fedora GNOME
> anyway.
> That's the Workstation WG's job. Just like how the KDE SIG packages
> the Qt/KDE stack, the Workstation WG (aka GNOME SIG) does this for
> the
> GTK+/GNOME stack.

I don't think this is entirely true.

The mission statement of Workstation Working Group:
"The Fedora Workstation working group aims to create a reliable, user-
friendly and powerful operating system for laptops and PC hardware. The
system will primarily be aimed at providing a platform for development
of server side and client applications that is attractive to a range of
developers - from hobbyists and students to developers working in
corporate environments."

It's a group that focuses on building a desktop OS based on GNOME, yes,
that involves packaging of a sizable part of the GNOME stack, but that
doesn't mean that it's their job and obligation to package (any) GNOME
software.

Jiri

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Jiří Eischmann]

Kevin Kofler píše v Út 18. 07. 2017 v 03:06 +0200:
> Jiří Eischmann wrote:
> > I agree with Matt here, Fedora Project's mission (neither the old
> > one,
> > nor the new draft) doesn't say anything about RPM. RPM is just
> > means to
> > an end, not the goal. And I don't know why Fedora should be tied to
> > RPM
> > forever. Really successful brands don't die when their current
> > solution
> > stops being relevant, really successful brands are able to
> > transition
> > themselves and stay relevant as the market shifts.
> 
> You are implying there that RPM is (or will soon be) no longer
> relevant, 
> which is just not true. Flatpak does NOT deliver equivalent
> functionality.

No, I'm not implying that RPM is no longer relevant, I'm implying that
it might not be relevant in the (even distant) future. I don't think no
one here wants to get rid of RPM while it's relevant. Just like car
companies are not ditching traditional cars because they're still very
much relevant, but  if we keep RPM as a dogma with the mindset "I can't
ever imagine Fedora without RPM", we will drive ourselves into
irrelevancy if the market really shifts to something else eventually.

Maybe in 10 years we will find that RPM is still the best way to put
the OS together and ship it to users, maybe there will be better
alternatives, who knows and if Fedora doesn't explore these
alternatives early enough, yeah, then we will no longer be relevant as
an OS.

IMHO the mission of the Fedora Project is to provide a free OS, not a
necessarily an RPM distro. Yes, RPM has happened to be the way we put
the OS together since the beginning, but that doesn't mean we can't
look past that just like car companies which want to survive in the
long run are looking into electric and hydrogen cars although for their
whole history they have only produced cars with internal combustion
engines.

Jiri

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Jiří Eischmann]

stan píše v Po 17. 07. 2017 v 08:02 -0700:
> On Mon, 17 Jul 2017 10:10:16 -0400
> Matthew Miller  wrote:
> 
> > We could look at starting a new brand. But, I don't think your
> > Harley-Davidson analogy applies, because we're not using this to
> > break
> > into a new market. We're using this to make sure that we remain
> > relevant as the market we are in changes. 
> 
> Except the whole market isn't changing.  It is just a new niche
> opening
> up.  It's like Gnome3 deciding to convert the desktop interface for
> mobile, creating a hybrid that tries to satisfy both, but hits the
> sweet spot for neither.  They would have been better off with a new
> product targeted at mobiles exclusively, called maybe goblin or
> pixie,
> while retaining their old brand, gnome2, to satisfy existing desktop
> users who were happy with the paradigm embodied in that brand.
> 
> > Let's take the current shift
> > to electric cars as a branding analogy — GM *could* have gone with
> > a
> > whole new name, but instead we have the Chevrolet Volt. (And Nissan
> > Leaf. And Ford is even reusing the "Focus" name.)
> > 
> > I think this matches our current and upcoming challenge more
> > closely. 
> 
> I think you are agreeing with him.  GM didn't convert the chevy
> malibu
> to electric.  They created a new brand.  People who want an IC malibu
> still can buy one, and know it isn't going to be electric tomorrow,
> leaving them high and dry.  And those who want to dip a toe into the
> Ecar market, can try it out from a brand they trust.  Just like the
> soap analogy.

Except they didn't really create a new car brand, just a model brand.
No one is saying Fedora for desktop will be all flatpaks from now on.
There will be another flavour that will be called Fedora Atomic
Workstation alongside  RPM-based Fedora Workstation. Just like
Chevrolet has electric Volt and traditional Malibu at the same time.
But no one in GM/Chevrolet is saying: No, the Chevrolet brand is
associated with combustion engines and it will stay that way forever.
GM is not spinning a new car company/brand for electric cars.
You say that they keep Malibu for people who want traditional cars, but
for how long? No one in GM is not gonna give you any promises because
if the market eventually shifts to electric cars they will just stop
doing the traditional cars. But the Chevrolet brand will stay.

I agree with Matt here, Fedora Project's mission (neither the old one,
nor the new draft) doesn't say anything about RPM. RPM is just means to
an end, not the goal. And I don't know why Fedora should be tied to RPM
forever. Really successful brands don't die when their current solution
stops being relevant, really successful brands are able to transition
themselves and stay relevant as the market shifts.

BTW we already have an official edition which doesn't use RPM as a
delivery system - Fedora Atomic and it's been part of the Fedora
Project for several years.

Jiri


> In my opinion, the equivalent for fedora would be to create a new
> spin
> called gatsby or homburg that uses flatpaks.  Maybe one waxes and one
> wanes. Or maybe there is a fork.  But what is being discussed now is
> making an all or nothing bet on a new technology.  Once rpm is ripped
> out of fedora, it won't be coming back, in practical terms.  There's
> a
> burning the ships sort of appeal in that approach, but it isn't the
> most prudent path from an expected value perspective.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Improving the Fedora boot experience

[Jiří Eischmann]

Allan Day píše v Út 12. 03. 2013 v 11:15 +:
 Hi all,
 
 On the question of how kernel versions should be accessed, I am very
 much in favour of the position that Chris Murphy expressed earlier:
 choosing a kernel version is opaque to most users and requires fairly
 advanced technical knowledge to understand.

I agree, but unfortunately, it's not the case of Fedora. By having a
rolling release policy for the kernel, we're forcing users to deal with
kernel versions.
I follow user forums quite a lot and I read it every day: I updated and
my wireless card stopped working, my computer doesn't wake up from
suspend, the system is now much slower. New kernels bring a lot of
regressions and we don't have enough test coverage to avoid them. The
general solution to those problems is to go back to the last working
kernel version. But by making it less obvious we make these frequent
problems more difficult to solve.

Jiri

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel