Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oasis – a small, statically-linked Linux system

github.com

Post reply on HN
Print view View original

281–288 of 288 posts

Re: Oasis – a small, statically-linked Linux system

#281

Post by raesene9 »

znpy wrote: post #27
raesene9 wrote: post #21

Earlier quoted context omitted.

A small point on that last bit. The bearssl authors are pretty conservative when it comes to development milestones, I'd guess that their 0.6 would be pretty solid :)

> I'd guess that their 0.6 would be pretty solid :) Would you accept that kind of reasoning for software running on your pacemaker, or on your insuline pump? I think we should respect the developers here: they're not claiming production quality level (they're claiming beta-quality level) so it's not correct to use that library in any kind of product and claim any kind of production-level quality.

If you go by version number and anything any of the dependency files for large software products which are often used in produciton, they might cause you some concern...

https://github.com/kubernetes/kubernetes/blob/master/go.mod for one obvious example.

Re: Oasis – a small, statically-linked Linux system

#282

Post by TimeBearingDown »

soulofmischief wrote: post #269
TimeBearingDown wrote: post #248

Earlier quoted context omitted.

I’m pretty sure GPU passthrough does work in Qubes HVMs, although I haven’t tried it myself. Here are three quick and recent tutorials I found including one with a newer VirtualGL approach that offloads work instead of passing the entire card. https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html https://forum.qubes-os.org/t/nvidia-gpu-passthrough-into-lin... https://forum.qubes-os.org/t/seamless-gpu-passthrou…

Does this fix the Code 14 issue with NVIDIA cards? That is why I had to switch to KVM back in 2016, as KVM has support for bypassing NVIDIA's "bug" which prevents using consumer cards in a virtual environment. I have been away from Qubes for 7 years now so I'd hope some form of improvement has been made.

Are you referring to Code 43?

I believe the NVIDIA drivers after version 465 may not have this issue.

Here’s a report of this working on Qubes/Xen: https://forum.qubes-os.org/t/qubes-gpu-passthrough/661/12

However you may need to hide the virtualization from some games or other software, where Qemu/KVM can be more flexible.

There’s a project and some discussion to use these with Qubes, but it’s early days: https://github.com/nrgaway/qubes-kvm-dev

https://forum.qubes-os.org/t/porting-qubes-to-hypervisors-ot...

Re: Oasis – a small, statically-linked Linux system

#283

Post by TimeBearingDown »

Qwertious wrote: post #256
TimeBearingDown wrote: post #250

Earlier quoted context omitted.

One more, site won’t let me edit. https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html

That's the same as the first link in your previous comment. Did you manage to edit it after all?

Yes, thank you.

Re: Oasis – a small, statically-linked Linux system

#285

Post by soulofmischief »

TimeBearingDown wrote: post #282
soulofmischief wrote: post #269

Earlier quoted context omitted.

Does this fix the Code 14 issue with NVIDIA cards? That is why I had to switch to KVM back in 2016, as KVM has support for bypassing NVIDIA's "bug" which prevents using consumer cards in a virtual environment. I have been away from Qubes for 7 years now so I'd hope some form of improvement has been made.

Are you referring to Code 43? I believe the NVIDIA drivers after version 465 may not have this issue. Here’s a report of this working on Qubes/Xen: https://forum.qubes-os.org/t/qubes-gpu-passthrough/661/12 However you may need to hide the virtualization from some games or other software, where Qemu/KVM can be more flexible. There’s a project and some discussion to use these with Qubes, but it’s early days: https://gi…

Yes sorry, I meant 43. It's been a long time :)

> However you may need to hide the virtualization from some games or other software, where Qemu/KVM can be more flexible.

How prevalent is this? Is it basically just multiplayer games employing anticheat?

Re: Oasis – a small, statically-linked Linux system

#286

Post by jcelerier »

palata wrote: post #279
jcelerier wrote: post #276

Earlier quoted context omitted.

> Well you build OpenSSL as a static library, and you use that... I mean yes that's what I do but see my comment, I was asking specifically about dynamic linking mentioned by the parent (OpenSSL is definitely a "core library") > I think there is fundamentally no way (and that's by definition) to support two explicitly incompatible versions in the same build. Yes, that's my point - in the end static linking is the onl…

I strongly believe that developers should not ship across an array of distros. First because you probably don't test on them all. Really, that's the job of the distro/package maintainers. As a developer, you provide the sources of your project. If people want to use it on their respective distro, they write and maintain a package for it, or ask their distro maintainers to do it. That is the whole point of the distro!

Well, I completely disagree. I have a fair amount of users on a wide array of distro who are non-technical - just users, they wouldn't know how to compile something let alone write a distro package. They still deserve to be able to use the software they want without having to change OS.

> or ask their distro maintainers to do it.

This only works if you're using a rolling-release distro. You can't get new packages in the repos of Ubuntu 20.04, Suse Leap, Fedora 30 or Debian Bullseye.

Re: Oasis – a small, statically-linked Linux system

#287

Post by ghotli »

raverbashing wrote: post #232
NewJazz wrote: post #71

Earlier quoted context omitted.

malloc performance is still sub-par IMO. It is not nearly as terrible as it was, but scudo, memalloc, and glibc's malloc are better.

Yeah, and with glibc you can even LDLIBRARY an alternative glibc, not so much with musl (unless it changed recently)

I make statics usually so this sort of just never comes up. If I wanted another malloc it would just be linked in at compile time like the rest.

Re: Oasis – a small, statically-linked Linux system

#288

Post by trealira »

Koshkin wrote: post #117
sigsev_251 wrote: post #6

Earlier quoted context omitted.

Michaelforney has also built croc [1], a qbe based C compiler. Really impressive! [1]: https://github.com/michaelforney/cproc

Not as "impressive" as TCC, I'd say. Why? TCC has its own backend, and it has the preprocessor built in. (But QBE is indeed impressive.)

The assembly generated by cproc is more efficient than that generated by TCC, which is not great.
Post reply on HN