News for hackers. Stuff that matters.

lotwxyz

Re:A CLI Front End for WebSQL and the Hacker News API on Thursday March 12, 2020 @06:15PM (#22562478)
I just created another command called "hnitemkids" that waits for the kids property of an item (ie comments) to be updated. So far, here is the only output I see...

  0 kids found
Oh well, at least I don't need to keep refreshing the browser window any more :-)
Re:Stream the current largest item id in Hacker News on Friday March 06, 2020 @03:14PM (#22506873)
I found out there was a Hacker News Firebase API like one hour (or so) ago, and decided to see if I could integrate it into Linux on the Web. Of course, there are many more possibilities in terms of applications (both for the desktop and the shell) than this little jobber.
Re:Pair Programming Economics on Friday March 06, 2020 @10:54AM (#22504531)
This is a wiki that only serves user-agents that are capable of executing JavaScript. Weird.
Get into developing web technology. The web is the crucial "space of freedom" within which all other modes of freedom (political or otherwise) currently depend.

I want to start tackling these big issues, too...

That's why I created a new kind of operating system, which runs in web browsers, called Linux on the Web! Online desktop here: https://lotw.xyz/desk.os

The idea of creating cross platform desktop applications is why I created Linux on the Web. First of all, it is merely a website, so there is no concept of downloading anything, and needing to give system-level permissions. But it is a website that looks, acts, and most importantly feels like any other desktop environment in the world.

I have been working on this, nearly full-time, in one form or another, since 2011, ie, near the beginning of the Chrome/v8/nodejs-led webapp "blastoff" point. You can give the desktop environment a try at https://lotw.xyz/desk.os (pay attention to the bottom-left corner of the screen).

My main audience at the present time is people just like yourself, so hopefully we can keep in touch (I'm Dennis). There are ways to communicate built into the interface.

> One of my weaknesses as a grad student is a tendency to want to multi task and take on many side projects (as evidenced by the above youtube video and the text you are reading now).

Yeah, this is my downfall as a human being, which is why I needed to build a singular project [0] that could be used as a sort of containment system for all of the particular side streets, dirt roads, and barely trodden pathways that my mind can wander into. That way, even if those ventures do not themselves turn into anything of any practical benefit, they at least then at least the "meta thing" in which they live is still being constantly used, tested, and improved when necessary.

[0] https://dev.lotw.xyz/desk.os

Re:The growth of command-line options, 1979-Present on Tuesday March 03, 2020 @10:40AM (#22475325)
In my web-based shell implementation [0], I use a library concept, such that you have to "import" commands into the current execution environment. You can either do this kind of thing:

  $ import fs
This imports all the commands in the 'fs' library, without any concern for namespaces, and if there are any already existing commands with the same name, they are not overwritten (the new ones are not imported).

But if you do this:

  $ import fs as myfs
Then, all the commands in the 'fs' library are invoked like this:

  $ myfs.vim
[0] https://dev.lotw.xyz/shell.os
Re:A Text Renaissance on Saturday February 29, 2020 @10:14AM (#22450927)
What about websites that have good, solid text editors (like vim) integrated into them, and are able to store files locally, and access them via CLI [0]? Could that be seen as part of this text renaissance? Or do you need to have some kind of post modern literary angle to participate in the festivities?

[0] https://dev.lotw.xyz/shell.os ("help" is your friend!)

Re:Was Knuth Really Framed? on Thursday February 27, 2020 @03:51PM (#22437699)
My Unix philosophy to showing people what a web-based 'ls' command looks like is this:

  $ import fs && import util && comstr --nowrap ls | pretty | less
(Works here: https://dev.lotw.xyz/shell.os)
Re:Rome: An experimental JavaScript toolchain on Thursday February 27, 2020 @03:26PM (#22437409)
You can use all the fancy terms for the mangling and intentional obfuscation of crappy code that you want. Sure, you might think that minification is a valid use for such tools, but really, there is no alternative to just sitting down and writing the right code so that it may eventually become a standard thing, and so we won't need to keep reinventing the wheel over and over again.

I know of what I speak. I am in the process of turning the world of web development upside down with Linux on the Web (https://dev.lotw.xyz/desk.os).

Re:The Effect of Pipe Capacity on Unix Pipeline Performance on Thursday February 27, 2020 @09:20AM (#22433448)
Believe it or not: I have to deal with issues just like this over in webdev-land! (See the Terminal app in https://dev.lotw.xyz/desk.os or skip right to it, go to https://dev.lotw.xyz/shell.os)
Re:Rome: An experimental JavaScript toolchain on Thursday February 27, 2020 @08:43AM (#22433120)
> Javascript should innovate at higher levels

Until that level takes the problem of in-browser, persistent file/blob storage seriously, the JS ecosystem will not be able to truly progress, particularly when it comes to the question of linking evolving code bases with more stable libraries. But I digress. (I'm not going to "pimp" for my project now... see my comments!)

Re:Rome: An experimental JavaScript toolchain on Thursday February 27, 2020 @08:33AM (#22433054)
You can't compile the code of scripting languages, so please stop using that term. You may be doing something to the "source code", but it is not compiling! And I would argue that the thing you are doing to that code is never a good thing.
I think the underlying motivation in this comment is that there are very many technical application development challenges which can be solved simply by web developers paying close attention to the fundamentals of their craft rather than relying on "fancy tricks" to speed up the development process. Plugins like Flash used to be one kind of "fancy trick" to offload into another layer, but there were many developers who stayed faithful to the process of working with everyday browser capabilities (and all of the politics that these capabilities entail), so that the wrinkles could eventually be ironed out. I think that so many who go the "Electron"-ic development route are afraid of getting their hands dirty with the question of in-browser client-side storage, ie, they want to be able to get their hands quickly on the files in the user's native file system.

There are, however, very stable in-browser ways of dealing with the question of client-side storage. IndexedDB is one. But there is another that I am quite partial to, called the File System API. I use it to locally store the files and code in the browser-based OS called Linux on the Web (https://dev.lotw.xyz/desk.os).

Re:MSPaint in JavaScript on Tuesday February 25, 2020 @07:43PM (#22419186)
> No bs web ui here.

You ain't seen nothing yet: https://dev.lotw.xyz/desk.os

Hint: "Bootstepper mode" is always fun... https://dev.lotw.xyz/desk.os?bootstepper=1
Haha, I can't imagine even one file anywhere in the world that I own that anyone would find immediate value in possessing. We can continue this conversation in the LOTW desktop... either via the Mail or Forum app (you need to create a user account first, but that's not too hard to figure out in the interface). Just hit the Start ahem the Begin button to find them!
That's meant to be a throwback to the look and feel of the 90's when you saw so many bare bones Apache index.html listings that were something like that.

What you are seeing there is highly controlled, no-nonsense output, ie, what you might expect out of something that is a legitimate kind of "Linux" on the Web.

What I need to worry about on the backend is 500 errors that might leak some kind of info, and I am very vigilant of those... even though I think app engine does a pretty good job of making sure that nothing vital does get leaked out.

My theory on safety: there's more safety in a world where things just work better. I think that LOTW can crank that idea of "things working better" into overdrive!
1) It's served over https.

2) All the files in the local file system are completely the property of the user. The js makes no attempt to do any snooping or uploading. You can verify that by looking at the network activity.

I've been hacking on this thing in form or another since 2011!