If not flatpaks would highly unstable.

If you compile ff56 flatpak against libpng 0.9 it'll use that lib version in 10 years too, right?

and you can do the same with an rpm or deb ?

If yes flatpaks are a security risk - and not encouraging devs to keep up with libraries.

and you can do the same with an rpm or deb ?

Not if you want it in fedora or rpmfusion.

Or rhel/centos.

I'd rather someone make a tool that can package applications for several packaging methods at once, rather than having flatpaks/snaps.

won't help in case of closed source applications which were released some time ago and never updated; usually it's true that outdated applications should not be used but sometimes it's more than handy

won't help in case of closed source applications which were released some time ago and never updated; usually it's true that outdated applications should not be used but sometimes it's more than handy

But the major applications should remain packaged - desktops, browsers ect.

well these libs come from the runtime which is up to date, they are confined so only affect themselves if they really do have something old. And any apps in a public repo can be easily updated like any rpm/deb

But the major applications should remain packaged - desktops, browsers ect.

yeah, I've always assumed Flatpak to be a last resort in case for some reasons proper packages are unavailable

well these libs come from the runtime which is up to date, they are confined so only affect themselves if they really do have something old. And any apps in a public repo can be easily updated like any rpm/deb

Do you remember the FF57 switch? With like 5% of users switching to palememe or deciding to just never update?

(5% number from what i've seen, no statistical backup)

yeah, I've always assumed Flatpak to be a last resort in case for some reasons proper packages are unavailable

And thats the only reason i'd accept a snap/pak and not use the application as result. If a software maker cant be bothered or isnt able to package it and the community doesnt want his tool anyway.

no? i don't see how this affects things, you are now talking about *users* not updating packages...this affects all package formats

no? i don't see how this affects things, you are now talking about *users* not updating packages...this affects all package formats

Its much harder to tell dnf to forever ignore firefox.

as it is with flatpak

or snaps

You eventually break it running at all or similar bugs start dragging you back.

as it is with flatpak

You can just never run flat-update or however it goes. I see neither nagging nor downside, as all old libs are still available and will forever be.

Well, no downside as theoretical user that wants to keep FF56 for example.

so you are saying the user *wants* to keep ff56 (which has it's own security issues) but the user should be forced to update the libs separately ? ... seems you are coming up with obscure usecases .... anyway seems we should agree to disagree

Not really. It's not available for other Linux versions.

you can install it from flathub

What info do we have here about The Intel incident?

what incident?

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

Sorry If It is offtopic

But seems relevant

What info do we have here about The Intel incident?

Intel doesnt respect something by design thus making many especially cloud workloads slower by 5-50%

Amd not affected thus rubbing their gands with glee.

intel on damage control already looking to shift the attention from them in mailing lists

Embargo ends on 4.Jan likely so we'll know more then

Seems like Linux Kernel is being patched, bit without any comments

Seems like Linux Kernel is being patched, bit without any comments

It has comments but its under embargo thus they can't make it public

But the mailing lists and amd submitting patches to exclude their properly working cpus from that bit being set has opened most details

That is what I understood

Do you know what tasks would be more affected?

What kind of work

Do you know what tasks would be more affected?

Databases, Virtualisation, Webhosting, Compiling - anything thats done in large scale and either has many syscalls or a ton of security check

It hurts Intel most where they really dont want it - the cloud.

Great... Just bought an old Thinkpad to substitute my old Toshiba oven...

pgsql has been tested to be 28-35% or so slower

Great... Just bought an old Thinkpad to substitute my old Toshiba oven...

Well, i hope that cpu is 30% faster at minimum

Just to have a little more power and virtualization....

is it dangerous for just users?

is it dangerous for just users?

Yes, kernel space leaks from js are much easier for example.

Well, i hope that cpu is 30% faster at minimum

I'm talking of old Core2Duo

You want this to be on

I'm talking of old Core2Duo

X200? are you in love with libreboot or why didnt you go for X230/t430 with coreboot?

This is a R500

I went for It because I wanted a cheap replacement for The Tos

Sell, get a used x230

Since It had Broken speakers, CD unit, has already burnt a mobo and didnt has vt-x

Sell, get a used x230

^

Another capped Intel? ?

Yes, kernel space leaks from js are much easier for example.

so we shouldnt browse wrong websites bc it cuuld leak some personal data from RAM?

Another capped Intel? ?

Well, with the improvement over an core2duo you'll lilely not notice the 25% slowdown

so we shouldnt browse wrong websites bc it cuuld leak some personal data from RAM?

Not only wrong websites, even legit websites can deliver malware trough advertising scripts and co.

great

And yes, if you defeat aslr this easy you can get to compromising the final kernel easier. So dont turn the mitigation off hoping it'd never hit you.

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

Which generation suffers ?

And of course if you run vms hoping theyd protect you ..

Which generation suffers ?

All

Intel - all amd - none via - none

Why don't they sue intel?

Why don't they sue intel?

Over what?

Seems like ALL at least from 2008

ERROR: S client not available

Over what?

For this god damn flaws?

And performance decrease

The intel me backdoor? 30% slowdown because of a hardware bug? Intel being shitty in general in pricing and competition?

im lil bit paranoid))

