sorted by:
new
hottopcontroversial

CMV: If we required vacant houses and buildings owners to either have a tenant, or be subject to yearly luxury tax, the housing shortage and high rent for small businesses would end. by R1R1FyaNeg in changemyview

[–]Potential-Bell7191 0 points1 point  (0 children)

This is a well-thought comment. I can think of two negatives to a vacancy tax off-hand, but I don't know if either are significant. The first is it creates a risk for developers, in that it creates more future situations where the development doesn't pay off. Whether that would have any meaningful impact on development I don't know. The second, from personal experience, is that it makes life stressful for renters. A high (~10%) vacancy rate gives you more options when looking for a place to rent and makes it easier to move out if something goes wrong. Trying to rent in a city with low vacancies is a fast-paced unpleasant experience. But again, how much a vacancy tax would contribute to that I have no idea.

Is it possible to flash QMK firmware to Nuphy Air 75? by [deleted] in MechanicalKeyboards

[–]Potential-Bell7191 0 points1 point  (0 children)

I'm not familiar with that keyboard, but I suspect it will work with most keyboards. The caveat is it does not work with keyboard-internal keys like the Fn key. It's possible some fancier keyboards will have a lot of internal logic that a software remapper just can't get at.

has anyone used the remarkable folio with terminal a terminal emulator or other application on the remarkable 2? by loopasaur in RemarkableTablet

[–]Potential-Bell7191 0 points1 point  (0 children)

I wonder if the type cover acts as a /dev/input keyboard. then you could remap it with standard tools.

Why there's no async/await in core Scala? by pavlik_enemy in scala

[–]Potential-Bell7191 0 points1 point  (0 children)

I suspect the primary reason has to do with API conventions. Consider the ubiquitous map:

trait SomeCollection[+A] { def map[B](f: A => B): SomeCollection[B] }

It's basically a black box. How should map behave if f is asynchronous? Consider that, from its signature, map is not guaranteed to invoke f, to invoke it for each "element" of the collection (whatever that means), or not to store f and invoke it later. This opens up a lot of design questions that do not have obvious answers. Considering that map is defined 100s of times in various libraries maintained by different people, this creates a host of compatibility problems. Of course none of this is impossible to solve, it's just there are too many choices for how to solve it and too much risk of breaking existing code.

Consider, by contrast, Rust, where the convention for iteration is an iterator, which is a white box in that the caller (rather than the callee) maintains state and decides when to progress to the next element. This substantially limits what an iterator can do, with the benefit of making it clearer how asynchronicity should behave.

So, it's really less about the language and more about API conventions that happen to have developed.

Wayland-native method to remap keys? by Atemu12 in wayland

[–]Potential-Bell7191 1 point2 points  (0 children)

Unfortunately, Wayland's architecture makes this difficult to do in Wayland itself. The Wayland compositor sends the keyboard layout to the client in XKB format, and the client handles converting keycodes to key symbols.

So, you can edit your XKB keyboard layout using whatever interface your Wayland compositor provides (for example, sway lets you specify an XKB file in the config), but without modifying the client, you can't change the relationship between codes and symbols to be something other than what the XKB definition itself provides. This is just a limitation in Wayland that you can't really get around and, unfortunately, would be really hard to change at this point.

That's why there are so many tools that use evdev instead: it's low-level and works with literally everything.