tal

The above text says that the aim is to do RDMA, to let the NIC access memory directly, but I'd think that existing Linux zero-copy interfaces would be sufficient for that.

https://en.wikipedia.org/wiki/Zero-copy

The Linux kernel supports zero-copy through various system calls, such as:

• sendfile, sendfile64;[9]
• splice;[10]
• tee;[11]
• vmsplice;[12]
• process_vm_readv;[13]
• process_vm_writev;[14]
• copy_file_range;[15]
• raw sockets with packet mmap[16] or AF_XDP.

So I'd think that the target workload has to be one where you can't just fetch a big chunk of pre-existing data, where you have to interject server-generated data in response to small requests, and even the overhead of switching to userspace to generate some kind of server-generated response is too high.

Which seems like a heck of a niche case.

But it obviously got approval from the kernel team.

googles

https://www.kernel.org/doc/html/next/filesystems/smb/ksmbd.html

The subset of performance related operations belong in kernelspace and the other subset which belong to operations which are not really related with performance in userspace. So, DCE/RPC management that has historically resulted into number of buffer overflow issues and dangerous security bugs and user account management are implemented in user space as ksmbd.mountd. File operations that are related with performance (open/read/write/close etc.) in kernel space (ksmbd). This also allows for easier integration with VFS interface for all file operations.

I guess you could accelerate open and close too.

In all seriousness, I feel like if you're in such a niche situation that you can't afford the overhead of going to userspace for that, (a) there's likely room to optimize your application to request different things and (b) CIFS might not be the best option to be sharing data over the network either.

There have been vulnerabilities on the TCP/IP stack on a number of platforms (maybe all?), and that's a rather smaller attack surface.

EDIT: It also looks like ksmbd has already built itself a bit of a security history:

https://access.redhat.com/solutions/6991749

EDIT2: A bad security history:

https://lwn.net/Articles/871866/

The commit history for ksmbd shows a steady stream of fixes, as expected. Worryingly, though, many of the problems being fixed are clearly security issues — not a good thing in a network filesystem implementation. Examples include:

• The code to change ownership and permissions did not check existing file permissions first.
• Failure to validate data lengths could lead to access to invalid data.
• The server would blindly follow symbolic links during pathname lookup.
• Numerous failures to validate buffer lengths, such as this one or this one.

All of those fixes were applied after ksmbd landed in the mainline; there are others that came before. Currently, twelve fixes to ksmbd credit Coverity scans in their changelogs.

Those would worry me if they showed up in a production userspace network filesystem.

[continued from parent]

• Temperature. I know that Disney's done some things like have water jets that spray at people for their rides. I imagine that someone could rig something up with a computer-controlled heater/air conditioner, make a cave in-game feel cool and clammy. Kind of hard to both set up in arbitrary places and get a common experience across people. There have been people playing with using thermocouples for VR.

• Scent. Again, I recall reading that Disney worked on incorporating this into Fantasia presentations many decades back. I suppose that one could have some kind of device that kept a bank of essential oils and then could mist a given set, though I think that how long it lingered would depend a lot on the surrounding environment. Maybe if you had some kind of vent by the nose or something that passed air directly by the face. There are apparently companies trying to sell devices to do this sort of thing.

• Motion simulators exist, can be used for stuff like flight sims, but I think that the price point is probably going to remain too high for them to really take off for the mass market.

I mean, in theory, I could imagine someone writing some kind of software layer that cleverly abstracts all these sorts of systems, has games drive events. But in practice, I've been watching external devices that aim to provide a new source of sensory input come out for a long time, and they have pretty depressingly and consistently failed to take over the market.

I think that realistically, in terms of having many games providing sensory input to people, it's gonna be the display and audio, and maybe VR headsets for the foreseeable future.

Maybe as stuff like OpenRGB becomes more standard we could also see that tied into game/music events more as well

That's possible, though I should note that control of external lighting has been around for a while, and we haven't really seen it become a standard thing in games. I think that the problem is less lack of a protocol and more that similar configurations aren't commonly available or that people don't feel that there's a great way to incorporate it into games. And it's not even specific to lighting, but to devices other than the monitor and speakers that provide some kind of sensory input to people. After all these years, the norm is still:

1. You can see what's on the display.

2. You can hear what the speakers play.

For the lifetime of the personal computer, maybe fifty or sixty years at this point, the only real change in the norm has been for fidelity improvements to what's on the display and fidelity improvements to what's playing though speakers (well, headphones more-frequently these days). And people have tried a lot of things.

• I'd guess that keyboard backlighting is one of the more-common things, and it doesn't get used much.

• Monitor bias lighting has been around for a while.

• RGB LEDs on the PS5 controller are standard, but I don't own a PS5, so I dunno how commonly they're made use of.

• DMX512 is a standard for hooking up stage lighting devices like strobes and spotlights and colored lighting and smoke machines and stuff -- you'd use it to drive stuff like live performances, lightshows at clubs, stuff that runs in time with music like this. USB-to-DMX512 transceivers are pretty affordable, and Linux can handle them.

