Future tech hype

What future technology (related to computing, hardware or software) has you interested and why? >MicroLED From what I've come across, the display technology to end it all if it can be miniaturized enough to get the usual 1080p:24" or 1440p:27". Another related and relevant news: LG reintroduced IPS panels with A-TW polarizers (https://tftcentral.co.uk/news/lg-32gq850-aka-32gq85x-with-1440p-260hz-and-a-tw-polarizer). Just hope the retarded ultrawide fad will fade. >JPEG XL and/or AVIF Both the mainstream browser support and encoder quality included here. The most important consequences of these formats is in constrained environments: P2P networks like Tor/I2P/GNUnet with low bandwidth, storing mangas/photos in modern ereaders/smartphones without SD card slot. Note: AVIF lossless is soykaf even compared to PNG but possibly (as in: encoder maturity may be responsible for the difference) better than JPEG XL in lossy, so JPEG XL is the one I favour if there must be only one. >something to replace x86 in workstations Talos tried, but is still too expensive (and with poor software support and a complicated boot process due to the BMC), Apple's ARM stuff is obviously what people are looking at; especially since Asahi Linux is progressing fast. Especially interested in this since the Microsoft Pluton/Intel AMT/AMD PSP trio really is disgusting. Other interesting happenings here: RISC-V continuing at its pace and https://chipsandcheese.com/2022/08/26/tachyums-revised-prodigy-architecture/ >bcachefs and stratis OpenZFS is way too buggy, so any (Linux) competition is good. >Wayland I hate a lot of it, but it does solve some major X11 problems. The ecosystem (protocols, libraries and X11 replacement programs) is still slowly stabilizing. >GNUnet As mentioned before, this finally looks like a worthy Tor replacement; though I may go I2P if it takes too long. >Lisp world CL: got revived through quicklisp, interesting stuff like Clasp, SBCL, SICL, Petalisp, McCLIM still progressing. Scheme: R7RS still not dead (though without syntax-case and Chez staying on R6RS). Racket: don't know much about it (I'm a CL guy), but the Chez (CS) backend became the default one in 2021, which is cool. >Rest of programming world Real (AST based) macros finally catching on in babby PLs, Nim looks OK, Vale looks promising.

I'm a big fan of JPEG XL, mostly because I was a FLIF fanboy back in the day and JPEG XL is based on FLIF. AVIF just seems lower quality.

>Fuchsia Google is the closest thing to a modern AT&T, so if anybody is going make an actually good successor to it, it'll be a group with their amount of resources. I like its design decisions from what I know of them. The file system existing in the userspace. An object-based microkernel. Its effective and simple solution to dependency hell. Being able to support multiple ABI revisions. And its proposed compabitlity with linux software. The license is also good in my book. >JPEG XL >Risc V Same >Yggdrasil It's fast and easy to host a website on.

>>62856 *actually good(enjoyable to use on a daily basis) successor to Unix*

>>62855 >AVIF just seems lower quality. All the comparisons I've done show AVIF (using libav1 as encoder) as better only when in lossy mode with low bpp. At more reasonable bpps, both did achieve transparency, and JXL obviously wins the lossless race. But recent comparisons (cf https://encode.su/threads/3397-JPEG-XL-vs-AVIF and https://nitter.net/jonsneyers) are in favour of JXL. Now we wait for https://caniuse.com/jpegxl to be green (with Safari of course acting as the usual ball and chain) and libjxl to progress (0.7 will soon be out). >>62856 >Fuschia The problem is their NIH syndrome. They could just have taken a good L4 implementation as starting point, but they had to keep their soygineers happy.

>>62858 >They could just have taken a good L4 implementation Considering the time gap and their goals, I don't see a problem with starting from a clean slate. Also, maybe they don't like the license any of them have.

Far from a new technology, but always been a fan of animated PNG. Too bad the biggest soykafheads on the internet have been trying to push lossy video formats as an animated GIF replacement. As long as video formats lack delta-frame compression techniques, they fuarrrking aren't.

>>62862 GIF compresses like soykaf, though, even compared to lossless H.264 (using only intra coding). Really don't see the point anymore, to be honest.

>>62864 >even compared to lossless H.264 Indeed, however APNG typically beats lossless x264 on the placebo encoding setting at half the file size when dealing with animations. x264 on lossless is actually one of the best lossless codecs targeting file size, too, based on my own testing. APNG still wins because the advantage of delta-frame compression is that good.

