>> DDR5 technology comes with an exclusive data-checking feature that serves to improve memory cell reliability and increase memory yield for memory manufacturers. This inclusion doesn't make it full ECC memory though.
"Proper" ECC has a wider memory buss, so the CPU emits checksum bits that are saved alongside every word of memory, and checked again by the CPU when memory is read. Eg. a 64 bit machine would actually have 72 bit memory.
DDR5 "ECC" uses error correction only within the memory stick. It's there to reduce the error rate, so otherwise unacceptable memory is usable - individual cells have become so small that they are not longer acceptably reliable by themselves!
As I understand it, the 50-move rule must be invoked by one of the players, lets assume our immortal players agree not to invoke that rule.
The 75-move rule is automatic, so that would be the limiting factor.
Note, that 75-move rule is only applicable after no pawn has moved or a piece has been captured. So our immortals can do a lot of shuffling things around.
I'm thinking that the number of moves of the longest game is going to be (16 pawns * 7 moves each + 16 pawns being captured + 14 other pieces each being captured, not the kings) * 75 moves for shuffling around = 10650 moves.
That's only 1 week at 1 move per minute! But given the permutations, it might take much longer to calculate the actual moves required to get to the end state :)
Pawns only get 6 moves :) But also they can't all make 6 moves because they can only move past each-other via capture, so half of them would get 5 moves instead (if you're counting all the captures), so that gives a maximum of ~8850.
Author here. I know not everybody loves the name. If I was trying to sell it I might be concerned about that. But it's open-source, and I'm not trying to make any money off of it, just trying to give something back to the community.
I was originally trying to name it something serious-sounding and I quickly found out that pretty much everything decent is taken. And even if you can come up with a good name that's not already in use by three other projects, good luck getting a decent domain for it.
I'm also a musician, and I've been through the drama of trying to come up with band names many times in the past. Here's what I've learned: the name matters, but only so much. If people like a band, they're gonna listen no matter how dumb the name is. Do you think Metallica is actually a good name? How about Def Leppard? Lynyrd Skynyrd? The Beatles? Those names are kinda stupid and nobody cares, lol.
Same thing with software. If the product is good, people will use it, and they are not going to care much about the name. I think Luxury Yacht is better than some made-up word that doesn't mean anything but maybe has some vague connection with kubernetes if you squint at it just right, like a magic eye puzzle.
Just my opinion, though. I'm not wrong, and you're not wrong, we just think about things differently, and that's OK!
Personally, I would like the name to be somehow related to the system. When I'm facing a stack of names and icons, make it easy for me.
Names without some connection to the thing are just more difficult. Maybe the name isn't descriptive - you can only have some many versions of ed, edit, edt, vedit, gedit, zed... I'm perfectly happy with puns and jokes - eric can be connected to (monty) python. It's the connection that makes it memorable. Even yacc and grep have some connection to the program.
I've been using Vivaldi browser for a while now, but neither the name nor icon have formed a natural connection to browsing for me. Same with Lazarus (an IDE), no obvious link (worse, it's nothing to do with raised from the dead). But "Bluefish Editor" at least tells me what it does, not a full description, but plenty.
How about requiring all APIs to be open? Companies are free to run/maintain/drop servers and apps, but we'd have the ability to use the hardware we bought, if we write our own apps.
That might actually be good for security. If APIs must be public, proper cloud security becomes necessary (rather than relying on obscurity).
Oh great - yet another way to get AI slop. Slop text, a slop cover - just raw slop, straight from the slopperizor. And the internet gets another little bit deader.
I thought for a long time that rather than move to Wayland, we could come up with a tidied-up version of X. Sounds like a good and useful project, I hope it progresses.
If you take the time to read through that (very partial) list of cruft and footguns in X11 it probably makes it a little easier to understand why a clean-slate approach was able to attract momentum and why many hands-on involved developers were relatively tired of X11. Critics would of course respond that backwards compatibility is worth the effort and rewrites are often the wrong call, etc. It's the Python 2/3 debate and many others.
Realistically rewrite would keep X11 compatibility layer and just do same wayland did, make new protocol.
Just... without all that mess that turned out to be at best +/-, at worst outright negative causing problems for everyone involved.
And near all of the "advantages" are "the server is built from scratch" not "the protocol was the limitation"
Python 3 was actively antagonistic to Python 2 code for no reason other than to lecture us about how we were doing things wrong, writing code to support 2 and 3 to help transition was dumb etc etc.
For example, in python 2 you could explicitly mark unicode text with u"...". That was actively BLOCKED with python 3.0 which supposedly was about unicode support! The irony was insane, they could of just no-oped the u"". I got totally sick of the "expert" language designers with no real world code shipping responsibilities lecturing me. Every post about this stuff was met by comments from pedantic idiots. So every string had to have a helper function around it. Total and absolute garbage. They still haven't explained to my satisifaction why not support u"..." to allow a transition more easily to 3.
Luckily sanity started prevailing around 3.5 and we started to see a progression - whoever was behind this should be thanked. The clueless unicode everything was walked back and we got % for bytes so you could work with network protocols again (where unicode would be STUPID to force given the installed base). We got u"" back.
By 3.6 we got back to reasonable path handling on windows and the 3 benefits started to come without antagonistic approaches / regressions from 2. But that was about 8 years? So that burnt a lot of the initial excitement.
> Python 3 was actively antagonistic to Python 2 code for no reason other than to lecture us about how we were doing things wrong, writing code to support 2 and 3 to help transition was dumb etc etc.
> [...]
> By 3.6 we got back to reasonable path handling on windows and the 3 benefits started to come without antagonistic approaches / regressions from 2. But that was about 8 years? So that burnt a lot of the initial excitement.
So it's a great analogy. Wayland started out proudly proclaiming that it intentionally didn't support features in the name of "security" but everyone should "upgrade" because this was totally better, and has been very slowly discovering that actually all the stuff it willfully dropped was useful and has mostly evolved back to near feature parity with Xorg.
Uhm no? As I mentioned, Wayland is simple because it was designed with the idea that there will be many implementations. It turns out that once you have many implementations, you can't just implement screen recording in one implementation and directly integrate with that implementation, because someone might use a different implementation. This then necessitates extensions for features that go beyond displaying things.
15 years ago I tried it and got that path error.
1 year ago I tried again and still got the same error.
I'm well aware that it's simple enough to fix. But I was baffled that the same error was still there.
I dunno there's a lot to pick from when it comes to "worst designed"!
It's definitely not well designed though.
And I agree about recommending it to beginners. Sure, a for-loop and a simple function look very friendly and easy, but good luck explaining to them why they can't import from a file in a different directory...
It was always an option, but "just" needed someone to dedicate all their time to it and pull in a group of long term maintainers. The real question is what will happen with the project in 2 years and will it be stable for day to day use.
The fact that you can "assume Vulkan exists" helps a lot (both hardware and software renderers exist). Do remember--Wayland predates Vulkan by almost a full decade.
In addition, you can offload OpenGL compatibility to Zink (again leaning into Vulkan).
> pull in a group of long term maintainers.
"Use new cool language" seems to be a prerequisite for this nowadays ...
You can't "assume Vulkan exists". Any pre-2016 hardware won't have proper hardware support for Vulkan and that's a lot of hardware still in use. Software renderers are unworthy of any serious consideration due to the perfomance drawbacks.
Just use OpenGL. I don't know when this trend to overcomplicate everything using Vulkan began, but I hate it.
Nvidia had a driver for Vulkan for Kepler which launched in 2012, AMD had support all the way back to GCN 1.0 (also 2012). Intel did have issues supporting it, I can't recall if it was for hardware reasons or just lack of desire for a driver.
Vulkan has substantial advantages for multi-threaded code, as well as exposing the underlying asynchronous nature of running code on the GPU. The kind of thing you want to be able to control with a desktop compositor where controlling vsync and present timing is very important.
It talks about trimming 'legacy' features and specifically says they are omitting 'font-related' operations. That obviously means no useful core X11 application will work (unless you count xlogo and xeyes). Whether the XRender glyph cache mechanism is included is unclear. It also says only DRI is *currently* supported, but maybe that's incidental?
XRender isn't part of the core protocol so it should be implemented in the future. There is already some xrender code in there. Almost no applications use x11 core protocol font, except for cursor. Since the x11 core protocol font (on xorg server at least) is rendered without anti aliasing and doesn't really support unicode.
Core fonts absolutely support Unicode. My (non-Xft) xterm windows are full of Unicode characters right now. It is true that anti-aliasing is not supported by the X.Org server, although scalable fonts have been for a while (https://www.x.org/archive/X11R7.5/doc/fonts/fonts.html#AEN49...). But you don't need anti-aliasing on a high-DPI display, and on a low-DPI display you can use any of the many beautiful bitmap fonts, unlike a lot of ‘modern apps’ these days.
>> DDR5 technology comes with an exclusive data-checking feature that serves to improve memory cell reliability and increase memory yield for memory manufacturers. This inclusion doesn't make it full ECC memory though.
"Proper" ECC has a wider memory buss, so the CPU emits checksum bits that are saved alongside every word of memory, and checked again by the CPU when memory is read. Eg. a 64 bit machine would actually have 72 bit memory.
DDR5 "ECC" uses error correction only within the memory stick. It's there to reduce the error rate, so otherwise unacceptable memory is usable - individual cells have become so small that they are not longer acceptably reliable by themselves!