Atemu

joined 4 years ago
MODERATOR OF
[โ€“] Atemu@lemmy.ml 2 points 1 month ago

This has not been the case for at least a year or so thanks to graphics pipeline libraries.

Shader comp also only really manifests in frametime spikes, not generally high average frame times.

[โ€“] Atemu@lemmy.ml 2 points 1 month ago

Snaps are ๐Ÿ‘Œ

Such an obvious feature in retrospect. I added !ddgr to DDG back when I used it because reddit-exclusive results were so commonly useful but adding a bang for each and every website twice does not scale. (I don't need to do that very often these days due to Kagi's personalised ranking but it still happens.)

I wish snaps would stay in the @ syntax though as that'd make them much easier to edit. Perhaps that could be added as an option as it does hurt discoverability a little. @kagihq@mastodon.social

[โ€“] Atemu@lemmy.ml 2 points 1 month ago (4 children)

I'm a bit apprehensive towards LLM-generated things in general but I also use this from time to time when I just want a simple fact or get a feeling of whether the page is at all worth visiting.

I limit myself to facts that are trivial to verify or should be very hard for an LLM to get wrong.

If I need to look up some function for example, I'd very quickly find out if it's just hallucination. I also expect them to return the right thing if I expect the result to statistically be the most common thing.

Though if I'm being honest, I'd probably prefer a function to just get an expanded preview with the entire preview text offered by the website for this use-case (or an equivalent plain text extract from the website).

[โ€“] Atemu@lemmy.ml 2 points 1 month ago

The most important features when handwriting IMHO are selection tools and then being able to manipulate the selected strokes.

Write implements a multitude of selection tools such as lasso which most tools have but much more useful to me were ruled selection which selects based on lines on a ruled paper and path selection which selects every stroke you touch with your selection stroke.

You can then move the selected strokes in a ruled manner, so for example I'd select a whole line of strokes and move them down a few lines. This is incredibly useful and brings many of the freedoms we enjoy in editing text on a computer to handwriting.

Re-flowing using stroke divisors is an amazing feature in theory but I've never been able to make it work reliably enough for my purposes, so I personally disabled that particular feature.

The undo/redo dial is also pretty neat.

Once you actually try to take real notes or solve some mathematical problems, you'll really come to appreciate such features and will dread using any note taking application supposedly made for handwritten notes that does not implement such features.

[โ€“] Atemu@lemmy.ml 1 points 1 month ago

While that's certainly true, using NixOS usually does not involve many advanced concepts or requires you to understand them.

You can set foo = bar in a .conf file without knowing what a variable is either.

[โ€“] Atemu@lemmy.ml 1 points 1 month ago (2 children)

I don't know about rnote but Xournalpp was very underwhelming when it came to actual handwriting features back when I tried it.

[โ€“] Atemu@lemmy.ml 2 points 1 month ago

It was an old Fujitsu Q755, not something I'd recommend you buy.

Had a wacom tablet built into the touch screen though which is the only thing I'd watch out for.

[โ€“] Atemu@lemmy.ml 3 points 1 month ago (2 children)

(nixos more or less requires you understand programming syntax for writing your system config)

It's technically not a real programming language but an expression language. The difference is that the former is a series of commands to execute in the specified order to produce arbitrary effects while the latter is a declaration of a set of data. You can think of it like writing a config file i.e. in JSON format.

The syntax isn't really the hard part here. You can learn the basics that comprise 99% of Nix code in a few minutes.
The actually hard part is first figuring out what you even want to do and then second how the NixOS-specific interface for that thing is intended to be used. The former requires general Linux experience and the latter research and problem solving skills.

[โ€“] Atemu@lemmy.ml 3 points 1 month ago

Because the only way to have a functioning NixOS system is to have it be reproducible. That's the only way it works; Nix is reproducible by design.

The ability to reproduce a system implies the ability to replicate it.

[โ€“] Atemu@lemmy.ml 3 points 6 months ago

This should allow ~~average~~non-technical users to keep up with development, without reading Github comments or knowing how to program.

;)

[โ€“] Atemu@lemmy.ml 10 points 6 months ago

Your browser cannot block server-side abuse of your personal data. These consent forms are not about cookies; they're about fooling users into consenting to abuse of their personal data. Cookies are just one of many many technological measures required to carry out said human rights abuse.

[โ€“] Atemu@lemmy.ml 1 points 6 months ago (1 children)

