Slashdot Mirror

Has anyone tried running JSLinux (Or JSWindows) under Electron, and start Electron in there? For MAXIMUM WHATWG!
Cause if it is implied, that running an OS (the HTML5 platform) on top of an OS, ... Then "It's VMs all the way up!" surely is the ideal dream state that the WhatWG targets. Until every last cycle and bit is used up.

Nothing really new, emulator "apps" could be loaded for ages, I find the original web browser emulator tech way more interesting, useful and convenient: https://bellard.org/jslinux/ This is basically nothing new and just a browser slapped with the existing emulator code slapped together,

You mean, absolutely anything, like JSLinux? https://bellard.org/jslinux/

If Javascript can run a Linux distro in your Web browser, what can't it do?

Are you aware that the Linux operating system has been implemented in Javscript, and will run in your browser?

https://bellard.org/jslinux/

How can one NOT recognize this as real programming! Performance, as you can see, is not bad.

BPG is based on HEVC. The patent licensing situation around HEVC is a complete mess with three different patent pools from which you need to get three separate licenses from and some HEVC patent holders (like Technicolor) are not in any patent pool so you also need another license from them.

Fortunately, AV1 is licensed under royalty-free terms and has no such hassles.

I am beginning a project to port the Linux kernel to webassembly.

No need. JSLinux already runs Linux in the browser. JSLinux can also run Windows 2000

I am beginning a project to port the Linux kernel to webassembly.

No need. JSLinux already runs Linux in the browser. JSLinux can also run Windows 2000

https://en.wikipedia.org/wiki/Inner-platform_effect

Now all we need, is a CPU that natively executes WebAssembly, and run a Browser in it, to come full circle.
(Because we already had jslinux. :)

I would support removing popups altogether as you say. I would not support removing Javascript. Applications need Javascript. More and more applications are moving from platform-specific (eg, Windows) applications into the browser.

Maybe there should be some highly visible difference between sites that use Javascript and those that do not? Like the tab changing color -- just to throw up a silly idea.

If Javascript could only affect that one tab that it runs in, then what harm could Javascript do?

Javascript is valuable because you run Linux within a PC emulator written in JavaScript..

Thus, you can have MAME
running on Linux
running on an emulator written in Javascript
running on IE
running on Wine
running on Windows Subsystem for Linux
running on Windows 10
running on VirtualBox
running on Linux
running on the bare metal.

Now why would you want to kill Javascript?

(And yes, Wine now runs on Windows Subsystem for Linux.)

Don't worry, we can fix it with an extra layer. Be sure to run your jsx parsing code that generates javascript that generates HTML (I'm not making that up, it's the modern strategy) inside a VM. For best results, add Docker as well, it makes everything better.

The problem here is it wasn't deployed in Docker. With a real database like Oracle. The whole thing should be run in the browser to give it an extra layer of containerized security.

Some fool is bound to write a virtualization system in Javascript one of these days.....

