Not desktop icons

All I'm saying is that Bumblebee is an unofficial, unsupported option. If it works for you, perfect. If it's not, don't be surprised.

Via the applications menu

I think the problem is he's not using GNOME or KDE which support it...

Oh

888 members

i know, I've got a friend who has a licence telling me the same.Maybe this year will be the one

Do it. It is fun.

Yes

I think the problem is he's not using GNOME or KDE which support it...

how do I know that?

how do I know that?

Well, if you've installed Bumbleee, it's possible that it just overrode something in the graphics stack. I don't think the two solution can work side by side.

But yes, the option should be in that menu.

@Alcsaw here is something about it in more consumable form, there is a screenshot of how it looks, too: https://blogs.gnome.org/uraeus/2016/11/01/discrete-graphics-and-fedora-workstation-25/

Do you think uninstalling Bumblebee would solve that?

If you think that going through the procedure to install Bumblebee and more importantly maintain it in a workable state in the future is easier than using something that is already built-in and just works, I'm fine with that. Use whatever works for you.

The thing is that people use what day know how it works, stuff that it is well documented. If you don't mention the built in support I would have never realised it was implemented.

@Alcsaw here is something about it in more consumable form, there is a screenshot of how it looks, too: https://blogs.gnome.org/uraeus/2016/11/01/discrete-graphics-and-fedora-workstation-25/

Thanks! I'll read it on the bus :D I have an appointment now I'll try something and tell you guys if any news!

Never install drivers via *.run files. It creates lots of untracked by package manager files and configs.

Though, all times I tried to use RPM Fusion drivers, my system refused to load graphical enviroment.

While *.run worked perfectly.

The thing is that people use what day know how it works, stuff that it is well documented. If you don't mention the built in support I would have never realised it was implemented.

I understand. It will be widely advertised when we finish the step 7 and will have Nvidia drivers officially available in GNOME Software. Until then, it's supported, but not something to advertize among average users.

I understand. It will be widely advertised when we finish the step 7 and will have Nvidia drivers officially available in GNOME Software. Until then, it's supported, but not something to advertize among average users.

In GNOME software or in official repositories?

Because, what about people who don't use GNOME?

In GNOME software or in official repositories?

In GNOME Software which will link to either Negativo17 or RPMFusion repos. We're talking to both, but first we need to package the drivers the way it's solid, it doesn't break as often as now and if it breaks we have to fallback to nouveau drivers and not to leave the user with a blackscreen.

Negativo17 repo in production? Seriously?

In GNOME Software which will link to either Negativo17 or RPMFusion repos. We're talking to both, but first we need to package the drivers the way it's solid, it doesn't break as often as now and if it breaks we have to fallback to nouveau drivers and not to leave the user with a blackscreen.

I don't know if this is at all helpful, but I had to switch to Negativo's drivers a few releases ago because the RPMFusion ones broke on my desktop and I had kernel panics. It was too long ago for me to remember the details, but I remember using his drivers solved the problem I had at the time.

I've been using them since, but I have no idea why Negativo's worked and not the RPMFusion ones.

I tried installing both, neither worked for me sadly.

I don't know if this is at all helpful, but I had to switch to Negativo's drivers a few releases ago because the RPMFusion ones broke on my desktop and I had kernel panics. It was too long ago for me to remember the details, but I remember using his drivers solved the problem I had at the time.

In our opinion Negativo17 packages the drivers better, but it'd be better to have it in RPMFusion because there is a community of people behind with infra, not a single person.

In our opinion Negativo17 packages the drivers better, but it'd be better to have it in RPMFusion because there is a community of people behind with infra, not a single person.

This makes sense.

In our opinion Negativo17 packages the drivers better, but it'd be better to have it in RPMFusion because there is a community of people behind with infra, not a single person.

Yeah, my concern exactly. One person could get sick, for example, leaving community without updates.

Not a single point of failure then

Yeah, my concern exactly. One person could get sick, for example, leaving community without updates.

Yup.

But eh, the very first thing necessary is a stable and working driver in repo.

And, well, you can always offer Negativo to put his work to RPMFusion.

Yes, purely technically Negativo17 is closer to what we need right now, but we're still trying to make it work with the RPMFusion guys.