By the way animated WebP is also trash compared to animated PNG. The VP8 codec it uses isn't as good at lossless compression as x264, let alone a genuine animation format that uses delta-frame compression. Can't wait for JPEGXL to come out so we don't have to deal with some moron from Google trying to push a video format as an animation format substitute anymore.

>>62867 In this specific case, I got 50 KB for H264 and 435 KB for FFV1. Wonder how lossless AV1 does.

>>62872 I don't quite understand the demands of archivists myself, but I don't think file size target is really the main focus of FFV1 for some reason.

>>62837 Archive-quality compression needs to be robust to data degradation. Ideal compression doesn't have this property.

>>62853 >Especially interested in this since the Microsoft Pluton/Intel AMT/AMD PSP trio really is disgusting. Arm has trustzone which is equally disgusting fiy

>>62877 Are you sure? Because I remember it being a bit different, more like x86's SMM. Basically, it depends on the OEM. Some search gave me: https://news.ycombinator.com/item?id=17783357

>>62872 Well, AV1 (libaom 3.4.0) with -cpu-used 0 is 81 KB...

>>62867 Addendum: I've found that lossless H.264 actually allows inter-frame coding.

>>62853 Honestly the only things I'm really hyped for are better, cheaper electric bicycles and scooters, non X86 everything, preferably unified architecture for mobile and computer devices, and more 3d printed semi boutique stuff like 3d printed components etc. Everything else just seems awful.

>>62853 >looking forward to new LCDs

>>62855 Is there a reason for AVIF to become popular? It's an adaptation of video compression algorithms, as opposed to a dedicated image format like JPEG XL stuff.

>>62908 What's the difference between I-frame intra encoding and "dedicated image format" compression? Protip: there's none.

>>62911 Well, little rectification: except the use of YUV444 instead of RGB (transparent conversion) and the limitations of the video formats like maximum image size (2^16 * 2^16 for AVIF, without tiles). But you get hardware decoding, which is quite invaluable.

>>62899 You realize that MicroLED is supposed to finally be the LCD tech to reach/surpass SED/FED (which was already the evolution of CRT), right?

>>62911 I-frames need to trade a little bit of data density for speed, while a 'dedicated image format' can afford to be a little slower if it results in better compression. Availability of hardware decoding/encoding *is* nice, but it's not an absolute necessity. I also don't think there is a single major format proposed which isn't amenable to fast SIMD-based implementation.

>>62936 >I-frames need to trade a little bit of data density for speed, while a 'dedicated image format' can afford to be a little slower if it results in better compression. The past (AVC intra vs JPEG) and the present (AVIF vs JXL) show that this isn't true. Or I could talk about MJPEG2000. >Availability of hardware decoding/encoding *is* nice, but it's not an absolute necessity. I also don't think there is a single major format proposed which isn't amenable to fast SIMD-based implementation. Entropy coding/decoding usually is the bottleneck, because it isn't SIMD friendly. Really, if AVIF had a better lossless mode, I'd "vote" for it; especially since it inherits (potential) grain synthesis for free from AV1.

>>62947 >The past (AVC intra vs JPEG) and the present (AVIF vs JXL) show that this isn't true Are you saying that their is never a tradeoff made for speed versus compression quality? Why do your examples show this is not true?

>>62969 >Are you saying that their is never a tradeoff made for speed versus compression quality? Of course there can be, what I meant is that it's not at all evident that it's the case here. Are do you have any data showing so? >Why do your examples show this is not true? Because both are comparable in quality/speed. Well, AVC intra trounces JPEG, so "comparable". And it's hard to compare anyway, as implementation is usually more important than the format (I mean, compare the work poured into dav1d with libjxl slow dev speed).

>>62935 Key word- is supposed to be. Given that Samsung is the only one who has it and that even OLED hasn't made it into monitors (of a sane size: <= 27 in), I doubt MicroLED is going anywhere anytime soon.

>>63023 Yeah, I did say so in the OP. LG showed with the {27,32}EP950 that OLED at a reasonable size can technologically be done. Burn-in (which µleds don't have) is probably the last problem; and price, obviously. Review of said OLED: https://tftcentral.co.uk/reviews/lg_ultrafine_32ep950_oled

>>63023 Also >Given that Samsung is the only one who has it https://en.wikipedia.org/wiki/MicroLED https://www.microled-info.com/

>>62853 > The most important consequences of these formats is in constrained environments I wonder how we managed before these formats were invented

>>63083 ??? You wait for the big images to load when browsing through Tor and much more with I2P.