[HN Gopher] The Xterm Window Manager Homepage
___________________________________________________________________
The Xterm Window Manager Homepage
Author : 6581
Score : 101 points
Date : 2021-10-09 11:15 UTC (11 hours ago)
(HTM) web link (xtermwm.sourceforge.io)
(TXT) w3m dump (xtermwm.sourceforge.io)
| dredmorbius wrote:
| A similar concept is available as TWIN: the Textmode WINdowing
| environment. This is mentioned at the bottom of the "See Also"
| list at TFA.
|
| https://github.com/cosmos72/twin/
|
| Screenshots at the (presumably old?) Sourceforge page:
|
| https://sourceforge.net/projects/twin/
| tyingq wrote:
| Reminds me of DESQView. https://en.wikipedia.org/wiki/DESQview
| smhenderson wrote:
| Indeed, the overview page even mentions that.
|
| _XtermWM is expected to be helpful to the following kinds of
| people:_
|
| Third item on the list is:
|
| _People who used the DOS-era "shells" like IBM DOS Shell,
| DESQview..._
|
| I can definitely see the appeal of this over a ssh link to a
| server you're trying to keep lean.
| bitwize wrote:
| This is like something a kid would write, or someone new to
| programming. Like someone wondered, "I love tiling window
| managers, what if my xterm had a tiling window manager in it for
| all my text applications?" That story is even suggested by the
| name. So the author either _is_ relatively new to programming, or
| they have a Buddhistic "eternal beginner" mindset. That may be
| the most charming thing about this piece of software.
|
| Note that I'm not trying to impugn the author's competence, but
| praising their mindset, which is that of someone who's discovered
| that programming a computer is a journey of infinite
| possibilities, and is unafraid of judgement of their choice of
| name, application, programming language, etc. because there is
| sheer joy in the act.
| a-dub wrote:
| seems more like unix based fanfiction/retro-appreciation for
| early 90s era desqview.
|
| as such, the author is likely over 40.
|
| terminal based tiling window managers have been around for
| decades, the most popular ones are gnu screen and tmux.
| smusamashah wrote:
| This looks like VTM https://vtm.netxs.online/ it can be tested
| online by doing ssh vtm@netxs.online
| dleslie wrote:
| That looks incredible.
| sprash wrote:
| It also feels amazing with all the animation and kinetic
| scrolling. I just wonder where to get the "Apps" showcased in
| the ssh demo and the screenshot.
| azinman2 wrote:
| No kidding. I'm really impressed with a full window
| management system in the terminal like that. The way it
| creates a spatial desktop and supports the mouse in such a
| way? The "translucent blur" effect! Incredible!
|
| Anyone actually use this to get real work done? And if so,
| why not just use a normal GUI?
| vngzs wrote:
| It's easier and more lightweight to configure an SSH
| session than X11 forwarding or remote desktops. So if you
| do all your real work on a server or desktop that you
| access remotely, these kind of tools can be helpful.
|
| That said, all I really need is tmux to do my work. I use a
| tiling window manager as my daily driver. Don't see any
| reason I'd adopt a floating WM in the terminal except that
| it looks cool.
| cpach wrote:
| Is Java really faster than Electron? I wouldn't have guessed
| that, but if it's true: Hey, cool!
| DonHopkins wrote:
| The most awful problem with Java is that Larry Ellison owns it.
|
| So the real question is: "Ugh, Why Oracle?!"
| xiaq wrote:
| Java programs are slow to start because of all the JVM
| overheads, but after that the performance is probably between
| 1x and 2x as slow as C (it depends a lot on the workload, of
| course). Java is definitely not a slow language in general,
| just has slow startup.
|
| The slow startup time is the reason why Java is considered high
| performance in "enterprise software", but has a reputation of
| being slow among developers, especially non-Java developers.
| "Enterprise software" is usually long-running server-side
| programs, so you barely care about the startup time. But if
| you're using Java programs as part of your development workflow
| you'll tend to start and restart them repeatedly and the
| startup time can get really annoying. Java's GUI libraries also
| tend to be not very well optimized, which further contributes
| to people's impression of Java's performance.
|
| In the case of this particular project, even though it's a
| terminal application, since it's a WM you'll likely start it
| once and leave it running for a pretty long time (as opposed to
| programs like "ls" which you run again and again), so this is
| in fact a good place to use Java.
|
| You can also use GraalVM to compile Java programs ahead of time
| these days, and get much faster startup.
| pjmlp wrote:
| For those stuck with Java 8, yes they can be slow to start.
|
| For everyone else that has moved on, there are JIT caches and
| AOT compilers, no longer something only available to
| consumers from commercial JDKs.
| cle wrote:
| The Java ecosystem has a deeply engrained habit of doing
| expensive time-consuming things at startup too, like
| classpath scanning, eager caching and dependency injection,
| etc.
|
| GraalVM has a bunch of tradeoffs...executables can't be
| cross-compiled, anything using reflection or other dynamic
| features are difficult to compile, only a subset of the
| standard library is (was?) supported, etc.
|
| Honestly there are much better languages to use for compiled
| CLIs these days, I would still steer clear of Java for CLI
| tools unless you need to reuse existing code.
|
| But I do agree with you that Java/JVM is a decent option for
| a WM, but using GraalVM would ruin all the nice properties of
| the JVM for that use case (JIT + dynamism).
| pjmlp wrote:
| With a modern JVM, you can work around that expensive
| startup by making use of JIT caches.
| KronisLV wrote:
| You know, it feels like you're right about the technical
| aspects, but there's an alternate point of view to be
| considered: maybe, in some circumstances, the dynamic
| loading and execution of code through reflection and other
| mechanisms actually is a bad thing?
|
| If i got a euro for every time i run into problems at
| runtime when porting Spring to Spring Boot or Spring Boot
| 1.X to Spring Boot 2.X projects, i'd have enough money
| never to have port projects like that over.
|
| Whereas without such dynamic logic, if your code compiles,
| you can be pretty confident that there won't be such
| oddities, classpath or dependency conflicts, weird scoping
| rules for Maven (especially with the <provided/> option
| which means that all of the sudden your app becomes
| dependent on an app server and its specifics - does your
| install of Tomcat or TomEE have the correct version of the
| .jar you want to use, or maybe it'll be missing, or maybe
| there'll be two libraries loaded at the same time?).
|
| Of course, picking a tech stack in which such approaches
| and dynamism aren't even prevalent is also a good
| alternative, though not everyone enjoys the more static way
| of development either.
| AtlasBarfed wrote:
| You think java devs have it bad with ecosystem churn? The
| six months I spent in "modern javascript" was hilariously
| unstable.
|
| Classpath scanning is so unnecessarily hard in the JVM. I
| get they want flexible classloaders that may not have
| foreknowledge of the classes they can load, or that may
| not be simple zip/jars or filesystem-resident class
| files.
|
| But the fact that minority seems to doom classpath
| scanning to ludicrous workarounds and contortions rather
| than simply provide a "what classes do I know" api on the
| classloader that isn't a guarantee seemed ridiculous.
|
| The JVM should provide a cached map of the available
| classes. Jars/zips should optionally be able to provide a
| list/structure for fast scanning.
|
| "Full compilation" can still rely on shared libraries
| though, correct? Same boat there?
| capableweb wrote:
| > You can also use GraalVM to compile Java programs ahead of
| time these days, and get much faster startup.
|
| Just wanted to add a note that there is a tradeoff involved,
| as programs compiled with GraalVM will have worse performance
| compared to running directly with the JVM, but the startup
| speed will be faster.
|
| For CLIs, GraalVM is a god send.
|
| For long-running servers/daemons, JVM is still king.
| pjmlp wrote:
| For CLIs, AOT compilation has been available since around
| 2000 for those whose employers could afford commercial
| JDKs, or try their luck with gcj.
|
| Nowadays both OpenJDK and OpenJ9 offer free JIT caches with
| PGO data, GraalVM isn't the only free beer option.
| capableweb wrote:
| > AOT compilation has been available ... commercial JDKs,
| or try their luck with gcj
|
| > OpenJDK and OpenJ9 offer free JIT caches with PGO data
|
| As someone who never been exposed to either of those
| options, what kind of startup times do they offer
| compared to GraalVM? With GraalVM compiled Native Image I
| get same startup performance as any random Go program,
| would those offer the same performance when it comes to
| startup?
|
| Is there any tradeoff regarding long-term performance for
| daemons and similar?
| pjmlp wrote:
| Much better, because you still do have the JIT data, it
| is similar to having done a couple of GraalVM runs
| gathering profile data.
|
| Here is an overview of using it with Maven
|
| https://www.morling.dev/blog/building-class-data-sharing-
| arc...
|
| And here is the documentation for the JIT/AOT and JIT
| server preview for J9,
| https://www.eclipse.org/openj9/docs.
|
| By the way, this is also the way that ART evolved after
| the short lived AOT attempt.
|
| Nowadays a modern version of ART will have a tiered
| execution of fast startup interpreter (when no native
| code is available), a JIT with PGO data gathering, AOT
| compilation from only the parts that matter when the
| device is idle, upload of PGO profiles into the store so
| that every device of similar class doesn't start from
| zero when an APK gets installed.
|
| If the PGO dataset changes, then it backs into JIT again,
| and recompiles the native code again on idle.
| yung_steezy wrote:
| I believe Java web frameworks still come out on top in terms of
| performance speed.
| bitwize wrote:
| C++ and Rust frameworks are faster. But Java is in like the
| top 3 or 4.
| laumars wrote:
| Near the top. They never came out on top because languages
| like C++ would out perform (and now we have Rust too). But
| Java is certainly up there. That said, recently even a lot of
| the other languages have made some huge optimisations in the
| web server space too and so Java doesn't even dominate
| amongst the byte code languages like it used it
|
| https://www.techempower.com/benchmarks/
|
| That all said, comparing Java to Electron is like comparing a
| sports car to a camper van.
| capableweb wrote:
| I know this is not a perfect benchmark, but TechEmpower runs
| benchmarks with tons of different libraries and frameworks,
| here is the latest round, filtered by just Java and JavaScript
| technologies:
| https://www.techempower.com/benchmarks/#section=data-r18&hw=...
|
| First JavaScript on that list ranks 21th.
|
| If you check out the complete listing (all languages, https://w
| ww.techempower.com/benchmarks/#section=data-r18&hw=...), then a
| Java program comes at 4th place, after two Rust programs and
| one C.
|
| Conclusion, Java is not as slow as people think, and absolutely
| faster than anything involving JS.
| KronisLV wrote:
| I had a discussion about benchmarks and how useful they are a
| few days ago: i remember mentioning TechEmpower in particular
| because of how close to typical real world usage of the
| libraries and ecosystems their benchmarks are!
|
| That said, Vert.X and some other of the frameworks aren't
| exactly idiomatic Java, because they're heavily focused on
| maximum performance - when i last checked them out, there
| were even async JDBC drivers in development, and while the
| performance was indeed stellar, it wasn't exactly production
| ready back then.
|
| Edit: well, the actual way it writes and reads isn't bad in
| of itself, but some might need some time to get adjusted to
| the concepts. Actually, i'd say that it reads a bit more like
| JS: https://vertx.io/docs/vertx-core/java/
|
| Of course, things have probably improved, but perhaps it's
| also useful to compare some of the full platform
| implementations and perhaps the most popular of each
| language's frameworks. Maybe even with ORMs, to also see how
| those technologies fare in reality, since i've personally
| seen some of the most widely used enterprise frameworks
| become pretty slow due to all of the abstraction that's going
| on, which perhaps is a deserved criticism for Java.
|
| So for most of the "boring & stable" projects, it could look
| a bit like the following: https://www.techempower.com/benchma
| rks/#section=data-r18&hw=... - Java, Spring:
| the most popular enterprise framework in my experience
| - Java, Dropwizard: a pretty good alternative to Spring that
| takes a number of the industry standard frameworks/libraries
| and integrates them (Quarkus not featured because while
| the MicroProfile compatibility would be useful to test, they
| actually have no tests with ORMs for now) - JavaScript,
| Express: still the most popular framework for back end
| development with Node - JavaScript, Node: sometimes
| i've seen people write servers directly as well, which is
| surprisingly far easier in Node than it is in Java (servlets
| and the abstractions around them can be unpleasant to work
| with) (Koa not featured because while it's gaining
| popularity, they actually have no tests with ORMs for now)
|
| With those particular frameworks, the scene changes a bit and
| both of them are far more similar in their performance. I'm
| not sure what the takeaway here would be: whether it's that
| Wirth's law (https://en.wikipedia.org/wiki/Wirth%27s_law)
| applies to libraries that try to cover all use cases, that
| Java just has some popular frameworks which underutilize its
| potential for performant code, or that you really should
| compare particular frameworks, paradigms and implementations,
| rather than just languages in general (since the overhead
| cannot be disregarded).
|
| Of course, these results also may not be representative of
| the stacks that other companies use or even those that are
| popular in other regions of the world, so i invite you all to
| check out those results for yourselves with the stacks that
| you're considering and maybe even browse the test source
| code: https://github.com/TechEmpower/FrameworkBenchmarks/tree
| /mast...
| jjice wrote:
| If I had to wager a guess, getting to skip parsing at runtime,
| better typings known to the compiler, and having a lighter
| runtime all help.
|
| Having good type info is especially powerful for compiler
| optimizations, and a situation that JS get a lot less often
| than Java. I'm assuming the JVM is lighter overall than Node,
| but that's just a guess, and AOT(ish) probably helps as well.
| Nux wrote:
| Java can be very fast indeed. It gets a bad press because many
| programs coded in it can be quite heavy and bloated.
| cpach wrote:
| TBH I think this is the first time I've seen a TUI done in
| Java. (There might be more examples out there but I can't
| come to think of any right now at least.)
| tyingq wrote:
| A couple of TUI libraries for Java:
|
| http://www.pitman.co.za/projects/charva/Screenshots.html
|
| https://github.com/mabe02/lanterna
|
| And, lower level, there's jCurses, which despite the name,
| also works on Windows:
|
| https://github.com/kba/jcurses
| tyingq wrote:
| Apparently, the linked project also separated out their
| Java TUI into a separate project called Jexer.
|
| https://gitlab.com/klamonte/jexer
| laumars wrote:
| A TUI is ostensibly just a command line application with an
| event loop and plenty of {ESC} characters being written to
| STDOUT. And I can assure you there are no shortage of Java
| applications that run headless.
| GuB-42 wrote:
| In the hierarchy of performance, Java is what comes just after
| native C++, it may even be faster than Rust because while Rust
| is potentially faster, Java has decades of refinement. And
| remember that Java appeared in 1995, it had to be usable on
| machines of that time.
|
| Electron is at the bottom end for many reasons; it uses JS, a
| dynamic language that will have a hard time beating
| static/native code despite all the work poured into it. It has
| a ridiculously large runtime (a full browser), and every app,
| no matter how small, has a copy of it.
|
| And remember that Java was used in some way in early phone
| apps, including the first Android devices, at that time phones
| were seriously underpowered compared to the quasi-desktop
| performance we not have.
| laumars wrote:
| Java was used long before Android. It was in feature phones,
| like from manufacturers like Sony Ericsson (and developers
| would write games and mapping software in it too).
| KronisLV wrote:
| I still remember playing some of those games on my phone
| with the Symbian OS: https://en.wikipedia.org/wiki/Symbian
|
| Honestly, it was nice while it lasted and it was
| interesting to see developers do a lot with so little
| screen real estate, memory and other hardware limitations,
| like an evolution of the consoles of the older days, before
| phones became essentially scaled down fully featured
| computers.
|
| It is especially interesting because most modern JDK
| releases are known to be pretty memory hungry, in contrast
| to what the developers had to pull off back then. If Java
| had a stronger focus on embedded and low resource
| environments, who knows, maybe it'd be as usable as
| MicroPython nowadays.
|
| It appears that there are actually a few apps available
| that can supposedly load these games, though i haven't
| personally checked them out: https://play.google.com/store/
| apps/details?id=ru.playsoftwar...
|
| That said, i do have fond memories of Doom RPG back in the
| day, as well as the likes of Galaxy on Fire, as well as the
| old classic Gravity Defied. What a nice decade that was!
| tcoff91 wrote:
| SIM cards actually run a stripped down Java on them.
| pdkl95 wrote:
| A friend of mine had one of these (1998-99):
|
| https://electronics.howstuffworks.com/gadgets/home/digita
| l-j...
|
| > The Java Ring is a stainless-steel ring, 16-millimeters
| (0.6 inches) in diameter, that houses a 1-million-
| transistor processor, called an iButton. The ring has 134
| KB of RAM, 32 KB of ROM, a real-time clock and a Java
| virtual machine
|
| A wearable device that could run arbitrary portable code
| was a cool idea.
| laumars wrote:
| So do Blueray players, Java is everywhere.
| laumars wrote:
| I'm surprised you're surprised. Electron runs like a dog on
| modern systems while Java has been used in enterprise
| applications since the 90s. They're not even in the same
| league. But then there isn't much out there that even comes
| close to the performance overhead of Electron.
| mmphosis wrote:
| Jazelle DBX (direct bytecode execution)
|
| https://en.wikipedia.org/wiki/Jazelle
| anonymousiam wrote:
| The name is confusing. I initially thought it had something to do
| with one of these two existing "xterm" things:
|
| https://en.wikipedia.org/wiki/Xterm
|
| https://en.wikipedia.org/wiki/X_terminal
|
| I see that it is a "Window manager", but not related to The X
| Window System: https://en.wikipedia.org/wiki/X_Window_System
|
| It does however provide windows of Xterms (first link above) with
| good compatibility to the X version.
|
| Cool!
___________________________________________________________________
(page generated 2021-10-09 23:01 UTC)