• Multiple monitors. That's seen some uptake in flight sims (though I think that VR headsets will displace that), but outside of that, doesn't seem to have really caught on. And it's a (moderately) expensive way of doing things.

• You can get external small displays, of the sort that Matrix Orbital sells. Logitech tried incorporating them into "gaming keyboards" with integrated miniature displays for a while; it looks like they dropped that in 2013, with the G19s. There have been a few games that have had uptake. It did not take off.

• Various forms of 3D displays coupled with glasses did not do very well.

• VR headsets. We'll see where this goes. I remember an earlier VR headset craze back towards 2000 that didn't seem to take off, and I'm not sold that the current one is going to become the norm either. Though at least in terms of sensory input to your eyes, that can (given sufficient brightness, contrast, resolution, etc) replace all the other visual stuff here. If I had to bet on one external sensory device becoming the norm in the next decade, I'd bet on VR headsets, and I'm honestly not that bullish on even them. Maybe if they become cheaper and higher-resolution. I will say that I think that they pair well with laptops, since they address the limited screen size well.

• Technically, there have been some changes in speakers that have met with some level of uptake, but none have become the norm. You have things like chairs with backrest-mounted subwoofers or surround sound.

• Tactile feedback touchpads.

• Force feedback -- not simply rumble motors that use offset-weight motors, which is what I think a lot of people think of when they think of force feedback -- doesn't seem to me to be very healthy. Used to be that there were joysticks that simulated the resistance in pre-fly-by-wire aircraft, like the Microsoft Sidewinder Force Feedback Pro, but those seem to have fallen out of fashion. There are still some steering wheels that provide resistance in response to driving. The PS5 controller has, as I understand it, voice-coil actuators and mechanical resistance on the triggers. But in general, I feel like force feedback has been something where people have talked about potential for a long time, but which hasn't really become the norm.

• Rez famously came with a vibrator; these days, buttplug.io is a FOSS layer that can drive a bunch of sexual stimulation hardware (not, despite the name, just buttplugs). That's had some game uptake, but it's pretty limited. People have been working on computer-controlled sex devices since the mid-1970s, and it still hasn't become the norm.

[continued in child]

It looks like people have run WINE under Cygwin, so barring Cygwin-introduced compatibility issues, Windows can use the same compatibility layer.

I like the idea of both the game influencing the music and the music influencing the game.

Like, you have a directed graph of music, with audio on the edges, and the current game state determining which edge one takes out of a node. The game influences the music there.

But then you also have an "event track" on the edges that can be used to do cosmetic things like flash lights in the game or whatnot in time with the music, or, as with rhythm games, require the player to do things in time with the music. There, the music influences the game.

That ratio doesn't matter.

What matters is the value derived from some prohibited activity relative to the fine/lawsuits resulting from that activity.

Let's say that Company A sells oranges, and uses some pesticide that isn't approved, and gets a fine for it.

Let's say that Company B sells apples, and improperly claimed that the apples were fresher than they were to grocery stores and is sued for that.

Let's say that Company A and Company B merge and form Company C. The value of Company C would be larger, but it would make no sense for either of the above two disincentives to be larger. Being part of Company C doesn't make engaging in bad behavior more-desirable than it does for when A and B were separate, and so the disincentives one establishes for bad behavior shouldn't grow either.

If you merge CLIPBOARD and PRIMARY, every time you select text, you'll wipe out the contents of CLIPBOARD. You won't be able to copy text, then do any work that involves selecting text, then paste.

What’s a mongrel?

It's a non-purebred dog. Which, amusingly, tend to have fewer health problems than purebreds.

Right, which is why I favor the 100Wh battery.

I want a big, swapable battery that uses 18650 cells,

I mean, me too. I think that having less than a 100 Wh battery is nuts, but it's essentially impossible to find them.

I think that a couple of things have killed this:

• Cost. Cutting battery size is an easy way to cut cost, and it's less-explicit than, say, cutting RAM, as vendors often list a non-standardized "hours of battery life".

• USB PD plus external power stations. I think the expectation is that one will get one and having the user just use external ports makes life easier for the vendor and means that they don't need to deal with counterfeit batteries and such. Also moves heat out of the laptop. I would be more sympathetic to this if there were a standard for a laptop to start automatically drawing from an external USB powerstation when its internal battery gets low, rather than requiring manually-triggering charging.

• Weight. Apparently some people are super-rabid about laptop weight.

When talking about computers, it was always 1024.

The problem is that each time you go up another unit, the binary and decimal units diverge further.

It rarely mattered much when you're talking about the difference between kibibytes and kilobytes. In the 1980s, with the size of memory and storage available, the difference was minor, so using the decimal unit was a pretty good approximation for most things. But as we deal with larger amounts of data, the error becomes more-significant.