The intel me backdoor? 30% slowdown because of a hardware bug? Intel being shitty in general in pricing and competition?

Good point ?

For this god damn flaws?

Its just their implementation of this - you could only sue them if they contractually agreed to deliver certain scores or anyhting. And they dont because silicon lottery anyway.

Not only wrong websites, even legit websites can deliver malware trough advertising scripts and co.

thats means ublock not only blocks annoying banners, its also protects users

And of course Intel didnt invent kaslr - when they made 32bit x86 nobody ever thought of this advanced a mitigation

thats means ublock not only blocks annoying banners, its also protects users

adblockers are a safety feature, yes. The more ublock origin filterlists (except country based) the better

Amd not affected thus rubbing their gands with glee.

Hmm. Is this related to the patch that made it into the Linux kernel by AMD this week?

https://twitter.com/BryanLunduke/status/948430797266042880

pls help internal soundcard doesn exist on my Atom z3735f crappybook external works fine

sometimes I think my gnome shell is broken .-. right now it uses 23% of RAM. On a notebook with 16GB…

Hmm. Is this related to the patch that made it into the Linux kernel by AMD this week?

Yes

sometimes I think my gnome shell is broken .-. right now it uses 23% of RAM. On a notebook with 16GB…

Well that's painful to think about

Well that's painful to think about

It wouldn't be such a big deal when you could just restart the gnome-shell in place but that's currently not possible when using Wayland x.x

Oh yeah, I forgot about that :/

do you know if there are problems with updates repository?

I get: Cannot download 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f27&arch=x86_64': Cannot prepare internal mirrorlist: file "repomd.xml" was not found in metalink. Error: Failed to synchronize cache for repo 'updates'

Hmm, I've found them to be a fair bit slow lately, but haven't had trouble accessing them alltogether, so I wouldn't be able to say.

Ok

Temporary issue, now it works

Hmm, I've found them to be a fair bit slow lately, but haven't had trouble accessing them alltogether, so I wouldn't be able to say.

Everyone's updating for that new vulnerability just disclosed

Ahh, I see.

Does Fedora balance between the cutting edge and stability? Another freedom-focused systems like Parabola, Devuan, Uruk, Debian, Trisquel, Parabola is rolling taking pride of the cutting edge and most recent security. In contrary, Devuan, Uruk, Debian stable, Trisquel are LTS to be stability focused, more than Fedora. Finally Debian testing, is like Fedora balancing between stability and most recent security, but unlikely Debian testing dsnt care cutting edge.

If you want cutting edge fedora you run rawhide, otherwise you get tested stable packages

Does Fedora balance between the cutting edge and stability? Another freedom-focused systems like Parabola, Devuan, Uruk, Debian, Trisquel, Parabola is rolling taking pride of the cutting edge and most recent security. In contrary, Devuan, Uruk, Debian stable, Trisquel are LTS to be stability focused, more than Fedora. Finally Debian testing, is like Fedora balancing between stability and most recent security, but unlikely Debian testing dsnt care cutting edge.

Of course. Fedora may be the Distro balancing this best.

Fedora is the best balance when it comes to Bleeding Edge and Stability, hands down.

Simple reason: Many things like libreoffice stay on the latest stable release unless that release is EOL - and gtk/gnome stay also updated but on the same major releases.

And of course, not only does Fedora test automated but it will also test on bodhi, where users can check for regressions and give a last warning that something broke.

https://bodhi.fedoraproject.org/updates/FEDORA-2018-22d5fa8a90