Our great sponsors
-
ExpansionCards
Reference designs and documentation to create Expansion Cards for the Framework Laptop
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
ripgrep
ripgrep recursively searches directories for a regex pattern while respecting your gitignore
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
I wrote a general purpose multitouch daemon w/ gesture support for Linux that works with the existing input stack (i.e. doesn’t require switching to evinput), if anyone is interested:
https://neosmart.net/blog/2020/multi-touch-gestures-on-linux...
https://github.com/mqudsi/syngesture
have you looked at the https://frame.work/ laptop? dunno about palm detection but its centered like the macbook
I use both OSX and Linux extensively. I had the choice to go either way for my work computer and I chose OSX (intel chip).
A couple of days ago I wanted to use a Ruby gem ( https://github.com/rubyjs/therubyracer ) for some random project. To install the library (compile native bindings), OSX wanted me to download an install 12 GB of crap (full XCode, it didn't work with the command line tools)... In linux it was just a matter of downloading and installing the gem (100MB at most). That's crazy.
What I dislike more and more about OSX is how they have been aggresive against developers and technical people in the last years (like, why do I have to jump through hoops to modify my /usr/lib folder with SUDO/root? I AM ROOT ASSHOLE OS, LET ME DO WHATEVER I WANT TO MY COMPUTER.
But other than that, it's OK.
>The GNU coreutils are still the very best you can get.
I don't understand this statement then, have you heard of this https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md
It sounds like you want bash POSIX support and it to be default before you would use them. The error nobody else replicated, and its stable enough to be included in debian. https://news.ycombinator.com/item?id=29456115#29462180
There was a Gtk backend for Qt which would have solved this: https://github.com/CrimsonAS/gtkplatform
FWIW I've (mostly) moved from Mac to Linux for around a year now & decided on elementary OS which has Mac as a primary influence: https://elementary.io
I don't like everything about it but it has been the most usable/value-aligned Linux distro I've encountered so far.
>Creating a "standardized experience" like Windows usually means that configurability goes right out the window. It's how you get abominations like dconf or the GNOME music player
I don't understand how you connected these dots and I'd suggest against calling things abominations. You don't have to use dconf or the GNOME music player, those aren't standardized. If someone does like them I think they're perfectly fine, they do exactly what they're advertised to do. It's also fine if you don't like them, they're just two options from the many configuration databases and media players that you can choose from.
>But why shouldn't I be able to run xbindkeys or sxhkd or whatever hotkey dameon I want?
In some ways you actually can but it depends on the hotkey daemon and how it's implemented. The reason for that is technical, those are implemented with X grabs which have a number of usability and security issues. There are a few key rebinding daemons that use evdev directly so they work with Wayland:
https://github.com/samvel1024/kbct
https://github.com/snyball/Hawck
But these also do have similar security issues to X key grabs, in that they effectively operate as keyloggers. If you're looking for an API that works purely within Wayland and lets unprivileged clients request key rebinding, that doesn't exist yet. Somebody would need to specify what that API looks like and figure out a good way to make it secure. What would the end goal of the API be, and how could the system (and by extension, the user) tell the difference between a legitimate hotkey daemon and a malicious keylogger? And would it actually be any better than the approach of snooping evdev? I don't know the answer to these questions but you may have more experience with this than I do.
>Creating a "standardized experience" like Windows usually means that configurability goes right out the window. It's how you get abominations like dconf or the GNOME music player
I don't understand how you connected these dots and I'd suggest against calling things abominations. You don't have to use dconf or the GNOME music player, those aren't standardized. If someone does like them I think they're perfectly fine, they do exactly what they're advertised to do. It's also fine if you don't like them, they're just two options from the many configuration databases and media players that you can choose from.
>But why shouldn't I be able to run xbindkeys or sxhkd or whatever hotkey dameon I want?
In some ways you actually can but it depends on the hotkey daemon and how it's implemented. The reason for that is technical, those are implemented with X grabs which have a number of usability and security issues. There are a few key rebinding daemons that use evdev directly so they work with Wayland:
https://github.com/samvel1024/kbct
https://github.com/snyball/Hawck
But these also do have similar security issues to X key grabs, in that they effectively operate as keyloggers. If you're looking for an API that works purely within Wayland and lets unprivileged clients request key rebinding, that doesn't exist yet. Somebody would need to specify what that API looks like and figure out a good way to make it secure. What would the end goal of the API be, and how could the system (and by extension, the user) tell the difference between a legitimate hotkey daemon and a malicious keylogger? And would it actually be any better than the approach of snooping evdev? I don't know the answer to these questions but you may have more experience with this than I do.
Intel's compute features are in a separate open source package called Intel Graphics Compute Runtime.[1] Integrated graphics from 2014 (Broadwell) and later are supported. Support for discrete graphics (2020 onward) is in development.[2]
AMD provides an open source OpenCL solution for Linux called ROCm, but the project is too limited to be helpful in many use cases. ROCm supports a total of 6 GPU models, all from previous generations,[3] and does not support GUI-based software applications.[4]
[1] https://github.com/intel/compute-runtime
[2] https://github.com/intel/compute-runtime/issues/469#issuecom...
[3] https://rocmdocs.amd.com/en/latest/Installation_Guide/Instal...
[4] https://github.com/RadeonOpenCompute/ROCm/issues/1397
Intel's compute features are in a separate open source package called Intel Graphics Compute Runtime.[1] Integrated graphics from 2014 (Broadwell) and later are supported. Support for discrete graphics (2020 onward) is in development.[2]
AMD provides an open source OpenCL solution for Linux called ROCm, but the project is too limited to be helpful in many use cases. ROCm supports a total of 6 GPU models, all from previous generations,[3] and does not support GUI-based software applications.[4]
[1] https://github.com/intel/compute-runtime
[2] https://github.com/intel/compute-runtime/issues/469#issuecom...
[3] https://rocmdocs.amd.com/en/latest/Installation_Guide/Instal...
[4] https://github.com/RadeonOpenCompute/ROCm/issues/1397