Hacker Newsnew | past | comments | ask | show | jobs | submit | maxloh's commentslogin

From the "Technical notes" page:

> Access to Internet is possible inside the emulator. It uses the websocket VPN offered by Benjamin Burns (see his blog). The bandwidth is capped to 40 kB/s and at most two connections are allowed per public IP address. Please don't abuse the service.

https://bellard.org/jslinux/tech.html


My college professor used it to teach us the Linux command line

We have Windows PCs in the classroom.


Similarly I've used it for technical interviews.

Unfortunately, he didn't attach the source code for the 64-bit x86 emulation layer, or the config used to compile the hosted image.

For a more open-source version, check out container2wasm (which supports x86_64, riscv64, and AArch64 architectures): https://github.com/container2wasm/container2wasm


https://github.com/copy/v86 might be a more 1:1 fully open sourced alternative.

Not really. x86_64 is not supported yet: https://github.com/copy/v86/issues/133

Sure, and there are probably some other things lacking, but JSLinux supports a lot more than CLI Linux userspace on x86-64 too. E.g. compare to lack of graphical interface https://github.com/container2wasm/container2wasm/issues/196

It looks like container2wasm uses a forked version of Bochs to get the x86-64 kernel emulation to work. If one pulled that out separately and patched it a bit more to have the remaining feature support it'd probably be the closest overall. Of course one could say the same about patching anything with enough enthusiasm :).


Looks really like Prisma to me: https://www.prisma.io/docs/orm/prisma-schema/overview#exampl...

Why build another language instead of extending an existing one?


I looked at Prisma, I very much prefer the Protobuf/Thrift model of using numbers to identify fields, which allows 2 important things: fields to be renamed without breaking backward compatibility, and a compact wire format.

I think the Protobuf language (which Skir is heavily influenced by) has some flaws in its core design, e.g. the enum/oneof mess, the fact that it allows spare field numbers which makes the "dense JSON" format (core feature of Skir) harder to get, the fact that it does not allow users to optionally specify a stable identifier to a message to get compatibility checks to work.

I get your point about "why building another language", but also that point taken too far means that we would all be programming in Haskell.


JavaScript and Kotlin do that too.

For context, they have 2 to 4 commits per month since October [1]. The last release was July 2025 [2].

[1]: https://github.com/pypy/pypy/commits/main/

[2]: https://github.com/pypy/pypy/tags


That seems reasonably active to me. You can't really expect more from an open source project without paid full-time developers.

> And pressed on if he is insisting there needs to be a democratic state, Trump told CNN, “No, I’m saying there has to be a leader that’s going be fair and just. Do a great job. Treat the United States and Israel well, and treat the other countries in the Middle East — they’re all our partners.”


Since most ISPs also maintain their own DNS resolver, they could always reverse lookup the IP address AFAIK.

The whole idea behind ECH is one IP hosts tons of sites (eg. CDN) so you have no idea which one it is.

Also reverse lookup has nothing to do with hosting own DNS resolver.


What you're describing is a SNI, not ECH. Those two serve very different purposes.

> Also reverse lookup has nothing to do with hosting own DNS resolver.

It has everything to do with that. Had you used two brain cells, you would've known that they can memorize the IP address and the domain name, and if you connect to that IP in a short period of time, most likely you visited that domain name.


SNI is unencrypted, so your ISP can see it. ECH encrypts it.

How does this relate to my comment?

True. ECH is useless if you're using plain DNS. DNS over TLS or HTTPS is the way to go.

Why didn't the Indian government block traffics based on IP instead? That would make it much harder to bypass.

If i'm not mistaken its because IPs are actually much easier to rotate than domains.

E.g. all the users will remember `example.com` , underlying it doesn't matter what IP it resolves to. If the IP gets "burned" , then the providers can rotate to a new IP (if their provider allows).

Vs. telling your users to use a new domain `example.org` , fake websites etc.

Also sensible ISPs usually don't block IPs since for services behind a CDN it could lead to other websites being blocked, though of course sometimes this is ignored. See also: https://blog.cloudflare.com/consequences-of-ip-blocking/


I wouldn't say you're mistaken, but it's a simplification. In the network world, the capability exists to restrict what BGP advertisements are accepted via RPKI/a peer. Internet providers usually don't because the premium is placed on uptime/connectivity.

If tomorrow, everyone said "we don't want IP's from Frankfurt showing up somewhere in Dubai", you'd have a massive technical problem and rearranging to start with but once that was sorted you could geo-lock. IANA and Network providers simply haven't been doing that.

The reason it doesn't happen is Devs/Stakeholders want uptime from ISPs/Networks and not something they can't abstract. Basically its just a status quo much like the entire internet reverse-proxying through CDNs is a status quo. It wasn't always like that, and it may not always be like that in the future - just depends which way the winds blow over time.


> we don't want IP's from Frankfurt showing up somewhere in Dubai

what do you mean, IPs from Frankfurt?

IP addresses are just IP addresses, they know no geographical boundaries. In RIR DBs you can geolocate them to wherever you want. Which is the entire reason why Geo IP DBs even exist - they triangulate.


> "we don't want IP's from Frankfurt showing up somewhere in Dubai"

From a network perspective statements like that make no sense. IP addresses don't have any sort of physicality,


They have registration data. Someone could declare they don't want IPs registered to companies from Frankfurt with geofeeds in Frankfurt to be advertised in Dubai.

It’s not how any of it works.

How do you determine to whom an IP is even registered to? They get sub-leased all the time.

The best you can do is check who has administrative control over the prefixes RIR info, but that doesn’t mean that anyone with control is the factual user of the IPs.

You could check the IRR for the ASN and base it on that, but still.

There's also no way to actually know _where_ an IP actually originates from. Only its AS path.

The DFZ contains all prefixes announced everywhere, for the internet is completely decentralized.


> How do you determine to whom an IP is even registered to?

You check the RIR's records.

> They get sub-leased all the time.

With records updated. If not, any consequences from wrong information fall on the lessor and lessee.

> There's also no way to actually know _where_ an IP actually originates from. Only its AS path.

Ping time from different locations on their upstream AS gives a good guess.


> With records updated. If not, any consequences from wrong information fall on the lessor and lessee.

Not always + there are no consequences whatsoever.

Plenty of leasing services will just provide you with IRR & RPKI, without ever touching the actual records.

> Ping time from different locations on their upstream AS gives a good guess.

Upstream AS is meaningless if it's a T1 carrier. Ping AS6939. They are everywhere.


Ping a specific address of AS6939 and find out where it is.

https://bgp.tools/as/6939#prefixes

They are everywhere. It's a global carrier. Carriers also know no geographic boundaries.


That's why you have a strictly legal domain that enables a convoluted redirect with plausible deniability (not 302)

It'll still eventually stick, but a lot slower


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: