General Linux Chat and Small Questions v. Year of the Linux Desktop!

[Thelurker1234]

[QUOTE=deadeye536;50655982]I got an Arch VPS from Digital Ocean back in the early days when they still supported it. I still have it, but I had to work out some janky setup with kexec so it's not stuck on kernel 3.5. It's pretty stable, I've never had any unexpected downtime that was due to the OS.[/QUOTE]

I just finished getting a lot of it done, it's running really well, and ofc it was nice to be using an OS I was very familiar with rather than something like debian. It was fairly easy for me to get it going with vultr, I simply had to give an http link to the arch iso, and then I'd be presented with the installer.

I also locked myself out twice because while I did start sshd, I didn't enable sshd. Whoops.

[vlad]

is it possible to use both your iGPU and GPU at the same time in Linux? my second monitor is hooked up to my iGPU while my primary one is attached to my GPU. I would use my GPU only if I had the cables required. it only has a single DVI output and I have no adapters at the time being.

[SocMinarch]

[t]https://storage.gra1.cloud.ovh.net/v1/AUTH_cb7a5e3329844fd1a8ab7205fdc70060/public/images/borderlands/tps/dark.png[/t]

Getting closer to getting Borderlands TPS working on Fedora

[editline]6th July 2016[/editline]

It only launches if I run the binary through a terminal instead of through Steam, and it has lighting issues. Anyone know what's wrong?

[editline]6th July 2016[/editline]

Fixed by running with:

force_s3tc_enable=true ./BorderlandsPreSequel

Still doesn't work through Steam though

[lavacano]

Are you using regular wine or wine-staging

[editline]6th July 2016[/editline]

If you're using wine-staging, there will be a checkbox in winecfg to enable something called "CSMT". Try that.

[mastersrp]

[QUOTE=lavacano;50658253]Are you using regular wine or wine-staging

[editline]6th July 2016[/editline]

If you're using wine-staging, there will be a checkbox in winecfg to enable something called "CSMT". Try that.[/QUOTE]

It's native I believe.
[url]http://store.steampowered.com/app/261640/[/url]

[SocMinarch]

Yeah it's native. I fixed the lighting bugs but the game won't run through Steam, only through the terminal.

[BryBreadmin]

[QUOTE=Adam.GameDev;50658452]Yeah it's native. I fixed the lighting bugs but the game won't run through Steam, only through the terminal.[/QUOTE]

Does it have Steamworks integration or nah? If not you can just change the launch options for the game to be the same as launching it from the terminal (unless the steam overlay is what's breaking it, in which case you'll just have to disable that).

[SocMinarch]

Disabling the Overlay doesn't seem to have an effect unfortunately. I've been trying to get Steam to work without the Runtime but there's about three libraries that the Fedora repositories don't contain. I'll post them when able.

[BryBreadmin]

try setting your launch options for the game in steam to

force_s3tc_enable=true %command%

Steamworks (if it has any integration with that) should actually still work with this launch option.

Also what do you mean by getting steam to work without the runtime?

[SocMinarch]

Having Steam run with native Fedora libraries instead of Valve's Ubuntu chroot thing

[BryBreadmin]

Ah. Yeah good luck on that. Lemme know if that launch option works, though.

[SocMinarch]

Didn't work unfortunately. Running the game outside of Steam without that variable still worked, it just caused the above lighting issues.

[editline]7th July 2016[/editline]

I found the solution and all I can say is WHY DOES THIS FIX IT?

The terminal that showed Steam's output showed that LD_PRELOAD wasn't accepting gameoverlayenderer.so because it was the wrong ELF class, so I added:

LD_PRELOAD=~/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so %command%

to the launch options and for some reason it started working.

Adding the S3TC variable to it isn't necessary if you add it to your Steam launcher script

[editline]7th July 2016[/editline]

The custom launch options can be removed if the LD_PRELOAD stuff is added to the Steam launcher script too

[lavacano]

You see, that shouldn't be your problem, because Steam should just be trying to inject both the 32 bit and 64 bit shared libraries until one sticks. Which makes the fact that LD_PRELOADing it anyway does fix it even more confusing.

The only way that makes any damn sense to me is if Borderlands TPS got a shit port, and unless TPS isn't on the Unreal engine like it's siblings, I highly doubt that's the case, since the Unreal engine has native Linux support.

(Also, I forgot those had ports)

[SocMinarch]

Thought I'd switch my laptop to Fedora. openSUSE created a load of Btrfs snapshots for Snapper, so I cleared the partition table in cfdisk.

Turns out I cleared the partition table on the Live USB instead of the laptop. :suicide:

[AG]

Heya, could use some help if you don't mind real quick!
I tried booting a live CD into my current computer, but it would not boot unless legacy BIOS boot was enabled, but on my other computer it boots fine through UEFI. When installing the OS on this computer, should I set it up for UEFI boot or BIOS booting?

[AG]

[QUOTE=~Kiwi~v2;50663533]BIOS if you can't support EFI.
Strange though.
How old is this PC for it to not support EFI?[/QUOTE]

It's only 2 years old. Everything else works with it apart from this one OS, booting from the live CD

[AG]

[QUOTE=~Kiwi~v2;50663563]Have you tried a EFI USB of Windows?
Also what distributions have you tried?
Also are you sure(not doubting) using the UEFI boot option for said live session?

The fact that a 2 year old PC can't support EFI is nuts.

I have however heard of certain OEM manufacturers locking down their BIOS/EFI to only support 32 bit not 64 bit. So maybe try a 32 bit ISO with EFI.[/QUOTE]
Fedora and Mint work fine through EFI booting, whereas this Gentoo live won't even show a boot entry in the firmware interface or even display the drive itself to be able to boot from, but it does when legacy booting is enabled. I haven't tried booting Windows yet though.

[DrTaxi]

Properly creating boot media (especially since UEFI) can be a bit fiddly. Try using a different tool.

[Thelurker1234]

[QUOTE=AG;50663595]Fedora and Mint work fine through EFI booting, whereas this Gentoo live won't even show a boot entry in the firmware interface or even display the drive itself to be able to boot from, but it does when legacy booting is enabled. I haven't tried booting Windows yet though.[/QUOTE]

gentoo's live doesn't support uefi. You can install gentoo with any live USB though, as long as you have a terminal and GNU userland stuff.

[AG]

[QUOTE=thelurker1234;50663703]gentoo's live doesn't support uefi. You can install gentoo with any live USB though, as long as you have a terminal and GNU userland stuff.[/QUOTE]

oh alright, thanks!

[lavacano]

[QUOTE=AG;50663530]Heya, could use some help if you don't mind real quick!
I tried booting a live CD into my current computer, but it would not boot unless legacy BIOS boot was enabled, but on my other computer it boots fine through UEFI. When installing the OS on this computer, should I set it up for UEFI boot or BIOS booting?[/QUOTE]

Turn off secure boot and try that again.

[QUOTE=thelurker1234;50663703]gentoo's live doesn't support uefi.[/QUOTE]

Yes it does, it's had support for ages.

[larikang]

[QUOTE=Adam.GameDev;50659341]
I found the solution and all I can say is WHY DOES THIS FIX IT?

The terminal that showed Steam's output showed that LD_PRELOAD wasn't accepting gameoverlayenderer.so because it was the wrong ELF class, so I added:

LD_PRELOAD=~/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so %command%

to the launch options and for some reason it started working.[/QUOTE]

This is a really common problem with Steam on Linux. It has to do with the Steam runtime conflicting with system libs.
[url]https://wiki.archlinux.org/index.php/Steam/Troubleshooting#Steam_runtime_issues[/url]

I usually just delete the offending runtime files, but the problem is that Steam will re-download them occasionally when it updates. I've been trying to get the Arch packager to add a workaround to the steam script, but I think he might be dead or something.

[Looking4DatFk]

How do you know that you are not getting backdoored distro? Let's say Canonical's Ubuntu for example. It is a high value target that something like NSA would do anything to get into. How confident can we be that they are not sold out?

Now obviously a backdoor is not going to be shown in public source code but is going to be packaged into the official image installation file. I'm not saying like getting fed wrong image file by MITM or something, I'm more talking about Canonical itself packaging backdoor inside the image file, so don't mention hash integrity check - it is unrelated.

Only sensible way of detecting such a thing would be traffic sniffing but there are few things you have to take into account. It's not recommended to try to sniff your traffic from the same machine because in theory the interesting traffic could be hidden - since they are ones who gave you the OS, you need to sniff the data from a third-party device between you and your Internet. Second thing to consider is the fact that it can be extremely silent and only activated through remote command, therefore keeping almost complete network silence till then. It can be encrypted and/or made to blend in, in a lot of ways.

I'd like to learn about your opinions, ideas, observations, experiences, advices, etc. What do you think, how likely it is that at least one of the top 5 distro is backdoored right from factory? I don't know, maybe I'm missing something or overlooking something, I'm not Linux pro. Enlighten me if so.

Compiling everything from scratch is much safer alternative because open source code is less likely to contain any malicious code than an image file. Would you recommend doing this?

[ipha]

It's certainly possible, but to my knowledge it has never happened. Ultimately you give complete trust to any distro you use, and unless you audit the source yourself you're still blindly trusting the code if you compile from source.

Debian is working on reproducible builds as a way to prove that the packages they release match the source. If they added a back door it would rase a red flag that the package doens't match the source anymore.
[url]https://wiki.debian.org/ReproducibleBuilds[/url]

[Looking4DatFk]

[QUOTE=IpHa;50669117]It's certainly possible, but to my knowledge it has never happened.[/QUOTE]
I imagine it would be extremely hard to detect anyway.

[ipha]

[QUOTE=Looking4DatFk;50669147]I imagine it would be extremely hard to detect anyway.[/QUOTE]

I think it would be difficult to add a back door without anyone noticing and once it's noticed all credibility will be lost. I can think of a few ways adding a backdoor would backfire.

- Backdoor included in every installation:
* Someone working on the project would leak info about it
* There would have to be outgoing network traffic to a common group of servers. Some government/company/security researcher would notice this.

- Backdoor target to one individual:
* No guarantees on what mirror that person is using
* Would require cooperation with all mirrors, or one if you can pinpoint which mirror they're using.
* What if that mirror is in another country?

[Looking4DatFk]

[QUOTE=IpHa;50669264]
* Someone working on the project would leak info about it
[/QUOTE]
You need to buy out few key people only.

[quote]* There would have to be outgoing network traffic to a common group of servers. Some government/company/security researcher would notice this.[/quote]
As I said, it could be silent till activated remotely, they obviously wouldn't want every random Linux enthusiast to send them data. After that traffic could be heavily concealed. Heck, it is even possible to send data by innocent DNS requests by right timing, etc.
You can't rely on things because "someone would notice it". There has been a lot of cases in past where no one noticed shit, and I'm not talking about some microcode backdoors or things that are heavily concealed.

[ipha]

[QUOTE=Looking4DatFk;50669456]You need to buy out few key people only.

As I said, it could be silent till activated remotely, they obviously wouldn't want every random Linux enthusiast to send them data. After that traffic could be heavily concealed. Heck, it is even possible to send data by innocent DNS requests by right timing, etc.
You can't rely on things because "someone would notice it". There has been a lot of cases in past where no one noticed shit, and I'm not talking about some microcode backdoors or things that are heavily concealed.[/QUOTE]

For a computer behind NAT(just about every one) it can't be activated remotely without maintaining a connection or occasionally polling for instructions.

[Looking4DatFk]

[QUOTE=IpHa;50669636]or occasionally polling for instructions.[/QUOTE]
You don't need to poll information from nsa.gov directly, you can conceal the pattern. You have awful lots of data going in and out, they are all instruction vectors.
You can also give it big intervals and do it when there is a lot of flow.

[vlad]

ugh, monitors in linux are annoying. apparently you can't use two monitors via iGPU and GPU if you're on the official nvidia drivers. nouveau on the other hand allows this but Pascal support is currently non existent. I don't expect them to support it any time soon. stuck with a single monitor for linux stuff for now then

[editline]8th July 2016[/editline]

decided to go Plasma this time around too, very nice DE to be honest. looks both modern and sleek compared to KDE4