> Wayland is now as old as Xorg was when wayland started because X11 is "old and crufty" and still not usable.
How is this comparison supposed to make any sense? When Xorg started it was a fork of the existing XFree86 codebase (due to XFree86 changing license to one not deemed open source compatible), not starting from a clean sheet of paper. And XFree86 in turn wasn't a clean sheet implementation of the X protocols either, it IIRC started as a bunch of patches on top of the reference X11 codebase which goes back to the 1980'ies.
this is counting the xfree86 legacy. That one was started in 1991 and 17-18 years old when wayland was startet in 2008 which is now 18 years ago.
Counting the time before xfree86 doesn't make much sense. While initial implementations of X where older than that, those early implementations don't really have much in common with todays Xorg.
And the problem is, that wayland is still much less mature than Xorg was when wayland was started.
[different person] That's even worse than I thought. I assumed XFree86 was 1986, and I don't think I heard of Wayland until right around a decade ago. I know I didn't think it started until around 2011/2012.
The same problem with height would also be an issue for the underwater thing. Quick googling suggests a very large container ship might have a draft of 16-17m when fully loaded. Probably you want the catenary at 20m depth then. How does a small get their pantograph (or whatever you'd call it) down to that depth, and then move forwards without the pantograph sticking 20m down creating a huge amount of drag. Not to mention how do you make the connection between the pantograph and the catenary in the (conductive) sea water?
> Probably you want the catenary at 20m depth then. How does a small get their pantograph (or whatever you'd call it) down to that depth,
Does the connection from the 'pantograph' to the boat need to be rigid? Use a cable? Maybe it's not for the smaller boats which can't handle a 20m (probably more like 40m for the angle and slack) cable, but also need less power and thus pollute less.
> and then move forwards without the pantograph sticking 20m down creating a huge amount of drag
Presumably, the catenary's route would be cleared of obstructions - maybe even on a frame elevated over the floor, maybe at relatively constant depth - or do I misunderstand? Would a 40m cable cause that much drag? Obviously the pantograph would have to be low friction and highly reliable.
Unfortunately it's not entirely clear if rustls can compete in the embedded space where Mbed TLS is most popular?
As a rustls maintainer, we'd love to get feedback about this and/or work with organizations that want to sponsor getting rustls to the point that it could!
Google says it's "CPEU most commonly stands for Continuing Professional Education Unit, a credit system used by dietitians and nutrition professionals.". Yeah, not sure how that is related to RISC-V. Perhaps we should eat RISC-V powered nanobots to, uh, future sci-fi something?
I've been wondering if we're going to end up with some kind of backlash against all the autotuning, 'gridification' as this article explains, etc etc., and AI slop as well as deepfakes filling up the interwebs. You can't know what's real anymore. So people will start preferring live performances. Not only live music, but, say, theater/musicals/opera instead of going to the movies, and so forth?
Not saying this as some kind of general "anti-AI" argument or anything. I'm not advocating for the Butlerian Jihad. I find AI a very useful tool, and I used it at work pretty much every day. But for art, which in a sense is a celebration of human creativity, something gets lost if we use AI to generate it, doesn't it?
I'm kinda hoping we get a revival of playing music (e.g. at the piano, on the guitar) at home. As Gillian Welch said "If there's something that you want to hear | You can sing it yourself".
https://imslp.org/ makes an enormous 19th century repertoire of salon music available to the amateur musician. I've been following the YouTube channel Gamma1734 https://www.youtube.com/@PianoScoreVids book marking attractive simple pieces, tagging them "easy piano for me".
I'm slow at learning pieces, bookmarks outnumber learned pieces about a hundred times! This abundance of riches may aid a revival of playing music.
Oh, absolutely. Music might be a shit career unless you happen to be in the top 0.01%, but it's a fantastic hobby. Being able to play or sing something yourself is immensely satisfying (maybe not so satisfying to your neighbors, but I digress).
In defense of the analog simple life I suppose it's possible to be a hermit without sending out mail bombs to people you believe have not seen the light?
COMMON, ENTRY, and EQUIVALENCE are certainly frowned upon in modern Fortran style, as the language has gotten less error prone ways of accomplishing the problems those features ostensibly solved. But they still exist in the language for backwards compatibility.
To this day some Fortran compilers put large local variables into static storage rather than the stack. Because many old Fortran programs were written with the assumption that all procedure variables were statically allocated, and thus having huge arrays as local variables wasn't an issue.
This kind of code then easily breaks by overflowing the stack if the compiler allocates them there.
But this then doesn't work that well if the procedure is called recursively, or concurrently from multiple threads.
Making this even worse, in a recent Fortran standard (2008?) this was reversed such that procedures must be explicitly marked with NON_RECURSIVE in order to allow the compiler to allocate variables statically. Undoubtedly the right decision given the increasing prevalence of threads as well as recursive algorithms, but a gotcha for compiling old dusty deck code.
I remember helping a research group port some old Fortran code they had to a more modern environment and compiler. Turning on array bounds checking made the program crash pretty quickly. "There can't be a problem with the code as we've published papers with it". Umm, sorry sunshine, that's not how it works.
How is this comparison supposed to make any sense? When Xorg started it was a fork of the existing XFree86 codebase (due to XFree86 changing license to one not deemed open source compatible), not starting from a clean sheet of paper. And XFree86 in turn wasn't a clean sheet implementation of the X protocols either, it IIRC started as a bunch of patches on top of the reference X11 codebase which goes back to the 1980'ies.
reply