Atemu

joined 5 years ago
MODERATOR OF
[–] Atemu@lemmy.ml 22 points 1 year ago (2 children)

parents are a motor to innovation

Absolutely. No parents -> No children -> No innovation.

[–] Atemu@lemmy.ml 21 points 1 year ago (4 children)

Why is this being downvoted? It's clearly labelled as Japanese; if you don't want to see foreign languages, filter them out.

[–] Atemu@lemmy.ml 2 points 1 year ago* (last edited 1 year ago)

VA has historically been terrible for high framerate, decent for colour accuracy and great for image quality (contrast is so much better on VAs compared to IPS).

VA panels with decent rise/fall times and not too much overshoot are far and few between. You really have to do your research and even then it'll be close or even slightly over the refresh cycle target. Only Samsung's more recent panels are actually good for high refresh; incredibly good actually.

[–] Atemu@lemmy.ml 2 points 1 year ago* (last edited 1 year ago) (2 children)

I’ve heard that some VA panels can get a bit wonky with text.

I haven't. Where did you hear this?

OLEDs tend to have issues because of their subpixel layout and I don't know the current state of font rendering support on M$'s stupid OS.

I can’t be giving people jaundice, I mean. The Acer isn’t exactly perfect either, but it’s good enough.

If your current cheap monitor is good enough, any monitor of this class will be at least as good.

If you need proper colours though, you should rather invest in a calibration device. Even good monitors should be calibrated for your specific room conditions if colour accuracy is of importance.

Whatever I choose will be my daily driver for probably 7+ years.

Then I'd get a newer OLED that isn't prone to burn in or wait a few months for said OLEDs to do down in price.