A determined fellow did (well nearly, it's a PC emulator in JS - that runs Linux)

Not quite the same. Nice try though. To satisfy my requirements it should provide virtualized hardware to guest operating systems which should require no modifications to their kernel. Potentially running Windows 10 or Ubuntu.

Some fool is bound to write a virtualization system in Javascript one of these days.....

A determined fellow did (well nearly, it's a PC emulator in JS - that runs Linux)

BPG is better and can be accelerated.

Download some of the min C compilers and adapt it to generate the code you need.

E.g.: http://bellard.org/tcc/

But if you google https://www.google.de/search?q... you find dozens.

Well it is nice, but it is late. 11 years ago we (one person at least) knew how to transmit both analog and Digital, yes digital with a homebuilt equipment [bellard.org]

You joke...

http://bellard.org/jslinux/

Done.

No sweat. We've got better alternatives..
Something like this would give BPG a nice boost in usage and move JPEG to the awkward wayside together with GIF.
Go right ahead, I say.

Or there is always BPG files, which already work on current browsers with a simple JS renderer.

http://bellard.org/bpg/

It only works if it's all running in the browser. Bonus points for running asm.js.

recently? http://bellard.org/dvbt/

It's compiled into javascript, so it doesn't have any more exploit-ability than javascript itself has. You can run linux in your browser too.

According to this page outlining GCC's backend mechanism, I can see why it's *slow* at times.

One of my friends told me that tcc compiled a linux kernel in 10 seconds

joe, ersatz emacs, microEmacs, QEmacs, ...

Lots of choices out there for simple editors that don't need a lot of resources. But that said, emacs and vim run like a champ on my Raspberry Pi.

JavaScript runs Linux.
What could possibly go wrong?

I agree with you about MP3/Ogg - but the Javascript decoder (used for example in http://bellard.org/bpg/gallery...) could make all the difference.

Basically it means that the server admin can reap the benefits (bandwidth) while the user has to handle the legacy conversion (Javascript runs on the user's machine). Therefore there is practically no downside for those who decide what is on a webpage.

And once this format is even just semi-widespread, browsers will start to support it too - and then it's a standard.

I realize that this is Slashdot and we have a great tradition of not RTFA, but given that this is about an image format you could at least go LATFP (Look At The Fucking Pictures). It's also an impressive display of how well image deciding using JavaScript works (but then, this is the guy who wrote an entire x86 emulator capable of running Linux using JS, and even made it work on IE; I have no doubt as to the man's skill in that realm).

Link for image format and quality comparisons: http://xooyoozoo.github.io/yol...
Link for info about the image format and links to more comparisons: http://bellard.org/bpg/

Doing some investigation, the claim that the BPG decoder is "small" might not be exactly true. The decoder, even minified, clocks in at 237 kB.

Although this is mitigated since the decoder could be cached in the browser cache, making it so that the decoder could be downloaded just once - at least just once per session. And once per web site, of course, because everyone is going to host their own copy of it. (I imagine at least... would same-origin policy be a problem if you tried to keep it somewhere central/standard?)

Anyone deploying this would be advised to consider if the space savings outweigh that initial cost in space. Then again, it all depends on what you want to acheive. What if you just have a huge archive of seldom-accessed images and want to save on disk space rather than on network bandwidth? Might make sense to store the images as BPG server-side and do decompression server-side if you can take the CPU hit.

On the flip side, what you can do with JavaScript Apps today is far beyond most of what could be done with native apps in the late nineties. There are even a number of system emulators written in JavaScript that fully emulate systems from the late nineties....

If the web browser supports Javascript, then you may be able to run Linux inside the browser using something like jslinux, so you could compile an Emacs to run inside the web browser inside your Emacs.

I do expect that some day, many browsers will come with a standardized sand-box that does fulfill all these requirements

It's called Java, and of course that worked out well.

On the other hand, Javascript is fast enough to emulate x86, so I suppose you could say that day has already arrived, assuming everyone implements a safe VM in Javascript.

Question, what does R do that other lingos cannot?

Nothing. I'm sure other languages can do everything R can do.

This is an interesting point, which I'm going to veer slightly off topic with. All general purpose programming languages* can do _precisely_ the same things. All fit the requirements to be "Turing complete". ANY Turing complete language "A" can emulate any other Turing complete language "B", and therefore "A" can do the anything that "B" can do. Since "B" can also emulate "A", the two languages can do precisely the same things. (Church-Turing thesis). An interesting example of this is that JavaScript can do everything that CPU microcode can do, as shown at http://bellard.org/jslinux/ .

Therefore, the question is never "which language can do more", it's always "which language can do it most quickly, most securely, etc." C is often faster than Java for many operations. R is more convenient for statistics, PHP 5.3 makes security bugs less likely than PHP 4.0, but all of those languages can run the exact same programs.

Contrast HTML and XML, which being markup languages rather than general purpose programming languages, are not Turing complete. Standard regexs are also not Turing complete, though Perl's extended regexs very well may be.

for the flamers that say you need expensive equipment, there are always the heroes that can make it happen with low budget

http://bellard.org/dvbt/

so now we just need a power amplifier, and its not a 1MW PA. A 100W will do

Wait for someone to run a javascript x86 emulator

Jslinux. Enjoy.

Not only that, but with digital TV, they know what you watch and when. With analog TV, they don't. Knowning who watches what and when is a very, VERY valuable business model - just ask Google...

Erm, they don't know who's watching digital TV either. Unless you buy a receiver that phones home, which would be dumb. DVB-T is as open a standard as PAL, you can generate a valid signal from your video card.

http://bellard.org/dvbt/

Real programmers engineer trees to grow punch cards with self-evolving code already punched on them.

I suppose this means that, yes, God is a real programmer. I think that makes perfect sense. The source code for everything is perfectly available (MIT license), but there's no documentation and there are no comments in the code at all. In particular, the build environment is completely left as an exercise for the user. The original developer has been so silent for so long he clearly considers the code "mature" and is no longer considering enhancement requests or bug fixes... they all get marked WONTFIX with the comment "working as designed". Unfortunately the original code is extremely convoluted and seems deliberately obfuscated, so it's not really possible to fix the numerous bugs and errors in the system even if a build environment can be replicated.

Worst of all is the toolchains used... it's like the worst case of "not invented here" and "feature creep" ever. Space-time and matter-energy libraries reference each other recursively to create the atomic system, and then he uses that to create biology programs that are self-replicating and self-evolving, which in turn have their own applications. No wonder reality is so screwed up. It's worse than that Linux VM running in JavaScript.

Not necessarily. Just start with an x86 emulator instead of an OpenRISC emulator.

Really, with Emscripten you can do just about anything. There was a classic Mac emulator posted about a month ago.

A year ago, when I started the project it was simply interest in learning Javascript. I was fascinated by the emulator from Fabrice Bellard http://www.bellard.org/jslinux/
I am a programmer focused on simulations/emulations and performance. I was also interested in learning the internals of how a computer nowadays works. The x86 CPU is way to compilcated. You lose the clear sight for stupid details like the A20 gate. The OpenRISC project is perfect. It is a CPU with a very easy and clear CPU. Nothing historic. It has even some similarities with byte code, which makes it very fast if you emulate it properly. I optimized especially for running Linux violating the specification a bit.
The whole CPU with MMU fits in around 1000 lines of code. During that day I never expected to get that far. Now with all three cores and devices it needs around 7000 lines of code.

I have a list of useful things you can do with it:
1. Use it as an education system of the Linux system or other tools. For example you could write a git tutorial with live examples.
2. This emulator provides an alternative way to port old software to run on modern systems. In direct comparison to the project Emscripten it is slow, but the porting could be much easier. For terminal applications probably no porting is neccessary at all (e. g. Frotz).
3. The emulated OpenRISC CPU is very easy and contains around 1000 lines of code. So it is the perfect example to learn how emulation works.
4. With network support it allows you to access other computers within the Web Browser providing ready to use tools. (Even an encrypted chat is possible if you run the sshd daemon)
5. Use it as a speedtest for Javascript engines.
6. It is an advertisement for the OpenRISC project.

You can also read the motivation of Ben Burns in his Blog: http://www.benjamincburns.com/2013/11/10/jor1k-ethmac-support.html
And I have to admit that I did the wayland support last time only to get some news. :)

First of all, you don't have the compilers source code.

You have a compiler's source code and the binaries of multiple independently developed compilers or interpreters for the same language. After the bootstrap process completes, you should be several nines confident that this source code is the source code for the resulting binary, provided that the multiple independently developed compilers or interpreters don't all have an identical backdoor. The probability of all readily available compilers having the same backdoor is so small that the result of DDC is beyond reasonable doubt.

Even if you could be sure of that, the compiler was compiled with a compiler

The first Fortran compiler was written in assembly language. So was the first C compiler. So was the first Lisp interpreter. So were the 8-bit BASIC interpreters on late 1970s to early 1980s 8-bit home computers.

Option A is ridiculous. It basically says, verify the compiler is clean by looking at all of the source (an essentially impossible task)

I wonder why a widely used encyclopedia's article about an allegedly impossible task doesn't mention that it's impossible. And for programs intended to fit into a handful of kilobytes, such as the first Fortran compiler or a tiny C compiler, an audit is quite tractable.

You are always running an unvetted program unless you coded it in machine language from the ground up with custom hardware and toggle switches.

You mean like what Kevin Horton did with his NANDputer? In any case, I could take one of those 8-bit BASIC ROMs, desolder it, hook it up to toggle switches and LEDs, read it out bit by bit, and verify that it matches the disassembly. And yes, mass-produced 6502 CPUs and BASIC ROMs have been decapped and photographed to make sure no funny business is going on inside the ROM chip itself.

Yes. Words have meanings. You are just not using those meanings. Case in point: http://bellard.org/jslinux/

Since the entire emulator is written in JavaScript to run in a browser, and using that tool, you can write and self compile the Linux kernel, by your definition Linux kernel developers are not "programming". Literally, any application that can be written can be written to run in a browser using JavaScript. The only question is how hard it would be to write, and how fast it would run.

Obviously, your use of words have no meaning, and you should reconsider how you use them if you want to successfully communicate.

Tada! JSLinux: http://bellard.org/jslinux/

yes! http://bellard.org/jslinux/ wait for it to boot, then just type "emacs", have fun!

Do you prefer a slow emulated real system, or a fast but minimal toy?.

Not that impossible, actually.

We are so close to a Web-based operating system I can taste it.

Technically, we're there. Runs on the iPhone, too, so if you ever dreamed of running Linux on your iPhone, there's your chance.

Sorry, but to have a android device that can transmit and receive ACARS is close to impossible.

I would not bet on that !

The lasts superphones embeds so much high speed subsystems (2,3,4G/WiFia,b,n,g/BT/FM/AM/NFC/RFID/PAL/NTSC/HDMI/USB2,3/Audio/ and certainly a few more at each generation) that there are probably capable of processing some signals at virtually any frequencies if some high skilled hackers are motivated to do it.

Analog filters never cut abruptly; DSP can be reprogrammed to abuse the surrounding components. Any interfaces can leaks some creative signals. Take a look at this for example: http://bellard.org/dvbt/

http://bellard.org/jslinux

A full x86 emulator written in JS. It happens to load a Linux image into it, but you could easily use a BSD one instead. Pretty cool... but not quite as cool as compiling the OS to run in JS directly.

Pfff, writing Linux kernels in Javascript is so last century. Nowadays we RUN kernels in Javascript!

most of the courses I spend all my time on are far removed from the skills I need to succeed as a web developer. But on the other hand, I can't imagine another degree that would allow me to stay in a programming mindset. The fact is that web development has taken huge bounds in the last few years, and sadly most universities haven't caught up. Computer science is a field that overlaps with web development, but getting a computer science degree to become a web developer is like getting a zoology degree to become a veterinarian.

Once upon a time, I (and I think most "real" programmers) looked down on web development as "toy" development, the sort of thing a company's owner's "good with computers" nephew did as an excuse to put him on the payroll.

As you correctly point out, though, web development has very much become a form of "real" programming, in some ways more complex than doing native apps. Between communicating with a backend datastore (generally some form of SQL); controlling nontrivial UI logic and AJAX (or comparable) updates through several layers of code from native on the server to client-side Javascript; and now HTML5 has basically made the browser as close to a "native" environment that speaks Javascript as we could ask for - You very much do need a CS degree (or at least that level of understanding) to do any serious web development in the present world.

Aside from the variety of HTML5 demos Google has put together to show off its graphical capabilities, check out Fabrice Bellard's Javascript PC emulator booting into an actual 2.6.20 Linux (CLI, at this point) environment. When "web development" now includes potentially needing to write device drivers, don't think you can take a "CS Lite" degree and jump into a job. If anything, consider your specialty an extension of the core requirements for CS, not a stripped-down version.