'Best Open Source Software of 2021' Identified by InfoWorld Listicle (infoworld.com) 58
"Money may not grow on trees," argues InfoWorld, "but it does grow in GitHub repos." (as well as other open-source code-hosting sites). "Open source projects produce the most valuable and sophisticated software on the planet, free for the taking, dramatically lowering the costs of information technology for all companies..."
Then they picked out a few to recognize and honor with their 2021 Best of Open Source Software Awards.
The winners include:
Then they picked out a few to recognize and honor with their 2021 Best of Open Source Software Awards.
The winners include:
- Windows Terminal, which they describe as a command-line terminal application with GPU-accelerated rendering giving "an order-of-magnitude performance boost over the older console host... Configuration options let you customize terminal appearance and behavior in ways never possible before."
- Crystal, "a project to deliver a programming language with the speed of C and the expressiveness of Ruby" which can interface with C code. (Version 1.0 was released this spring after years of development.)
- Flutter, Google's UI toolkit for generating natively-compiled mobile/web/desktop applications (based on Dart).
- Presto, an open source distributed SQL engine, and BlazingSQL, a GPU-accelerated SQL engine.
- Apache Superset (an enterprise-ready business intelligence web application offering easy dataset visualization) and Apache Solr, a search platform built on Apache Lucerne. ("Unlike Elasticsearch, which dropped its open source license, Solr is still free.")
Race to the bottom (Score:1)
Self-consciously posting "lists-as-articles" doesn't make it any less clickbait. It's like drinking cheap beer "ironically". The pretension changes nothing.
This before concluding that I really completely fail to get excited by any of the listed. I did get disappointed that the bodylinks aren't to the software but to more listicles, so I had to search. And then finding that the the one bit of software that might interest me, really wasn't interesting after all. It's all about "ecosystem" these days. Those
Re:Race to the bottom (Score:5, Insightful)
I'm laughing at the need for a GPU accelerated terminal.
Comment removed (Score:4, Informative)
Re: (Score:2)
It's text, not crysis.
Re: (Score:2)
Re: (Score:2)
That still doesn't sound like a challenging render.
Re: (Score:2)
Re: (Score:2)
even a small improvement in performance is still an improvement, which is the point.
The actual claim is: "...order of magnitude performance boost"
Re: (Score:2)
Re: (Score:2)
(shrug)
I'm not the one making extraordinary claims.
Re: (Score:2)
I think he woke up and found himself a Microsoft hater, as in "If it's Microsoft, it's bad."
Re: (Score:1)
translucent background in a software-rendered terminal
Why on earth would anyone in their right mind want to do that?
Re: (Score:2)
Just try and enable e.g. translucent background in a software-rendered terminal and see how much more CPU-time is consumes in comparison.
Just try and enable a traslucent background in a terminal, and I'll point the rest of the people at somebody who is not used to working on a terminal.
Sure, it looks kewl, but it is not useful. And, in many ways... it gets in the way of work.
Re: (Score:2)
Re: (Score:2)
That still doesn't sound like a challenging render.
If you were around in the 1980's and early 1990's, then you'll remember the horrid performance of software-only graphical terminal rendering. In that era, real text mode was giving way to graphical text mode emulation. Everything was being drawn in graphical mode, including text terminals. We got GPU-accelerated scrolling (it was called hardware-accelerated scrolling at the time) somewhere in that timeframe, and for that reason. Scrolling a graphical terminal window IS a challenging render for a CPU, which
Re: (Score:3)
Re: (Score:2)
Vista gave up GDI hardware acceleration but Win 7 picked it back up again (when Aero is turned on). While modern GPUs probably no longer support most of the XP-era GDI acceleration, basic font rendering is probably still there.
The "horribly laggy re-rendering" is due to memory was considered precious in the old days, and so GDI was designed to paint all programs in the same queue, without storing framebuffers in layers. So, at that time, when surface A covered surface B, even if the two surfaces belonged
Re: (Score:2)
It's text, not crysis.
You clearly have zero idea what the Windows Terminal actually does and thus end up just spouting rubbish. Many of us who spend a lot of time on the CLI like to customize our environment to suit our needs and preferences and the Windows Terminal has a fuckton of customizability both in the looks and in functionality. Having one, single fullscreen window with a ton of different terminals open in panes instead of having to use tabs and/or separate windows for them, all with different settings and looks, for example, is a really powerful feature.
But literally none of that needs any GPU acceleration.
Re: (Score:3)
Re: (Score:1)
Well, that's actually not true on many low-end and portable devices. If you have something drawing scaled, anti-aliased TrueType fonts to a composited framebuffer on a built-in LCD screen for a mobile device that runs on the power equivalent of about four AA batteries, you're gonna fucking notice while scrolling through your docs and code if the terminal doesn't have any hardware acceleration. If text is yucky to you, you probably don't do the type of work that excites this use case to begin with.
Not that
Re: (Score:2)
Historically, GPUs did do 2D acceleration, it seems we're circling back to that, with a lot of complexity added in between.
I'd wager that the mere act of offloading the rendering is in itself more resource intensive than entire terminal emulator programs we were using 20 years ago.
Re: Race to the bottom (Score:2)
A terminal generally needs very little rendering. Progress bars and the like can easily be displayed without any complex rendering. That's the joke. Now I am happy to hear counter arguments but I too found it a bit strange. At best the use case is to combine a file explorer and a terminal but again maybe I am just not thinking hard enough.
Re: (Score:2)
no it doesn't. a terminal is supposed to just render text. how fast do you need text to scroll? do you think an integrated card isn't capable to do this? wasted electricity of offloading this to a $1200 GPU
now, i have windows terminal, but because it does tabs
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
no it doesn't. a terminal is supposed to just render text.
Who said it couldn't have nice background, transparencies and quick draw text? With your mentality, 90% of current techs would have never been invented.
Re: (Score:2)
Don't fonts require rendering these days?
I use a variety of fonts because I do a lot of work with texts in other languages (and more importantly, non-Roman scripts). I don't know. for sure, but I'm guessing those don't just show up on the screen like your chosen font did back in the 90s.
Re: (Score:1)
a terminal is supposed to just render text.
Yes so why not do that on the processor designed for rendering?
do you think an integrated card isn't capable to do this?
You mean an integrated GPU? Yes I think an integrated GPU can perform GPU-accelerated work, it absolutely is capable of doing it hence the reason they are offloading this work to that integrated GPU rather than doing in on the CPU.
wasted electricity of offloading this to a $1200 GPU
Why does it have to be a $1200 GPU? What's wrong with the integrated GPU (if it's available)? More to the point it's going to use less electricity by leveraging the most efficient processor to complete the task.
Re: (Score:2)
If your framebuffer has difficulty scrolling 2d text then something is wrong.
Re: (Score:1)
I didn't think a GPU accelerated terminal would be a big deal, but you'd be amazed at how noticeable the difference is.
I will say that throwing tons of text through the Windows terminal is still noticeably slower to me on a beefy windows PC with a GTX 1070 than it is with my work laptop using KiTTY (with an integrated Intel GPU) on Linux. Accidentally dump a massive file to the terminal or do an overly crazy file listing? It's so much faster than an unaccelerated terminal it's not even funny.
Re: (Score:2)
I laughed at that too.
"Look how fast I can list this directory!!"
Re: (Score:2)
Re: (Score:2)
I'm laughing at the need for a GPU accelerated terminal.
Made me laugh too, but know I'm intrigued by why something like that exists. I'll def be checking it out over lunch.
Re: Race to the bottom (Score:2)
Nice username.
So your main argument is lists are a poor data structure for conveying information. I just want to make sure I get that right on this site for needs.
The GPU accelerated SQL server sounds interesting. Which one were you interested in?
Relation to infoWars? (Score:1)
Is InfoWorld related to infoWars, or why would the random picks of this random org matter?
GPU accelerated terminal (Score:3)
A true, ridiculous IT story:
In my first student job, 2006 or so, one of the first problems I solved for money, was this big data import script in a university system. "It's just sometimes really slow, but just sometimes, it's random." It was a Perl script that processed tens of thousands of records per run from a CSV file.
Why was it slow? Because it ran on a single core Windows machine, via Cygwin, and spit so much to stdout that rendering the terminal was eating 50%+ of the CPU. Minimizing the window sped it up dramatically. This is why it was inconsistent. Sometimes people were minimizing the window, sometimes not.
I probably should have fled the whole profession immediately.
Today it's more about battery life on laptops, but still, it can be a meaningful amount of CPU.
Re: (Score:2)
That's not because of rendering, printf itself is very slow. There are some mutexes wasting time.
Re: (Score:2)
Re: (Score:2)
Yeah, while I can't dig up all the specifics of a setup from fifteen years ago, I'm pretty sure that's right. Redirecting stdout to a file also ran far faster. I'm pretty sure it was just the rendering on the (I think Windows 2000, might have been XP) terminal it was running on, was indeed that slow.
Re: (Score:3)
It's not too unusual.
A plain text terminal is very fast at dumping text to the screen because you're only updating a text buffer and the text drawing is handled by a character generator chip in hardware, pulling from a character ROM. The slow part is scrolling but you're only doing a small tiny bit of RAM of around 4K or so.
Even so, however, writing can be slow because it's going over to the video memory which is on an external bus.
On a GUI though, text rendering goes through many more software layers - the
Re: (Score:2)
The other problem is the terminal is almost always blocking - you emit a character to stdout and the system call doesn't return until the character actually is drawn to the screen.
So a GPU accelerated terminal is one thing, but unless absolute interactivity is required, you can seriously speed things up by ... redirecting to a file. File I/O is universally buffered and even if you decide to show it on screen. it doesn't impact the program operation because the file I/O is taking data as quick as it is emitted while the display of said data is done in another thread or process and thus doesn't block the main computation.
This sounds like there is a major opportunity of terminal speedup. If one can instruct the terminal "hey from this point on stdout can run async and return without waiting the character(s) to be drawn" then many console scripts will be a lot more efficient. The script will only need to change the mode back right before they ask for user interaction. (Or the terminal is smart and change automatically.)
Re: (Score:2)
This webpage is a crime against humanity (Score:2)
This webpage is a crime against humanity.
It's a slideshow and individual slides, and you're speed limited looking through them. Whoever thought of that should be publicly shamed and not be allowed to ever hold any job impacting any kind of user interface.
Re: (Score:2)
Re: (Score:2)
What a horrible webpage. I could only see half a logo for each slide, and could not scroll down, so I gave up.
Is Crystal a Julia rip-off? Why is it on the list? (Score:4, Interesting)
From the 2012 blog post [julialang.org] of the Julia language:
"We want a language that's open source, with a liberal license. We want the speed of C with the dynamism of Ruby. We want a language that's homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. Something that is dirt simple to learn, yet keeps the most serious hackers happy. We want it interactive and we want it compiled.
(Did we mention it should be as fast as C?)"
And seems like Crystal is the same only ~10 years later [infoworld.com].
Re: (Score:2)