One of the major obstacles we have is that RPMFusion would have to create a special repo for it, we just can't enable non-free by default in Fedora with all the other, potentially patent-protected stuff.

One of the major obstacles we have is that RPMFusion would have to create a special repo for it, we just can't enable non-free by default in Fedora with all the other, potentially patent-protected stuff.

Well, just implement a checkbox. :)

"Use non-free repos for software and drivers"

Fedora can't even link a patent-protected stuff as "opt-in" unfortunately.

Even if that stuff is networking drivers, for example?

I am, honestly, very not into that licensing stuff.

Even if that stuff is networking drivers, for example?

If it's just drivers, it's probably fine, but non-free in RPMFusion has more and we don't have any control over it, so one day we may find ourselves offering something like ffmpeg in Fedora. So having a separate repo for drivers where we only offer that is a sensible thing.

I see.

In GNOME Software which will link to either Negativo17 or RPMFusion repos. We're talking to both, but first we need to package the drivers the way it's solid, it doesn't break as often as now and if it breaks we have to fallback to nouveau drivers and not to leave the user with a blackscreen.

I would prefer RPMFusion over negativo17.

In our opinion Negativo17 packages the drivers better, but it'd be better to have it in RPMFusion because there is a community of people behind with infra, not a single person.

This.

Fedora (Facebook) New supplemental wallpapers will make Fedora 26 look fabulous! Check them out. link

even the default wallpaper is amazing ?

Sadly, not much PCB macro shots in high resolution.

good number in Chinese culture :)

?

I need to sit down with some of pictures and figure out what I want to offer as wallpapers.

I completely forgot to submit two for the past release and I had some really good ones too

It's hard to pick just two though

?

want it?

Partly bad number in germany :D

want it?

Maybe you need to show me how you added the watermark, so I can it to some of my favorites. :)

haha

Inkscape (next gen wallpapers :P )

two layers, one with the image and the other with the logo

put the logo on the upper level, make it white and set the layer type to overlay or similar

then play with its opacity

that's it

It's hard to pick just two though

One Bluish Aurora Borealis will be good enough ?

ERROR: S client not available

they are usually greenish...

besides the blueish ones, of course.... RGB....

One Bluish Aurora Borealis will be good enough ?

Hah, only I don't have one of those. ? I'm a little heavily biased towards the Balkans right now.

they are usually greenish...

The greenish will represent the continuos work and the innovative spirit in the Fedora Project until it goes Bluish.

Hah, only I don't have one of those. ? I'm a little heavily biased towards the Balkans right now.

A baby blue sea/beach with white sands... ??

1. Wormhole 2. ???

time server was synchronized?

my guess - internal pc clock got desynched, then NTP kicked in and set the time

my guess - internal pc clock got desynched, then NTP kicked in and set the time

this is VM

but

okay, that was a restart

and this VM syncs with local ntp, with rtc. And problem did after reboot

so, syslogd got sigkill

either syslogd got killed and you just don't have the logs, or the whole machine shut down

Now VM is reboot again and ... all right

those are my guesses :D

okaaaay so it's in a reset loop

And this case is repeat and repeat...

try to boot into safe mode maybe

And this case is repeat and repeat...

https://docs.fedoraproject.org/en-US/Fedora/25/html/System_Administrators_Guide/sec-Terminal_Menu_Editing_During_Boot.html

also

try to boot into safe mode maybe

I can doing 20 boot trying, and all ok. But week later I am doing planned shutdown of hypervisor-host and ... this

you may remove quiet from kernel parameters in grub (or whatever it is in your vm), maybe something else will be visible

try to boot into safe mode maybe

why?

are there any logs from your vm hypervisor?

are there any logs from your vm hypervisor?

no, nothing

why?

to see if it at least boots there, also maybe you'll get access to more logs that way

sync time vm with hv - turn off

I can't see any logs from the ntp server in the screenshot you've provided, but maybe try to boot into rescue and disable the ntp service? just guessing, I'm not an administrator

that's what I would try to do, disable a lot of services and try to get to the one which is at fault

also I would check if there are hypervisor's problems, like lack of memory, but I doubt stuff in the vm would get sigkills in a nice ways like here