FWIW: when I ported the DomTerm terminal emulator (see separate response below) to WSL, it went surprisingly smoothly. The domterm command is a split front-end/back-end application: The back-end is a WSL command-line program written in C. It handles argument parsing, ptys, forking, http and wesocket serving, daemoniation, unix-domain sockets, and more Linux idioms. Very little had to be changed for WSL - mainly changing some file paths. The front-end handles the UI and is a Windows application: You can either use your regular Windows desktop browser (Firefox and Chrome both work), or you can use an Electron wrapper, which is somewhat nicer. (The Electron wrapper is basically a small amount of JavaScript code that requires an Electron binary that you can download from GitHub.)
Can I suggest you check out DomTerm?
It has the functionality of gnome-terminal (and then some) but does not require an X-server.
Instead, it uses Electron, which (in my biased opinion) makes for a very nice interface.
This article focuses on DomTerm on WSL.
The release page includes pre-compiled WSL binaries.
In the old days I used old-fashioned tuner cards, but for years I've been using an external HdHomeRun network tuner. Just put one of these little boxes where convenient, connect antenna cable, and ethernet (WiFi is also an option). This means you can run MythTV on almost any PC, such as an discarded laptop, as long as it has HDMI output and sufficient storage (optionally USB).
The article is misleading in suggesting that driving from Kristiansand to Trondheim currently takes about 20 hours. It does that if you roughly follow the coastline. However, there is already a much faster route going through Oslo.
Where floating tunnels may make sense is for shorter trips - for example Bergen to Ålesund.
Thanks. Kawa has what one might call "optimistic typing": The compiler calculates the type of an expression, and compares it with the type required by context. It only complains if this intsection is empty. In contrast, in traditional strict typing the compiler requires that expression type be a sub-type of the required type (unless there is an explicit cast). I've thought about adding an option to Kawa (it wouldn't be the default) to implement strict (sub-type) typing. However, that would require various changes and some thought to make palatable.
Groovy has optional static types, while Scheme does not out of the box.
However, Kawa does have optional static typing.
That, plus careful language design, plus a smart compiler, means that Kawa code run very faster - much faster than Groovy or Clojure or JRuby or...
Ask Rich Hickey that: Kawa (1996) is 11 years older than Clojure (2007).
The linked LWN article meantions some reasons: Among them that Kawa is much faster than closure (both execution speed and start-up speed). Plus some might like that Kawa is mostly-compatible with a pre-existing independently-specified language.
"Something that I find strange is how fast kawa seems to be [even] in the repl."
Note that Kawa does a full compilation (to bytecode), with all the optimizations, even in the repl.
(Of course it only optimized one line/command at a time in that case.)
The downside is that Kawa is a little fragile if you redefine things in the repl; hence I advise using the --no-inline option for the repl.
It's on the list of things to work on when we get a chance.
Neither Java or Kawa are "traditional compiled language" in the same sense as C or C++. However, Java as a language (rather than as an implementation technology) is much closer in style to C++ than (say) Python or Ruby. Java has lexical scoping, static name resolution, ahead-of-time compilation (albeit to bytecode), does lots of compile-time error checking. In the current environment, Java (and Scala) are considered closer to "traditional compiled language" than languages like Python or Ruby, which are considered "scripting languages". Of course there is no hard distinction between the two kinds (except marketing) - and Kawa aims at the strengths of both kinds.
The Kawa 0.1 interpreter from 1996 was written by Alex Milowski, who is indeed Polish-American.
I took it over in 1996, and re-wrote it as a compiler. At this point, I doubt any of Alex's code still exists.
I'm Norwegian-American, and Kawa means nothing in Norwegian. Still, I saw no reason to change the name.
Aside from the fact that it's Just Plain Horrid(TM) to read or write in source format, TexInfo suffers from the same problem that HTML does: No semantics.
You don't seem to know much about Texinfo. It is definitely very much about semantics - quite like DocBook.
I agree DocBook takes the semantics thing slightly further than Texinfo - but it has big holes too: For example
DocBook doesn't have a standard way to specify the structure of a command/function synopsis except for the C language.
The reason that DocBook is so "verbose" is that it actually indicates what things are.
One reason DocBook is so verbose is because it is XML, which by definition is verbose and human-unfriendly.
I've written plenty of documentation in both Texinfo and DocBook. They're both reasonable formats, but it is clear that DocBook is very tedious if you have to write it "by hand" rather than use a word-processor. Texinfo is much easier to both read and write, and it handles the "semantics" pretty well.
Texinfo is is a decent format for writing documentation in - nicer and less verbose than HTML or DocBook.
You can generate either HTML or DocBook or XML from Texinfo, and then do a bunch of processing on it.
For example the documentation for Kawa is written in texinfo, then makeinfo converts it to docbook, which is then converted to html.
The result isn't splashy but (if I say so myself) fairly nice.
I honestly hate to go into this because you're right for the most part but most cases in the average metropolitan area have overwhelming evidence.
I'm skeptical, given how frighteningly many cases where someone has been proven innocent after years in prison based on a single eye-witness or jail-house informant, which we know are extremely unreliable, or scientifically bogus evidence, or coerced confessions and plea bargains.
Right, but the suggestion was of using JRuby for the Ruby implementation (including Rails), and using "real Java" for the performance bottlenecks. I responded to a comment making fun of that idea.
Now, ensure that you also score memory performance.
"Memory performance" is not a goal in itself - it only matters to the extent that it affects speed (though GC, cache misses, and so on). (And of course if you don't have enough memory to run your application at all or without paging, but that's seldom a problem these days.)
Note I'm not saying that memory usage is unimportant - today calculation is free and
accessing non-cache memory is expensive.
But nobody cares about memory usage except to the extent that it affects speed.
As you point out, these are short artificial benchmarks, so they may not tell us much about real-world performance.
My point remains: Don't dismiss the performance of Java. A lot of smart people have worked hard on making Java run fast, and that is one reason
it is widely used in "the enterprise".
This is why Java-style (C#-style, Python-style, whatever) references are good. They don't point to any real memory, but rather into a list of objects, where the real pointers are located. When compacting memory, only this list would have to be updated, as no data contains real pointers that would have to be updated and all pointers are available in this list.
That's usually not how modern high-performance garbage collectors work.
They use "direct pointers", just as in C++. When compacting memory,
the data does contain real pointers that have to be updated.
The power connectors seem to be still different. Also you probably need some kind of mounting bracket to keep the drive physically in place, unless you have a case designed for the smaller laptop drives.
The summary makes it clear these are for desktops, not laptops, data centers, or anything else.
And to clarify (since the Original Article's title is wrong): these are announced as the most efficient
desktop hard drives, because
laptop hard drives are already much more efficient than desktop hard drives.
In fact, if you want to build an energy efficient desktop, a good
way is to use a laptop hard drive with an adapter.
What I'm waiting for a compact laptop/hand-held with a daylight-readable display. That's what would make a OLPC clone interesting to me, and as it appears the Asus doesn't have such a display, I'm not interested. (Of course others may find a low-cost light-weight mini-laptop very useful.)
To view the data on the CD/DVD you need to use the WikiX application, which is platform-specific (no PPC support, for example). What I would have done is to store the articles as XHTML (making use of CSS and JavaScipt). Then the articles could be viewed with any browser. It would also be more useful for long-term archival use. Why didn't they do that? One reason might be data compression (store the articles is a compressed format so more could fit on a CD or DVD). Another reason might be some user-interface feature that can't be done using JavaScript, such as searching. If so, you could provide a choice of interfaces: WikiX (which allows searching and a slightly nicer user interface) or "any browser".
I haven't heard anything about a patent re-examination.
Has Vonage requested that? Has the patent office really re-affirmed the validity of these apparently overbroad patents? If not, why didn't Vonage ask for a stay (preferably before the verdict) so the patent office could re-examine the patents? Didn't they learn anything from the Blackberry case?
Slashdot Mirror
FWIW: when I ported the DomTerm terminal emulator (see separate response below) to WSL, it went surprisingly smoothly. The domterm command is a split front-end/back-end application: The back-end is a WSL command-line program written in C. It handles argument parsing, ptys, forking, http and wesocket serving, daemoniation, unix-domain sockets, and more Linux idioms. Very little had to be changed for WSL - mainly changing some file paths. The front-end handles the UI and is a Windows application: You can either use your regular Windows desktop browser (Firefox and Chrome both work), or you can use an Electron wrapper, which is somewhat nicer. (The Electron wrapper is basically a small amount of JavaScript code that requires an Electron binary that you can download from GitHub.)
Can I suggest you check out DomTerm? It has the functionality of gnome-terminal (and then some) but does not require an X-server. Instead, it uses Electron, which (in my biased opinion) makes for a very nice interface. This article focuses on DomTerm on WSL. The release page includes pre-compiled WSL binaries.
In the old days I used old-fashioned tuner cards, but for years I've been using an external HdHomeRun network tuner. Just put one of these little boxes where convenient, connect antenna cable, and ethernet (WiFi is also an option). This means you can run MythTV on almost any PC, such as an discarded laptop, as long as it has HDMI output and sufficient storage (optionally USB).
Where floating tunnels may make sense is for shorter trips - for example Bergen to Ålesund.
Wrong. Iceland is generally considered part of Europe
Thanks. Kawa has what one might call "optimistic typing": The compiler calculates the type of an expression, and compares it with the type required by context. It only complains if this intsection is empty. In contrast, in traditional strict typing the compiler requires that expression type be a sub-type of the required type (unless there is an explicit cast). I've thought about adding an option to Kawa (it wouldn't be the default) to implement strict (sub-type) typing. However, that would require various changes and some thought to make palatable.
However, Kawa does have optional static typing. That, plus careful language design, plus a smart compiler, means that Kawa code run very faster - much faster than Groovy or Clojure or JRuby or ...
Yes. (I suggest reading the LWN article linked in the submission - it's fairly short.)
The linked LWN article meantions some reasons: Among them that Kawa is much faster than closure (both execution speed and start-up speed). Plus some might like that Kawa is mostly-compatible with a pre-existing independently-specified language.
"Something that I find strange is how fast kawa seems to be [even] in the repl." Note that Kawa does a full compilation (to bytecode), with all the optimizations, even in the repl. (Of course it only optimized one line/command at a time in that case.) The downside is that Kawa is a little fragile if you redefine things in the repl; hence I advise using the --no-inline option for the repl. It's on the list of things to work on when we get a chance.
Neither Java or Kawa are "traditional compiled language" in the same sense as C or C++. However, Java as a language (rather than as an implementation technology) is much closer in style to C++ than (say) Python or Ruby. Java has lexical scoping, static name resolution, ahead-of-time compilation (albeit to bytecode), does lots of compile-time error checking. In the current environment, Java (and Scala) are considered closer to "traditional compiled language" than languages like Python or Ruby, which are considered "scripting languages". Of course there is no hard distinction between the two kinds (except marketing) - and Kawa aims at the strengths of both kinds.
You're off two decades: Scheme is from 1975.
I took it over in 1996, and re-wrote it as a compiler. At this point, I doubt any of Alex's code still exists. I'm Norwegian-American, and Kawa means nothing in Norwegian. Still, I saw no reason to change the name.
You don't seem to know much about Texinfo. It is definitely very much about semantics - quite like DocBook. I agree DocBook takes the semantics thing slightly further than Texinfo - but it has big holes too: For example DocBook doesn't have a standard way to specify the structure of a command/function synopsis except for the C language.
The reason that DocBook is so "verbose" is that it actually indicates what things are.
One reason DocBook is so verbose is because it is XML, which by definition is verbose and human-unfriendly.
I've written plenty of documentation in both Texinfo and DocBook. They're both reasonable formats, but it is clear that DocBook is very tedious if you have to write it "by hand" rather than use a word-processor. Texinfo is much easier to both read and write, and it handles the "semantics" pretty well.
Texinfo is is a decent format for writing documentation in - nicer and less verbose than HTML or DocBook. You can generate either HTML or DocBook or XML from Texinfo, and then do a bunch of processing on it. For example the documentation for Kawa is written in texinfo, then makeinfo converts it to docbook, which is then converted to html. The result isn't splashy but (if I say so myself) fairly nice.
I'm skeptical, given how frighteningly many cases where someone has been proven innocent after years in prison based on a single eye-witness or jail-house informant, which we know are extremely unreliable, or scientifically bogus evidence, or coerced confessions and plea bargains.
Right, but the suggestion was of using JRuby for the Ruby implementation (including Rails), and using "real Java" for the performance bottlenecks. I responded to a comment making fun of that idea.
Now, ensure that you also score memory performance.
"Memory performance" is not a goal in itself - it only matters to the extent that it affects speed (though GC, cache misses, and so on). (And of course if you don't have enough memory to run your application at all or without paging, but that's seldom a problem these days.)
Note I'm not saying that memory usage is unimportant - today calculation is free and accessing non-cache memory is expensive. But nobody cares about memory usage except to the extent that it affects speed.
As you point out, these are short artificial benchmarks, so they may not tell us much about real-world performance. My point remains: Don't dismiss the performance of Java. A lot of smart people have worked hard on making Java run fast, and that is one reason it is widely used in "the enterprise".
Java is quite fast, thank you.
The article poster hasn't been paying much attention ...
Hint: Google for "android g1".
This is why Java-style (C#-style, Python-style, whatever) references are good. They don't point to any real memory, but rather into a list of objects, where the real pointers are located. When compacting memory, only this list would have to be updated, as no data contains real pointers that would have to be updated and all pointers are available in this list.
That's usually not how modern high-performance garbage collectors work. They use "direct pointers", just as in C++. When compacting memory, the data does contain real pointers that have to be updated.
The power connectors seem to be still different. Also you probably
need some kind of mounting bracket to keep the drive physically in place,
unless you have a case designed for the smaller laptop drives.
And to clarify (since the Original Article's title is wrong): these are announced as the most efficient desktop hard drives, because laptop hard drives are already much more efficient than desktop hard drives. In fact, if you want to build an energy efficient desktop, a good way is to use a laptop hard drive with an adapter.
What I'm waiting for a compact laptop/hand-held with a daylight-readable display. That's what would make a OLPC clone interesting to me, and as it appears the Asus doesn't have such a display, I'm not interested. (Of course others may find a low-cost light-weight mini-laptop very useful.)
To view the data on the CD/DVD you need to use the WikiX application, which is platform-specific (no PPC support, for example). What I would have done is to store the articles as XHTML (making use of CSS and JavaScipt). Then the articles could be viewed with any browser. It would also be more useful for long-term archival use. Why didn't they do that? One reason might be data compression (store the articles is a compressed format so more could fit on a CD or DVD). Another reason might be some user-interface feature that can't be done using JavaScript, such as searching. If so, you could provide a choice of interfaces: WikiX (which allows searching and a slightly nicer user interface) or "any browser".
I haven't heard anything about a patent re-examination. Has Vonage requested that? Has the patent office really re-affirmed the validity of these apparently overbroad patents? If not, why didn't Vonage ask for a stay (preferably before the verdict) so the patent office could re-examine the patents? Didn't they learn anything from the Blackberry case?