drm / drm2 removal in 12

[blubee blubeeme]

On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen <sh+freebsd-current at codevoid.de>
wrote:

> blubee blubeeme wrote:
> > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore <kris at ixsystems.com>wrote:
> >> I've been personally using the new DRM bits since almost day one. I
> >> haven't found it to be unstable in the slightest. Compared to not
> >> having it and being forced to run 5+ year old hardware, it's been a
> >> huge blessing for those of us who care about running FreeBSD as a
> >> modern desktop / laptop.
> >>
> >> FreeBSD being an open source project, you are welcome to contribute
> >> back your work anytime. But since I don't imagine we'll see that
> >> patch coming anytime soon, I'll stick with this new LinuxKPI-powered,
> >> Plasma-desktop running awesomeness.
> >>
> >> (Written from my brand new Lenovo P71 which worked flawlessly out of
> >> box)
> >
> > Please tell me more about you're modern hardware, Kris Vice President
> > of Engineering at iXsystems.
> >
> > Try asking a person who doesn't run server infrastructure software and
> > hardware to get that stuff up and running, would you?
>
> Do you want to ask me? I'm mostly a private individual and linux/debian
> user that got fed up with the Linux fragmentation and direction of
> development (from a user perspective). I found my new home in FreeBSD.
> I migrated my (hobby) root server and have a few jails up and running
> and doing random stuff on them for myself and friends.
>
> Key to this was that I was able to get FreeBSD up and running on my
> Laptop - with the drm-next kmod - and use it daily to get used to it and
> learn about it. Actually it was a pain in the ass because back then I
> had to learn how to make -current run and even worse, I had to use the
> drm-next graphics branch from a github repository which wasn't even
> on the main FreeBSD account. I was forced to update the kernel every
> once in a while because the pkg update would complain otherwise. It
> frequently broke and I had to deal with it and learn how to recover it.
>
> The alternative would have been to go back to Linux, which has a whole
> lot more to complain about. So I stayed. And I'm happy with it.
>
> I accepted all this trouble to have decent graphics support. In all
> the time I had to fight -current issues a lot more than anything
> drm/graphics related. This stuff was always stable for me.
>
> I saw a few people trying out FreeBSD. And the first thing after the
> Installation is always: Graphics and Wifi. That's what people need.
>
> These are "desktop needs", where supporting new hardware fast is more
> important than being rock stable and feature complete.
>
> Just my 2 cents,
> Stefan
>
> --
> Stefan Hagen
> Mail: sh at codevoid.de | encryption key in header.
> gopher://codevoid.de | https://codevoid.de
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>
Like you said you're doing hobby work, that's fine. Take the time to test
that bleeding edge stuff on a branch somewhere.

You guys cannot expect reasonable people who have machines running
production code to have to deal with that type of nonsense that you just
described.

You left Linux because it's an unorganized mess, FreeBSD is not Linux.
There are clear rules and restrictions if you guys cannot understand this
then this is just a waste of time.

FreeBSD is server first and while that may suck for hobbyist at first, once
you understand that people who run servers do not care about graphics as
much as hobbyist do they need a reliable core.

The linuxkpi stuff the total antithesis of what I understand to be the
FreeBSD philosophy. Try reading it again:
https://www.freebsd.org/doc/handbook/nutshell.html

You guys can't expect to destroy the stability for everyone because a few
hobbyist who volunteer in their free time want to wreck the system.

Work on your code to improve the quality instead of trying to turn the
FreeBSD kernel into a thin wrapper around Linux kernel. Solve the
engineering problems instead of asking for quick fix solutions.

Any of you linuxkpi guys who are pushing this, what will be enough?

Haven't you guys gotten enough leeway from the core team?
How many breaking changes do you want to introduce to the FreeBSD kernel vs
engineering your software to work well within the existing infrastructure?

Which one of you guys dare to stand up and define a goal?