WARNING: YOU ARE *ROOT* WHEN YOU INSTALL SOFTWARE.

Do you trust the scripts microsoft puts in the package to run post install?

Remember when they changed your shell? https://www.preining.info/blog/2018/06/microsofts-failed-attempt-on-debian-packaging/

View this comment - View article - View full comments

Quoting: natis1

Quoting: Guest

Quoting: ShabbyXI'm glad they realized they lost this war, and now the poor people that trust microsoft have a working browser. If only they'd realize the same with NT and switch windows's kernel to Linux

They didn't make edge chromium based because they thought chromium was better. They were "forced" to because google was changing how youtube displays videos, which broke hardware decoding.

I can't find anything on this specifically but I'm guessing you are talking about the youtube switch to vp9 from avc. If so I will say, a website using free codecs that are part of the w3c standard instead of patented ones that aren't is a good thing always.

This, and also, edge was just garbage with video anyway. For example, you couldn't do video calls in facebook with it. My aunt who like most people have always gone with windows default even installed Chrome because of that. So obviously Edge just didn't cut it and they were losing users, so microsoft decided to do the easy thing and rebrand an open source browser.

View this comment - View article - View full comments

Windows notifications before Edgium: Edge is better than Chrome, Google said so, you should switch, seriously.

Then goes ahead and becomes a skin over Chromium. So desperate, they'd do anything to keep people tied to their microsoft id (instead of google id).

I'm glad they realized they lost this war, and now the poor people that trust microsoft have a working browser. If only they'd realize the same with NT and switch windows's kernel to Linux. Imagine so many people getting fast I/O for once in their life.

View this comment - View article - View full comments

Quoting: Comandante ÑoñardoSo...
I guess it is possible to run background system processes in one core and games/apps processes in the other core...

That's already possible! Look for isolcpus. There must be some more dynamic options available too.

View this comment - View article - View full comments

Quoting: ShmerlBasically, don't rush to buy it, until someone (Intel I assume?) will add such scheduler for Linux (if you are even considering it). In general Intel are good at doing it though so it should appear at some point.

Linux has been doing this for years for big.LITTLE, asymmetric multiprocessing is nothing new for Linux.

View this comment - View article - View full comments

Quoting: SalvatosDue to "appropriate controller input icons" alone, I feel like a lot of games will fall short of Verified. I rarely see the right icons for my DualShock.

Same with me, but note that they need the game to show the Deck's icons correctly (i.e. xbox icons), not all controllers!

View this comment - View article - View full comments

Quoting: Arehandoro

Quoting: robvv

Quoting: ArehandoroNo different to the fact that if Steam were to go bust all our games would not work either, not downloadable.

Assuming that you have many of your games already downloaded, they will still work just fine (except some Feral titles). Some may require the Goldberg emulator to run but that's about it.

Without Goldberg Emulator after a giving time you wouldn't be able to log in to Steam, and not all games work directly with the executable without Steam. Not counting all the features integrated that games have that rely on Steam.

If Steam shuts down, I have no doubt some open source project will spring up and implement the API. People won't just let so many games go to waste.

View this comment - View article - View full comments

Speaking of wasteland, I just started playing Wasteland 2 (DC) for the first time since a few weeks ago. Damn it's a good game!

View this comment - View article - View full comments

Quoting: 3zekieleventfd is actually efficient enough for its purpose I would expect. But the issue is, the inner counter is - by spec - maintained by the kernel. So it means many round trips between kernel and user space ... Which will limit perf, and I guess that is why you can not just poll it as much as you want. And that is the syscall spec, can't do much about it.
Futexes on the other hand were made so that you only go to kernel space if you can not take the lock ownership/if the semaphore is at 0 (basically a yield). So you have much less round trips with futexes. They are also stored as a simple `intptr` (an address) whereas eventfd looks like that:
struct eventfd_ctx {
struct kref kref;
wait_queue_head_t wqh;
/*
 * Every time that a write(2) is performed on an eventfd, the
 * value of the __u64 being written is added to "count" and a
 * wakeup is performed on "wqh". A read(2) will return the "count"
 * value to userspace, and will reset "count" to zero. The kernel
 * side eventfd_signal() also, adds to the "count" counter and
 * issue a wakeup.
 */
__u64 count;
unsigned int flags;
int id;
};
From the look of it, eventfd will be more real time (you will wake up as soon as something happens if you have the priority), whereas futex side, you will wake up at your next quantum clearly (I only see mechanism unsuspending you, nothing scheduling you). Futexes also do not hold a list of who is waiting, they are just a counter. So the first one who comes and retake the lock wins seems. It's coherent since the scheduler is fair anyway.
So I would say, they just fill purposes that are orthogonal. I would typically use eventfd for IO related waits, or if I need something a bit more real time. And futexes for all the rest.

Ack. I don't know eventfds well enough to actually have a proposal to improve it. But agreed, having futexes go through the kernel unconditionally is completely in contradiction with them being futexes, so a new syscall is reasonable.

View this comment - View article - View full comments

Quoting: 3zekielShort answer: they kinda already tried that at first, and judged it to be a dead end.

Fair enough.

Quoting: 3zekielLong answer:
Modifying an existing (set of) syscall(s) is extremely limited. You can not break compatibility in any way, since that would break thousands of apps, with no way for users to fix it. Contrary to libraries, you can not just install another kernel, or use a lightweight container to fix a kernel ABI breakage. So all issues with that syscall set are pretty much set in stone.

Sure, but that doesn't mean you cannot provide the same functionality more efficiently. The point was eventfd doesn't scale, and making that scale doesn't necessarily have to interfere with its functionality.

Quoting: 3zekielMore generally, it seems more natural and clean to use a tool that is actually made to fix your issue. File descriptors (which eventfd is based on) are made to deal with file-like stuff (that's a lot of stuff in Linux). Futexes are made to deal with synchronization issues. Futexes are also made to be used in large numbers, file descriptors... not that much (the overhead in memory and so on).

Everything is a file. In fact the few things that Unix didn't make a file turned out to be the most problematic areas (pids and signals notably). At least the pid problem is remedied with fds (pidfd), and if signals aren't already, I'm sure they will be turned into fds too.

I said all that to say that given how central fds are, it's worthwhile to make sure eventfd is actually efficient, rather than keep trying to work around it.

View this comment - View article - View full comments