[HN Gopher] Blink virtual machine now supports running GUI programs
___________________________________________________________________
Blink virtual machine now supports running GUI programs
Author : lnyan
Score : 325 points
Date : 2023-02-03 07:53 UTC (15 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| sebstefan wrote:
| From the same author that did Cosmopolitan C and... Occupy Wall
| Street?
|
| Damn, I don't do enough things
| cypherpunks01 wrote:
| Justine also wrote Rampage toolz 2.0, one of the early "AOL
| Progz" [1]. Can't quite remember which ones I used as a kid
| back then.
|
| She also claimed to have written hacks for Kevin Mitnick.
|
| Justine was somewhat controversial inside the Occupy movement,
| she was outside most circles and was criticized for extremely
| strongly-voiced technocratic opinions (see "Nerds Should be
| Segregated" [2], since deleted), but she's incredibly,
| incredibly talented. A good profile of Justine x Occupy post-
| mortem is here [3]
|
| [1] https://imgur.com/a/uSMr7
|
| [2]
| https://web.archive.org/web/20141102140507/https://justinetu...
|
| [3] https://www.thenation.com/article/archive/breaking-occupy/
| 2h wrote:
| huh damn
|
| https://wikipedia.org/wiki/Occupy_Wall_Street#Origins
| [deleted]
| BoardsOfCanada wrote:
| "In March 2014, Tunney petitioned the US government on We the
| People to hold a referendum asking for support to retire all
| government employees with full pensions, transfer
| administrative authority to the technology industry, and
| appoint the executive chairman of Google Eric Schmidt as CEO of
| America"
|
| So... at least you haven't done _that_ :)
| thatsadude wrote:
| Art!
| septune wrote:
| Are there any limitations in the linux binaries that can run in
| the VM ? (statically linked only ?)
| jart wrote:
| Blink can run both static and dynamic binaries. There are of
| course caveats. See this section in the README:
| https://github.com/jart/blink#compiling-and-running-programs...
| DarmokJalad1701 wrote:
| Is it possible to run Python on it? I guess network I/O is a
| limitation due to the browser environment?
| snek_case wrote:
| For dynamic libraries, does it mean a program running inside
| of blink can make calls to dynamic libraries installed on the
| host system? If so, cool!
| goerz wrote:
| I always think these announcements are about https://blink.sh/
|
| I don't know why it's okay to steal product names like that.
| Kiro wrote:
| Yeah, it sucks that Blink (the shell) stole it from Blink (the
| browser engine) that stole it from Blink (the SIP client) that
| stole it from...
| shadowgovt wrote:
| Trademark protection is around market concerns, and in general,
| open source projects side-step questions of "market" by giving
| everything away for free.
|
| ... apart from that, it's a legit hard problem to name things.
| As in "One of the two recognized hardest problems in software
| engineering" (alongside cache management and off-by-one
| errors).
| gandalfff wrote:
| Could this be ported to run on PowerPC Macs?
| jart wrote:
| PowerPC is one of the 11 hardware architectures on which we
| regularly test Blink using Qemu
| https://github.com/jart/blink/blob/c8dbbc8cf553680ab48d8a304...
| so my guess would be yes. However it depends on how old the Mac
| software is. Blink currently assumes modern POSIX system calls
| are available, e.g. fstatat(), O_CLOEXEC, etc. i.e. you
| currently need a host operating system published after
| ~2010ish. That could change in the future if we end up writing
| a ./configure script.
| asicsp wrote:
| From
| https://twitter.com/StriderMyshkin/status/162141843157589606...
|
| > _A pathway to a blazingly fast WSL?_
| rcarmo wrote:
| WSL2 is already "blazingly fast", and WSL was no slouch either.
| They are both impacted by storage overhead, which makes that
| tweet look kind of misguided.
| drowsspa wrote:
| I hate how low are our expectations of "blazingly fast" these
| days.
| olivermuty wrote:
| Also WASM is fast compared to javascript, slow compared to
| most other things.
| ohgodplsno wrote:
| Depending on your benchmarks, WASM can be 5 times slower
| than C, or equally as fast (sometimes faster).
| https://programming-language-benchmarks.vercel.app/cpp-vs-
| wa...
| thesz wrote:
| WSL2 is not blazingly fast.
|
| I use Haskell for my ever continuing self-education and
| compiling and linking times with ghc under WSL2 is at least
| twice as slow as the same operations under native Linux on a
| much less capable machine.
|
| It is not just me, it is acknowledged WSL2 is very slow in
| I/O: https://www.phoronix.com/review/windows10-okt-wsl/2
|
| I use WSL2 for reasons but I think I will be much better off
| with Linux.
| cercatrova wrote:
| WSL2 with code inside the Linux file system? Because if
| you're doing Linux work on the Windows file system, it will
| be bad. It is at native speeds inside the Linux file system
| though.
| thesz wrote:
| Yes, the file system appears to be Windows one.
|
| I remember no questions being asked when I set up WSL2.
|
| I really doubt that WSL2 will be at native speed with the
| Linux file system, because reads and writes still have to
| go through Windows kernel to be mapped into actual
| hardware reads/writes.
| wongarsu wrote:
| > I remember no questions being asked when I set up WSL2.
|
| If the (WSL) path to your project is inside ~/ it's on
| the linux file system. If it's in /mnt/c/ it's in the
| Windows filesystem. In WSL1 those were about equally
| fast, both going throught the windows kernel. With WSL2,
| accessing /mnt/c/ from Linux has to go through Windows,
| and accessing \\\wsl$ from Windows has to go through
| Linux, so where you put the files decides where they are
| fast.
| csdvrx wrote:
| > In WSL1 those were about equally fast, both going
| throught the windows kernel
|
| Yes, WSL1 was great. I hope it will never be sunset, as I
| need good IO performance.
|
| > where you put the files decides where they are fast.
|
| I also also hope we'll eventually get an option to pass
| partitions to HyperV, which is currently possible only
| with full disks.
|
| It would be a return to the previous WSL1 level of
| performance for files within a NTFS partition: even if
| you'd need a separate NTFS partition, that'd be a minor
| nuisance to guarantee performance.
| cercatrova wrote:
| You are incorrect in the last paragraph but that was
| already explained here. Try putting the files in the
| Linux file system and only using that.
| Kipters wrote:
| They will go through Hyper-V, not Windows
| sz4kerto wrote:
| > I really doubt that WSL2 will be at native speed with
| the Linux file system, because reads and writes still
| have to go through Windows kernel to be mapped into
| actual hardware reads/writes.
|
| No, Linux is running alongside Windows, not under it.
| Windows itself is virtualized when WSL2 is turned on, and
| both Linux and Windows run under Hyper-V. It's quite
| fancy actually.
| madeofpalk wrote:
| > Windows itself is virtualized when WSL2 is turned on
|
| Is there documentation/explainer for this? I've been
| trying to understand more about this (was this a change
| in Windows 11? Is it only when WSL2 is installed?) for a
| while now, but not found anything apart from stray HN
| comments every now and then.
| wongarsu wrote:
| It's the fundamental difference between WSL1 and WSL2. As
| designed in the 90s, the Windows NT kernel can have
| different subsystems that offer different userspace APIs
| to different software. Originally there were the Win32
| subsystem, the Security subsystem, the Posix subsystem
| and the OS/2 subsystem. The latter two fizzled out, but
| WLS1 is basically just another subsystem that provides a
| linux-compatible API to the Windows kernel. As it turns
| out providing full compatability is really hard though,
| so WSL2 is a complete rewrite, ignoring the subsystem
| concept. It basically just runs linux in Hyper-V, and
| adds some UI/UX to make that convinient.
|
| That Windows is then running virtualized is just how
| Hyper-V works, as soon as you turn on Hyper-V the host
| Windows runs as a guest in Hyper-V, though with special
| privileges [1]
|
| https://learn.microsoft.com/en-us/virtualization/hyper-v-
| on-...
| joshuaissac wrote:
| > WLS1 is basically just another subsystem that provides
| a linux-compatible API to the Windows kernel
|
| WSL1 is not an NT subsystem, either. WSU (the POSIX
| subsystem) was an actual NT subsystem, but with WSL, they
| abandoned this concept and went with a different design
| for performance reasons.
|
| https://news.ycombinator.com/item?id=25249262
| thesz wrote:
| https://github.com/microsoft/WSL/issues/2395
|
| This is still a problem with WSL2, at least on my WSL2
| with Windows file system mappings.
|
| I tried to use instructions that use fossil from the
| hctree page: https://sqlite.org/hctree/doc/hctree/doc/hct
| ree/index.html
|
| Fossil employs sqlite to store SCM information and it
| fails with "SQLITE_IOERR(1290): os_unix.c:39533: (22)
| fsync(...)" error, which is the same with VirtualBox:
| https://www.fossil-scm.org/forum/forumpost/7fb6c96d80?t=c
|
| So WSL2, having to put up with Windows quirks, is not
| much a Linux anymore. It is slow and some programs can't
| even run.
| csdvrx wrote:
| A valid critic given that there's no native filesystem
| support yet.
|
| But if WSL2 is given its own drive to mount and do what
| it wants with it, the issue should disappear.
|
| And when WSL2 supports passing partitions, the issue
| _will_ vanish.
| jmmv wrote:
| I wrote something on this topic a while ago:
| https://jmmv.dev/2020/11/wsl-lost-potential.html
| shawnz wrote:
| Note that WSL 1 doesn't use the NT subsystem
| functionality. See this sibling comment for details
| https://news.ycombinator.com/item?id=34640434
| shawnz wrote:
| WSL2 is powered by Hyper-V, which is a "type 1
| hypervisor":
|
| https://en.m.wikipedia.org/wiki/Hypervisor#Classification
|
| https://learn.microsoft.com/en-us/windows-
| server/administrat...
| pacoverdi wrote:
| > I really doubt that WSL2 will be at native speed with
| the Linux file system
|
| I had the same doubts, but when I finally took the time
| to install it, I found out that I was wrong. One Java
| program that I use, which is very heavy on the filesystem
| and slow like hell under Windows it a LOT faster under
| WSL2.
|
| As Java profiler support is poor on Windows, I now use
| WSL2 to run async-profiler sessions and get results as
| accurate as on native Linux.
|
| EDIT to add: you really have to run things fully in the
| WSL2 filesystem, be it for compiling or using a program.
| The performance is awful if you run WSL2 processes under
| the Windows filesystem.
| actionfromafar wrote:
| I wonder how VirtualBox would fare in your use case then.
| Especially since one can tweak I/O settings easily inside
| Linux too.
| jart wrote:
| VMWare is a must for Windows. Code compiles 10x faster in
| a virtual machine on Windows than it does if you compile
| on Windows natively. Or 100x faster if you forgot to
| disable Windows Defender. I've always found that amusing.
| bpye wrote:
| Full transparency, I work at Microsoft on the hypervisor.
|
| What do you find that VirtualBox does better than
| Hyper-V?
| jart wrote:
| I use VMWare Workstation Player to run a bunch of
| different operating systems on Windows, e.g. FreeBSD,
| OpenBSD, Windows 7, etc. It's served my needs pretty well
| for some time. Hyper-V as I understand it is pretty new.
| I think I'm using it to run WSL2 and I'm pretty happy
| with its performance. However I don't know how to use
| Hyper-V as a VMWare replacement. I'd imagine if it's able
| to do that, the learning curve would be a bit higher due
| to the CLI.
| cassepipe wrote:
| Any idea of why this is?
| ohgodplsno wrote:
| Most compilation processes create a lot of very small
| files. Or a metric ton of them if you're unlucky enough
| to do js.
|
| NTFS is awful at doing lots of small accesses on very
| small files, at least compared to Ext4. Add to that the
| fact that if you're on WSL, it needs to write POSIX
| attributes (which NTFS has no support for and therefore
| WSL must emulate), and that's a recipe for builds being
| slowed massively by IO.
|
| As for Defender, well, Defender sees new files and halts
| everything while it scans them. You can see how that can
| be a problem for a process that pops out tens of
| thousands of temporary files, which it will all go and
| scan, locking them while it does so.
| csdvrx wrote:
| > which NTFS has no support for and therefore WSL must
| emulate
|
| With ntfs3 (kernel 6) this is no longer true, as can be
| seen for example in Arch install living next to windows
| on C:\ https://gist.github.com/motorailgun/cc2c573f253d08
| 93f429a165...
|
| Also NTFS has had POSIX attributes support - they just
| weren't used before.
| ohgodplsno wrote:
| Note that I said WSL, not WSL2.
| csdvrx wrote:
| And I insist: NTFS has support for POSIX attributes.
| NTFS3 proves that: you can install arch on C:\, and use
| it normally.
|
| WSL1 doesn't support POSIX attributes, just like ntfs-3g
| didn't support them, but it's not a limitation of NTFS.
| jart wrote:
| Another thing that makes Windows builds go slow is the
| lack of vfork(). On Linux, vfork() lets you create and
| teardown a new process in ~30 microseconds. On Windows it
| takes about 6000 microseconds to do the same thing, which
| is in large part due to the lack of copy-on-write memory
| (which Windows won't support, due to Microsoft corporate
| culture being heavily biased against overcommit models).
| criddell wrote:
| That's not my experience with C++.
| sz4kerto wrote:
| WSL2 is actually just a Linux VM running directly on
| Hyper-V (not under Windows). It provides 99.5% native
| performance.
|
| If you're accessing files through SMB or something then
| sure, it'll be slow.
| meibo wrote:
| If you cross the IO boundary to the Windows FS, yes, it is
| slow and your compilation will be slow. You need to have
| the project in the WSL FS, it's always been this way and I
| get pretty much native performance this way. Your editor
| can navigate to the WSL filesystem instead.
| csdvrx wrote:
| > If you cross the IO boundary to the Windows FS, yes, it
| is slow and your compilation will be slow
|
| If you need good IO performance, WSL1 is still a valid
| option.
|
| I need good IO performance, and it's not clear how much
| of the overhead is due to NTFS, and how much is due to 9p
| (to pass the VHDX file on the NTFS partition to WSL2)
|
| So I'm planning some experiments with OpenZFS for windows
| and NTFS3 (https://old.reddit.com/r/zfs/comments/10lcnpk/
| zfs_raw_passth...), first using a WSL2 kernel with the
| option enabled
| (https://github.com/microsoft/WSL/issues/8564 and
| https://github.com/bioluks/WSL2-Linux-Kernel-NTFS) then
| WSL1.
|
| I have a dual NVMe setup and W11 for Workstations, so it
| should be possible to run a passthrough of both
| partitions to the kernel.
|
| However, it's not clear yet how to do that with a VHD on
| VHDX: most of the documentation I've read about VHD (or
| VHDX) refers to a passthrough as an "old" option:
| https://www.altaro.com/hyper-v/hyper-v-pass-through-
| disks/
| 2fast4you wrote:
| Have you considered swapping Windows and Linux? Depending
| on your use case, you can still get pretty good
| performance out of virtualized Windows if you use PCI-E
| passthrough
| csdvrx wrote:
| I have: I generally prefer Windows, but depending on the
| test results, this option is definitely on the table!
|
| As the computer has 2x NVMe and 2x GPU, it should be easy
| to do a GPU passthrough (with one GPU for Linux native,
| the other in passthough to Windows) but this brings a
| little extra complexity I'd rather avoid if I can.
| peoplefromibiza wrote:
| relevant bits from the comment you're replying to
|
| > _They are both impacted by storage overhead_
| smartmic wrote:
| I agree. If I would stay solely inside the WSL2 VM, it
| might be fast but my problem is that I need a tight
| integration between the Windows and the WSL2 file systems.
| In effect, this is a real pain, especially when it comes to
| I/O. But WSL2 also constantly loads one or more CPU cores
| to 100%+. My whole system feels handicapped. I probably
| have additional problems due to MS Defender, all known
| measures (that I can implement at all in a corporate-
| managed environment) have hardly remedied it.
| denzil wrote:
| Not sure if it helps in your case, but you also can
| access wsl disk from windows side. This could give better
| performance for some uses.
| csdvrx wrote:
| Having to use both msys2 and WSL2 is a bummer :(
| csdvrx wrote:
| It's probably due to hooks on NTFS file open. It
| shouldn't happen for files inside the ext4.vhdx (the /
| partition)
| saagarjha wrote:
| Nope, this won't really be an improvement.
| smcameron wrote:
| If someone is looking for some low hanging fruit in the way of
| contributing to cosmopolitan, they could teach its scanf()[1]
| family about floats[2]. (May not be as low-hanging as it first
| appears though, as converting floats correctly is trickier than
| it might first appear to be. The comments in the code say it can
| do floats, but the comments are mistaken.)
|
| [1]
| https://github.com/jart/cosmopolitan/blob/master/libc/fmt/vc...
| [2] https://github.com/jart/cosmopolitan/issues/456
| jart wrote:
| It'd be really nice to have a good scanf() function. Worth
| noting that we do have Google's outstanding double-conversion
| library in the cosmo codebase
| https://github.com/jart/cosmopolitan/tree/master/third_party...
| as well as gdtoa (which is what we use for printf's floating
| point support)
| https://github.com/jart/cosmopolitan/tree/master/third_party...
| but we simply haven't found the time yet to incorporate this
| stuff into scanf() so contributions are very much welcome.
| [deleted]
| polyrand wrote:
| I wonder if blink could be used as a lightweight sandbox. Looking
| at PR46[0], it seems sandboxing is not one of the current
| features, but it would be cool to have a way to run arbitrary
| code (e.g: Python) in a sandboxed environment. Even cooler if you
| could limit the amount of memory/CPU used.
|
| [0]:
| https://github.com/jart/blink/pull/46#pullrequestreview-1264...
| jart wrote:
| Author of Blink here. I wrote another command called pledge.com
| which does sandboxing: https://justine.lol/pledge/ Let's say
| for example you want to be able to run the `ls` command under
| Blink in a way that (1) restricts which parts of the file
| system it's allowed to use and (2) prevents it from talking to
| the Internet. You could say: ~/blink$
| pledge.com -v/lib -v/bin/ls -v. -p 'stdio rpath tty prot_exec'
| o//blink/blink /bin/ls HTAGS LICENSE Makefile
| README.md TAGS blink build o test third_party tool
|
| You can now be certain that your `ls` command isn't spying on
| you or uploading your bitcoin wallet to the cloud. The blink
| command itself is currently unsecured. However that shouldn't
| matter, since we can compose blink with pledge.com to bolt on
| all the security we need separately!
| polyrand wrote:
| Awesome! I was just reading about pledge. I think I need to
| find some time to play around with it. Right now, there's a
| lot of interest in using WASM as a sandbox for untrusted
| code, but pledge looks easier to use and more versatile (you
| don't need any kind of WASM compatibility, just a binary to
| run).
| jart wrote:
| Offline WASM runtimes like Wasmtime are pretty cool,
| however I'd call SECCOMP BPF with Landlock LSM a shining
| beacon of light. The problem is that (1) coding BPF
| assembly has always been terrifying to the uninitiated and
| (2) Landlock LSM only came out in the past year. I believe
| pledge.com is the first tool that makes using both these
| Linux security tools together universally accessible for
| everyone. Be sure to run a bleeding edge Linux kernel if
| you use the `-v PATH` flag. If you're running an older
| kernel, then the pledge.com command will treat unveiling as
| a no-op in the interest of compatibility. I use Landlock
| LSM on my desktop, which runs Alpine Linux 5.15.74-0-lts. I
| also use Landlock in production on GCE, but I needed to
| `apt install linux-image-5.18.0-0.deb11.4-cloud-amd64` in
| order for it to work.
| hebash wrote:
| [dead]
| buildbot wrote:
| One of those projects that is just so neat it engenders a desire
| to go do something fun with it!
|
| Maybe you build proton and have any windows game (or software?)
| in the browser?
| kev_emu wrote:
| That already exists. boxedwine.org
| buildbot wrote:
| Oh cool, thanks for sharing!
| [deleted]
| dahfizz wrote:
| That would be cool. I've been looking for a way to have to re-
| download a game every time I play it. And native games just run
| at way too high an FPS...
| jenadine wrote:
| But this is not cross platform, right? It is specific to x11
| vidarh wrote:
| I don't think there are any remotely mainstream platforms there
| isn't an x11 server for.
| yjftsjthsd-h wrote:
| Worst case, there's always
|
| http://www.jcraft.com/weirdx/
| vidarh wrote:
| There's also xpra, which gets you a browser interface to X
| apps.
| jenadine wrote:
| Good point. Blink could even ship with a X11 server. (Or
| Wayland compositor? To be more modern)
| [deleted]
| danieldk wrote:
| XQuartz does not properly support HiDPI, so it's never going
| to be great on Macs anymore:
|
| https://github.com/XQuartz/XQuartz/issues/91
|
| Besides that, even Linux is slowly moving to Wayland.
| vidarh wrote:
| Moving to Wayland does not prevent X11 apps. And I don't
| think anyone would expect this to be a _good_ solution for
| crossplatform guis. More of a fun starting point.
| terhechte wrote:
| Well, there is a Wayland Compositor for macOS:
|
| https://github.com/owl-compositor/owl
|
| It still lacks a lot of features though (I think, I never
| tried it out)
| mati365 wrote:
| So we invented Java again?
| jart wrote:
| Author of Blink here. Yes. Absolutely. I've always wanted to
| have Java's tools (e.g. "build once run anywhere" simplistic
| development) except I want to program in C / C++ instead of
| Java. The main platform I target is x86_64 desktops and
| servers, on which I want to run natively (rather than Java,
| which would force my code to _always_ be virtualized) and Blink
| lets me pull out the virtual machine trick when I need it (e.g.
| someone wants to run the apps I 've released on an esoteric
| platform like MIPS OpenBSD). All the x86_64 Linux executables I
| spent the past several years writing and releasing are suddenly
| able to be enjoyed by users on platforms I'd never dreamed of,
| like Haiku, and I didn't have to do anything to "port" and re-
| release those binaries on my website in order to do that. We
| just had to build one tiny 180kb virtual machine (unlike the
| JVM which is more like 100mb and might bundle a browser toolbar
| in the installer) and I made it open source (ISC, unlike Qemu
| which is GPL) so that you can enjoy these benefits too.
| IcePic wrote:
| > Blink lets me pull out the virtual machine trick when I
| need it (e.g. someone wants to run the apps I've released on
| an esoteric platform like MIPS OpenBSD).
|
| Me and the other user of Mips on OpenBSD are both glad you
| do!
| jcul wrote:
| Reading this, I began to think about cosmopolitan libc, and
| the "actually portable executable".
|
| I haven't played around with it, but I remember being in awe
| of its ambition.
|
| I haven't been following cosmopolitan, nor blink closely, but
| I just looked up cosmopolitan and realized you are the author
| of both.
|
| Just want to say amazing work! Hope to get a chance to try
| out blink soon.
| dekhn wrote:
| Somebody should write fanfic where jart goes back in time and
| forestalls the Java revolution in ~roughly 1995 by releasing
| Blink. Instead of the entire several decades of Java (and
| Javascript), Blink becomes the technology underlying web (the
| browser is really just a portable presentation layer) server
| and client programming. Lightweight phones with long battery
| life and portable architectures revolutionize mobile
| computing 5 years earlier. World GDP is 35% higher, and life
| is generally happier, and much easier.
|
| (seriously though, thanks for doing all this. I like your
| philosophy compared to what the world ended up with as the
| dominant paradigm)
| actionfromafar wrote:
| I still find it surreal that these operating systems share so
| many mechanisms that these portable EXEs are even possible.
|
| Someone should write some kind of historical explanation of
| how this could have happened. And how critical is it for the
| "APE" scheme to work? Could APE binaries work on AROS x86_64
| for instance? (Without emulation.)
|
| I also find it surreal that it took this long for someone to
| do something like Actually Portable Executable. I mean, it's
| slick and easy to use, but I haven't even seem assembler
| demos of this.
|
| Is the same polyglot EXE possible also on 32-bit x86? If so,
| I find it even weirder this have not been done long ago,
| considering the strange hacks people have pulled over the
| years.
|
| I'm fascinated by the whole thing, as you can tell. Back in
| the day, Windows and Unix seemed so far from each other, like
| oil and water.
| jart wrote:
| In this blog post https://justine.lol/sizetricks/#elf I
| talk about how simple it is to create a single file binary
| from scratch that runs on Linux, FreeBSD, OpenBSD, and
| NetBSD. All Actually Portable Executable does is it takes
| that trick three steps further, to support Windows, MacOS,
| and BIOS from a single file binary too. That requires a bit
| more effort.
|
| These are simply the operating systems I knew best, because
| I grew up using them, and as a result was able to discover
| the right combination of tricks to get it to work. I'm sure
| someone else who loves AROS and knows AROS would also be
| able to discover a way to trick it out so that APE could
| support it too. Same goes for other platforms. For example,
| one of the things on my TODO list this year is to find out
| if the APE x86_64 hacks are replicable for the ARM64
| architecture.
|
| The closest thing to a scientific theory behind what APE is
| would be what the information security community calls a
| "polyglot". Researching that is another great way to learn
| more similarly inspired tricks.
|
| > Is the same polyglot EXE possible also on 32-bit x86? If
| so, I find it even weirder this have not been done long
| ago, considering the strange hacks people have pulled over
| the years.
|
| It's actually even easier to do for i386 than it is for
| x86_64. The blog post above explains why that's the case,
| due to the syscall magic numbers being more similar. Also
| I'm equally astonished no one did this before I came along.
| I think part of why that's the case, is that I couldn't
| _just_ write APE. Doing this project meant that I had to
| implement a C library from scratch too, which is a years
| long coding marathon.
| actionfromafar wrote:
| Thanks, great explanations. I think the most astonishing
| thing to me is that I never saw such a polyglot EXE even
| print "hello" on stdout, written in assembler.
| enriquto wrote:
| Nobody dared to eat the fruit of the unknown tree. What
| if it was poisonous? Until a brave soul tried it, and saw
| that it was good.
| vidarh wrote:
| I think for something like AROS the combination of
| support for ELF and such a small community would mean
| that if someone wanted to do this for AROS the easier
| path might well be to add support directly in the loader.
| pjmlp wrote:
| Which ironically were invented before Java was even an idea.
|
| https://en.wikipedia.org/wiki/EM_intermediate_language
|
| https://en.wikipedia.org/wiki/TenDRA_Compiler
| actionfromafar wrote:
| Theoretically, if Sun and Oracle would have cared for the
| experimental runtimes which compiled to native instead of JVM.
| I think GNU had one going, but RMS hated that too, so there was
| kind of a gap in the marketplace for such a thing. You can sort
| of do it with .NET now.
| simiones wrote:
| Edit: I completely misunderstood what Blink is in relation to
| WASM. I'm leaving my original comment below, but it is quite
| wrong.
|
| Still, Blink is a VM in the same sense as the JVM, and it
| does JIT compilation (or it can interpret program ASM) just
| as much as that. As far as I understand from the git page, it
| is using x86_64 assembly as the "bytecode" though, so the JIT
| step may be quite trivial if running on the same arch and/or
| OS.
|
| Old post:
|
| This isn't compiling to native either, not ahead of time
| anyway. It is compiling C or C++ to WASM, and then running
| that in a browser. The browser will JIT compile the WASM,
| just like the JVM would.
|
| The biggest difference is that everyone has a browser, while
| not everyone has a JVM pre-installed.
| actionfromafar wrote:
| Wait, where is WASM used here? I thought that was a
| possible future development?
| TJSomething wrote:
| This doesn't use WASM or a browser at all. This is an new,
| original x86-64 machine code interpreter with a JIT
| compiler that supports x86-64 and aarch64. This is an
| extension of Justine's APE project to use x86-64 ELF as the
| core of write-once-run-anywhere software.
| pjmlp wrote:
| They cared about the commercial third party ones, just not
| about the free beer ones.
| [deleted]
| peoplefromibiza wrote:
| no, we reinvented Smalltalk. It only took 45 years
|
| EDIT: to realize it
| actionfromafar wrote:
| We did, but not in this project. :-) This is indeed more like
| an embedded JVM, not totally unlike early J2ME, but with
| x86_64 instead of JVM instructions.
|
| Ruby is more like Smalltalk.
| peoplefromibiza wrote:
| not at all a critique on your project, if that was the
| impression I gave :)
|
| I'm old enough to remember when Java applets were invented,
| grew up using Visualage Smalltalk on OS/2 at school, and am
| still bitter that nobody ever said: but this is Smalltalk,
| why don't we use Smalltalk then? :)
| pjmlp wrote:
| Because Smalltalk big supporters like IBM, decided to
| repurpose their Smalltalk offerings into Java.
|
| Visual Age Smalltalk had a role similar to .NET on the
| OS/2 ecosystem, SOM (OS/2 version of COM) supported
| Smalltalk, implementation inheritance and meta-classes,
| so yeah it didn't help to go full on Java.
|
| Also another Visual Age thing, Visual Age for C++ v4 also
| had a Smalltalk like experience for C++, unfortunely it
| was too demanding in resources.
| thangalin wrote:
| Smalltalk was ahead of its time. So much so that its VM was
| unbearably slow. Thirsting for CPU power that just wasn't
| there. I recall using a Pentium-based machine and waiting up
| to five seconds to open a context menu, and the IDE
| (VisualWorks?) could not keep pace with my typing. I could
| type in a message name and watch the letters appear one-at-a-
| time. Compared with Borland's TurboPascal and similar IDEs of
| the day, Smalltalk was a slog, albeit a powerful one.
|
| There are other issues with Smalltalk that we know now that
| we didn't then. Such as broad and deep class hierarchies are
| hard to use. Smalltalk didn't enforce type-safety when I used
| it (i.e., you can have runtime faults because you can send
| any message to any class and if you didn't implement "does
| not understand", you won't know until exercising that
| branch).
| chrismorgan wrote:
| Note that this is not Blink the rendering engine that powers
| Chromium and related browsers, but https://github.com/jart/blink,
| "a virtual machine that runs x86-64-linux programs on different
| operating systems and hardware architectures".
|
| Where this talks of running GUI programs, I presume it means that
| the VM can act as an X client. You would thus still need an X
| server. I don't know what may exist along those lines for the
| web. As for native/desktop hosts, well, I hope you weren't ever
| trying to use emulation as any form of _security_ , because the
| likes of Xorg _really_ aren't designed for that use case.
| eptcyka wrote:
| It runs the X server in the VM.
| Vogtinator wrote:
| Not in this demo. It probably could though.
| csdvrx wrote:
| There's a X with sixel support:
| https://github.com/saitoha/xserver-sixel
|
| I played with this before, and I could use X11 within a
| mlterm terminal.
|
| I should try to recompile it with cosmopolitan to have a
| single X server binary both for Windows and Linux
| trenchgun wrote:
| That's amazing!
| csdvrx wrote:
| And this is why I'm so interested in Sixel support for
| the Windows Terminal
| (https://github.com/microsoft/Terminal/issues/448)
|
| With that and a X server using sixels, there would no
| longer be a need for something as complex as wslg for
| most apps: you could just export DISPLAY in your .bashrc,
| then use one Windows Terminal tab to start X apps, and
| the other one to display/interact with them.
| chrismorgan wrote:
| If the X server were running in the VM, how would it
| _display_ things, or get keyboard and mouse input? You'd need
| to provide emulated hardware devices, which could be
| something like /dev/fb0 for output and /dev/input/ devices
| for keyboard and mouse. All that is a _very_ much larger
| undertaking, and probably a good deal less useful in general.
| The likes of X are a much more suitable abstraction.
|
| The change here is implementing sendmsg and recvmsg: socket
| communications, implying communicating with something outside
| the VM, which in the context of GUI stuff almost certainly
| means an X server from outside.
| destructionator wrote:
| > the likes of Xorg really aren't designed for that use case.
|
| Bullshit. Would be nice if people were to stop spreading these
| outright lies.
| chrismorgan wrote:
| I'm curious how you think it an outright lie. I'm speaking of
| the consequences of Xorg's basic lack of isolation (because
| it _wasn't_ designed for use cases where that matters): that
| granting access to the X socket allows you to inspect,
| intercept and modify inputs and outputs for things like key
| strokes, window contents (yours or others') and clipboards.
| destructionator wrote:
| > I'm speaking of the consequences of Xorg's basic lack of
| isolation (because it wasn't designed for use cases where
| that matters): that granting access to the X socket allows
| you to inspect, intercept and modify inputs and outputs for
| things like key strokes, window contents (yours or others')
| and clipboards.
|
| This is not true! Both the protocol and the implementation
| allow for significant separation of server permissions (for
| example, notice the difference between ssh -X and ssh -Y),
| and the peer-to-peer nature of things like clipboard means
| it is quite easy to deny requests on an application level
| if they're written for it.
| anthk wrote:
| XTerm has basic keyboard locking support.
| [deleted]
| rom-antics wrote:
| Straight from the horse's mouth:
|
| https://www.x.org/wiki/Development/X12/
|
| > In short, X11 was designed for a different era of
| computing.
|
| > This is not to say that there's an X12 project. There
| isn't. But if one day there is...
|
| > Systems need to be secure. X12 needs to be designed with
| security in mind.
|
| Do you think the Xorg devs are spreading lies about Xorg?
| destructionator wrote:
| > Do you think the Xorg devs are spreading lies about Xorg?
|
| Some are, yes, this is incontrovertibly true. But this one?
| You should hit the "history" button that's in the corner of
| every wiki. That page hasn't been edited at all since 2013,
| imported from some other document written I don't know
| when, and literally the only thing it actually says about
| security is that "needs to be designed with security in
| mind".
|
| What does that mean? What specific shortcomings have they
| identified?
| vengefulduck wrote:
| The fact that any Xorg client can become a key logger
| without any user input or authentication is a pretty big
| security hole imo.
|
| By design Xorg has no isolation between clients so they
| can all read each others input, control others windows,
| and inject keystrokes into other applications. That's
| unacceptable in the modern age and makes any attempt at
| sandboxing or separation of privileges for GUI
| applications completely pointless.
| destructionator wrote:
| > The fact that any Xorg client can become a key logger
| without any user input or authentication is a pretty big
| security hole imo.
|
| This "hole" doesn't exist. For an X client to capture
| input, it must be authenticated by either the unix user
| permission or by an access control list (where the
| default is to deny). Individual clients can also be
| marked untrusted which sandboxes them to some extent
| (though not as much as using a separate X server of
| course).
|
| I'll grant that in practice, most the time these
| restrictions are very lax... in part because they can
| break some applications. But at the same time, in
| practice, it doesn't seem to matter that much since
| either you're running things you trust anyway or if a
| malicious application has access to your X connection
| they also have access to all your other files so you're
| in trouble anyway.
| csdvrx wrote:
| Simple solution: isolate, by running 1 X server per
| client (or set of clients if you want gimp and krita in
| the same sandbox)
| thewataccount wrote:
| Is there any tutorials/examples of how to do this?
| seabrookmx wrote:
| Apologies for not answering your question directly, but
| I'm pretty sure this is what XWayland does to allow for
| compatibility of X apps ontop of wayland.
| nisegami wrote:
| I imagine it's mostly the issue related to applications
| having too much access to thinks like the keyboard and
| other windows without a permission system? That's a large
| part of what makes Wayland different from X11.
| [deleted]
| [deleted]
| [deleted]
| dahfizz wrote:
| If this is what it takes to get developers to care about native
| code again, I'm all for it.
| snek_case wrote:
| Could make a nice alternative to something like Electron...
___________________________________________________________________
(page generated 2023-02-03 23:00 UTC)