LCDs are not future proof. The vast majority has no proper support for HDR for starters (HDRn't).

I’m concerned that there will always be adjustments and compromises if I go curved.

Curved isn't as significant as you imagine it to be. You usually don't notice it at all.

Even extreme curvature as is common on Samsungs newer VA panels is only a little noticeable when you actually sit in front; eventhough it looks like a lot from the outside.

With VA, you actually want curvature as there is somewhat of a significant gamma shift when looking at a horizontal angle and the curvature helps mitigate this effect.

I really enjoyed 240hz G-Sync smoothness, but I don’t play serious competitive stuff and I could downgrade to 144hz, as long as the other benefits are worth the trade-off. I also think QHD will hover around 180fps in my current games, and UWQHD around 140 maybe. I’d probably only get the full benefit of 240hz QHD in older games.

Unless you really love playing E-sports games competitively and that makes up most of your gaming time, 144Hz is good enough. Though VRR with LFC is a must, look out for that.

Do any of you own either of these or similar monitors?

I'm not too familiar with the current market but what I can tell you is that you must always look up real-world measurements of rise and fall times, overshoot and colour accuracy. Ideally read or watch a review (TFT Central, RTings, HWunboxed/monitors unboxed).

This is especially important with VA panels as the vast majority use older tech that can have very slow rise and fall times that are often not actually sufficient for high refresh rates and/or bad overshoot. You need to filter these out.

I would not buy a monitor without having seen real-world measurements of rise and fall times aswell as overshoot.

If you have other recommendations in the $450-600 range

HW unboxed usually has many "current" monitors for comparison in their charts. I can highly recommend watching a few of their reviews.


I personally bought a UWQHD Nano IPS panel (LG 34GN850) after attempting to buy a working Samsung G9 VA UUWQHD twice a few years ago (yay Samsung QC...). It's decent but I wouldn't buy it again nowadays. I really miss the contrasts of the old (S)VA panel I had before. Decent VA panels have ~3000:1 ration while rather good IPS panels only have ~1000:0; it's really that much of a difference.

I'd only buy IPS if I couldn't find a VA with fast enough transition times for my specific constraints or desperately needed a colour accurate display.

These days, I'd buy LG WOLED or Samsung QD-OLED (or wait for them to go down in price).

[–] Atemu@lemmy.ml 46 points 1 year ago

I used to not but I wish I did. I want to know where pictures were taken. Photo album software like Immich can also make cool maps out of your photos this way and group photos by location.

As long as you're not sharing the pictures with anyone, there is no loss of privacy whatsoever in doing this. I don't see any reason to generally label it as "not great for privacy".

When sharing publicly, you need to be careful of course and run the images through an EXIF metadata stripper.

[–] Atemu@lemmy.ml 1 points 1 year ago

Plenty more benchmark worse. What's your point exactly?

[–] Atemu@lemmy.ml 0 points 1 year ago (3 children)

Statistically it should always be better by now because the resource hog that is called windows slows older systems down.

That's not how any of this works.

[–] Atemu@lemmy.ml 5 points 1 year ago

They should register a trade mark.

[–] Atemu@lemmy.ml 10 points 1 year ago* (last edited 1 year ago) (1 children)
[–] Atemu@lemmy.ml 3 points 1 year ago

Old reddit absolutely had its issues. The new and newnew design is just decisively worse however.

[–] Atemu@lemmy.ml 2 points 1 year ago

You activated my trap card!

It's entierly based on the excellent org-mode for Emacs.

1
submitted 2 years ago* (last edited 2 years ago) by Atemu@lemmy.ml to c/fairphone@lemmy.ml
 

I just opened a map and it's off by >45° again. Doing a calibration makes it a good bit better but still quite jerky and rotating the device 90° (i.e. using a wall for reference) still does not result in a 90° turn in the compass.

Does anyone else experience this? Please include the ROM and version used.

Edit: Should have mentioned this is a FP4. Other FPs are entirely different hardware.

 

I've been using Consent-O-Matic which works pretty well but built into the browser? Wow.

 

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

This is a changeset adding encryption to btrfs. It is not complete; it
does not support inline data or verity or authenticated encryption. It
is primarily intended as a proof that the fscrypt extent encryption
changeset it builds on work. 

As per the design doc refined in the fall of last year [1], btrfs
encryption has several steps: first, adding extent encryption to fscrypt
and then btrfs; second, adding authenticated encryption support to the
block layer, fscrypt, and then btrfs; and later adding potentially the
ability to change the key used by a directory (either for all data or
just newly written data) and/or allowing use of inline extents and
verity items in combination with encryption and/or enabling send/receive
of encrypted volumes. As such, this change is only the first step and is
unsafe.

This change does not pass a couple of encryption xfstests, because of
different properties of extent encryption. It hasn't been tested with
direct IO or RAID. Because currently extent encryption always uses inline
encryption (i.e. IO-block-only) for data encryption, it does not support
encryption of inline extents; similarly, since btrfs stores verity items
in the tree instead of in inline encryptable blocks on disk as other
filesystems do, btrfs cannot currently encrypt verity items. Finally,
this is insecure; the checksums are calculated on the unencrypted data
and stored unencrypted, which is a potential information leak. (This
will be addressed by authenticated encryption).

This changeset is built on two prior changesets to fscrypt: [2] and [3]
and should have no effect on unencrypted usage.

[1] https://docs.google.com/document/d/1janjxewlewtVPqctkWOjSa7OhCgB8Gdx7iDaCDQQNZA/edit?usp=sharing
[2]
https://lore.kernel.org/linux-fscrypt/cover.1687988119.git.sweettea-kernel@dorminy.me/
[3]
https://lore.kernel.org/linux-fscrypt/cover.1687988246.git.sweettea-kernel@dorminy.me
 
This is a changeset adding encryption to btrfs. It is not complete; it
does not support inline data or verity or authenticated encryption. It
is primarily intended as a proof that the fscrypt extent encryption
changeset it builds on work. 

As per the design doc refined in the fall of last year [1], btrfs
encryption has several steps: first, adding extent encryption to fscrypt
and then btrfs; second, adding authenticated encryption support to the
block layer, fscrypt, and then btrfs; and later adding potentially the
ability to change the key used by a directory (either for all data or
just newly written data) and/or allowing use of inline extents and
verity items in combination with encryption and/or enabling send/receive
of encrypted volumes. As such, this change is only the first step and is
unsafe.

This change does not pass a couple of encryption xfstests, because of
different properties of extent encryption. It hasn't been tested with
direct IO or RAID. Because currently extent encryption always uses inline
encryption (i.e. IO-block-only) for data encryption, it does not support
encryption of inline extents; similarly, since btrfs stores verity items
in the tree instead of in inline encryptable blocks on disk as other
filesystems do, btrfs cannot currently encrypt verity items. Finally,
this is insecure; the checksums are calculated on the unencrypted data
and stored unencrypted, which is a potential information leak. (This
will be addressed by authenticated encryption).

This changeset is built on two prior changesets to fscrypt: [2] and [3]
and should have no effect on unencrypted usage.

[1] https://docs.google.com/document/d/1janjxewlewtVPqctkWOjSa7OhCgB8Gdx7iDaCDQQNZA/edit?usp=sharing
[2]
https://lore.kernel.org/linux-fscrypt/cover.1687988119.git.sweettea-kernel@dorminy.me/
[3]
https://lore.kernel.org/linux-fscrypt/cover.1687988246.git.sweettea-kernel@dorminy.me
 

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

I assume many of you host a DMS such as Paperless and use it to organise the dead trees you still receive in the snail mail for some reason in the year of the lord 2023.

How do you encode your scans? JPEG is pretty meh for text even at better quantisation levels ("dirty" artefacts everywhere) and PNGs are quite large. More modern formats don't go into a PDF, which means multiple pages aren't possible (at least not in Paperless).

Discussion on GH: https://github.com/paperless-ngx/paperless-ngx/discussions/3756

view more: ‹ prev next ›