Do you have a better source than a 5 y/o comment in an issue?

 

cross-posted from: https://lemmy.ml/post/5552052

Apparently when you subscribe to a lower tier plan such as the one month one, the amount you paid (minus what you already "used") will be deducted from the upgrade price if you decide to commit for a longer amount of time.

This is great for people like me who want to try out all the features (including custom domains, Proton Bridge and SimpleLogin) without having to commit for one or two years and without having to pay the 65% higher price of the monthly plan.
I had already accepted the fact that I'd need to pay the monthly fee but this is a much appreciated gesture!

 

cross-posted from: https://lemmy.ml/post/5142305

From: Ben Skeggs

This series adds support for loading and running on top of NVIDIA's GSP-RM firmware, instead of directly programming large portions of the hardware ourselves.

The implementation is a little crude in places, but the goal of this series is to get (more-or-less) GSP-RM support on par with what we already support on HW. Next steps would be to look at what features GSP-RM enables us to more fully support, and clean up the GSP-RM integration once it's known what those will require.

Things should be somewhat faster when running on GSP-RM, as it's able to control GPU clocks, which wasn't possible for us previously.

SVM support is not available when running on top of GSP-RM at this point, due to GPU fault buffers not being implemented yet. This won't effect any real use-case, as SVM is experimental at best in nouveau anyway.

Aside from that, things should more or less work as normal.

GSP-RM support is disabled by default for now (except on Ada, where it's the only option) and can be enabled with nouveau.config=NvGspRm=1.

There'll likely be some nit-picky bugs to sort through, but I don't anticipate any huge disasters. I've smoke-tested this on a selection of GPUs right back to nv50, testing both HW and GSP paths depending on the GPU, and more thoroughly tested on Turing/Ampere/Ada, both discrete and laptop GPUs.

Firmware from NVIDIA is required to enable this support.

 

cross-posted from: https://lemmy.ml/post/5142305

From: Ben Skeggs

This series adds support for loading and running on top of NVIDIA's GSP-RM firmware, instead of directly programming large portions of the hardware ourselves.

The implementation is a little crude in places, but the goal of this series is to get (more-or-less) GSP-RM support on par with what we already support on HW. Next steps would be to look at what features GSP-RM enables us to more fully support, and clean up the GSP-RM integration once it's known what those will require.

Things should be somewhat faster when running on GSP-RM, as it's able to control GPU clocks, which wasn't possible for us previously.

SVM support is not available when running on top of GSP-RM at this point, due to GPU fault buffers not being implemented yet. This won't effect any real use-case, as SVM is experimental at best in nouveau anyway.

Aside from that, things should more or less work as normal.

GSP-RM support is disabled by default for now (except on Ada, where it's the only option) and can be enabled with nouveau.config=NvGspRm=1.

There'll likely be some nit-picky bugs to sort through, but I don't anticipate any huge disasters. I've smoke-tested this on a selection of GPUs right back to nv50, testing both HW and GSP paths depending on the GPU, and more thoroughly tested on Turing/Ampere/Ada, both discrete and laptop GPUs.

Firmware from NVIDIA is required to enable this support.

 

From: Ben Skeggs

This series adds support for loading and running on top of NVIDIA's GSP-RM firmware, instead of directly programming large portions of the hardware ourselves.

The implementation is a little crude in places, but the goal of this series is to get (more-or-less) GSP-RM support on par with what we already support on HW. Next steps would be to look at what features GSP-RM enables us to more fully support, and clean up the GSP-RM integration once it's known what those will require.

Things should be somewhat faster when running on GSP-RM, as it's able to control GPU clocks, which wasn't possible for us previously.

SVM support is not available when running on top of GSP-RM at this point, due to GPU fault buffers not being implemented yet. This won't effect any real use-case, as SVM is experimental at best in nouveau anyway.

Aside from that, things should more or less work as normal.

GSP-RM support is disabled by default for now (except on Ada, where it's the only option) and can be enabled with nouveau.config=NvGspRm=1.

There'll likely be some nit-picky bugs to sort through, but I don't anticipate any huge disasters. I've smoke-tested this on a selection of GPUs right back to nv50, testing both HW and GSP paths depending on the GPU, and more thoroughly tested on Turing/Ampere/Ada, both discrete and laptop GPUs.

Firmware from NVIDIA is required to enable this support.

view more: โ€น prev next โ€บ