Show HN: 3 years and 1M users later, I just open-sourced my "Internet OS"

There is a permission system I think. It's described in the developer docs:

> […] your app will get a few things by default: […] An app directory in the user's cloud storage […] A key-value store in the user's space […]

> > Apps are sandboxed by default! Apps are not able to access any […]

https://docs.puter.com/security/

I guess that refers to the cloud storage/backend. Clientside apps seem to run as IFrames, so should be subjected to normal browser sandboxing (…and actually, I guess, multiprocessing too), with only explicit message-passing.

Honestly I think the developer API could have been better highlighted by this HN post. Puter's actually doing a bit more than the Desktop Environment mockup that's visually apparent, and not featuring that seems like a wasted opportunity to pick up some app developers.

Honestly blown away by this. Graphics, audio, everything just works (tm).

I've seen many 'desktop in browser' type demos over the years, but never anything like this. This is impressive on so many levels.

On a technical level it's actually not that impressive. Mozilla got BananaBread/Sauerbraten running with WebGL on netbooks over a decade ago, with much more advanced graphics than Xash3D:

https://kripken.github.io/misc-js-benchmarks/banana/index.ht...

https://wiki.mozilla.org/HTML5_Games/BananaBread

The Half Life "app" above actually just wraps an existing Emscripten port in an IFrame. Puter does provide an abstracted filesystem (and other "OS" features), but I don't think the app above uses that, so it's no different than if you went to `data:text/html,IntralexicalOS!<br><iframe src="https://pixelsuft.github.io/hl/" style="width:50%;height:50%">`.

But actually I think putting together such a simple technical concept that works this well is the impressive part, that hasn't been done before. You can now take any existing web build of any app, and by adding a couple calls to `puter.fs.write()`, deploy it to a familiar virtual workspace where you get multitasking, cloud storage, and interoperation with other apps, for free.

The circle is finally complete! Now of course you want to use a browser within puter as well: Browser in browser OS in OS in virtual machine...

It's mind boggling how far one can torture the concept of markup documents to eventually arrive at something like this... just so users don't have to install software.

Millions of people have been killed so that other people wouldn't have to wear itchy clothes.

Convenience is the most powerful force in humanity.

Itchy is maybe exaggerating, but as far as I know, lower class clothes were very coarse compared to modern ones.

A lot of natural fibers need a lot of strength to be spun into finer threads and we didn't really have that on a large scale until the 1800s.

Plus distribution was much harder so in many remote parts were stuck with whatever they made locally, which was most likely subpar even for their times.

Cotton tech in the 1800s really revolutionized clothing.

Given what the web is, it makes me exceedingly sad we don't see the page as a browser of many sites more often. That a page mostly just dials home, to its own server, is radically less than what web architecture could be, is a mere readopting of the past.

Efforts like Tim Berners-Lee's Solid seem like a great first step. There's also a variety of Mastodon clients one can run as PWAs, which both is an example but also a bit of a counter-examples: the page can dial anywhere! But then that Fediverse server intermediates & connects you out to the world. RSS readers too; dialing home to connect with the world. Instead we could perhaps have a client that reaches out directly. Then that activity of reading & browsing, keeping track of favorites and what not: that would have to be sent home or otherwise saved.

To me, Puter platform has a huge potential. And as a developer, I already have large value from it.

Using puter.js I was able to add full cloud storage for my design editor https://studio.polotno.com/ without messing up with auth, backend and databases.

I agree, this opens up really interesting possibilities.

Here's my understanding of how it works, based on the puter.js docs [1]:

If I'm developing a frontend app that could benefit from cloud storage, I can load in puter.js as my "backend". I don't need to worry about user auth because puter.js will automatically ask the user to create an account or log in. I also don't need to worry about managing & paying for cloud storage because puter.js will take care of that on a user-by-user basis - including asking the user for payment if they go over their free limits.

I haven't actually used puter.js yet. But if I understand correctly, this could be a really powerful model. As the developer of a niche app whose purpose is not to bring in revenue, puter.js seems like a very reasonable way to pass on cloud storage costs to end users, while also reducing development effort!

[1] https://docs.puter.com/

As lavrton said in a sibling comment - simpler integration.

I can't speak to Dropbox integration, but every time I've looked at integrating with Google Drive I have felt my development effort growing, not shrinking.

Puter also seems to place a high value on privacy, which I like.

Polotno Studio is a free app. And for a long time, it didn't even have the ability to signup and save created designs into a cloud.

I didn't want to invest my resources into "cloud saving" feature (as it is a free app). Setup full authorization, setup database, setup servers and tons of other work to finish the cycle.

https://docs.puter.com/ gives a very simple, yet powerful client-side js SDK to enable full cloud saving and loading of data for my users. I spent a couple of days for integration. Doing everything by myself with full hosting would take weeks, if not months.

Sounds good, but it seems the sign-in feature pops open a new window to the puter.com domain. Does the SDK provide any means of avoiding this and keeping everything integrated on your app without pop-up windows?

Also I'm confused about how you pay puter for the service. What if a million people suddenly use your app, and sign-up? As the app owner, do you have access to the users who signed up? Can you export those members in case you wanted to import them somewhere else if you moved your app?

I am not in puter team, so I may not know some details.

But.

I don't really care how sign-in is implemented. If it is a popup, but simple for the user - that is ok for me. Probably they will change how it works in the feature because they Puter team was listening for my feedback with puter.js SDK.

Right now, I don't pay Puter. As I understand their long-term plan, eventually, they will monetize the users directly, for example, users will pay for bigger cloud storage.

For now, I don't have access to users. But I already spoke with Puter team about, and they told me they will have a full user management dashboard.

Thanks for that information, very useful.

Puter should provide more details, it seems lacking on their side given it's been around for a bit.

I'm someone who, like you, doesn't want to mess around with user management and authenticating, but I probably should grow a pair and learn how to do it properly using Amazon services or something.

I like this thinking.

If someone could combine Supabase + Postgrest or Hasura with an easy visual admin dashboard for them inside this, this could be a complete easy to access, easy to deploy platform.

This is insanely cool! Looks really slick too, even in a mobile screen.

jQuery?? I cannot imagine how difficult it is to not break this when you make the slightest change, hats off for managing with vanilla Javascript and jQuery! The best thing about React for me is to not have to worry about breaking the DOM or messing up with event handlers because some jQuery line, somewhere obscure is probably doing something funky that is really difficult to track down!

Convention over Configuration.

That and types. The only framework that's useful to JS is a better static type check system (and none of this lets-make-the-whole-damn-runtime-slow to support X feature, looking at you TypeScript).

We use a lot of typescript with a very opinionated setup on coding style and conventions, but that only goes so far when you’re dealing directly with the dom.

Because the dom is notoriously hard to work with. The internet is full of blog posts and articles talking about how slow it is as an example, but in reality adding or removing a dom node is swapping a pointers which is extremely fast. What is slow is things like “layout”. When Javascript changes something and hands control back to the browser it invokes its CSS recalc, layout, repaint and finally recomposition algorithms to redraw the screen. The layout algorithm is quite complex and it's synchronous, which makes it stupidly easy to make thing slow.

This is why the virtual dom of react “won”. Not because you can’t fuck up with it, but because it’s much harder to do so.

> When Javascript changes something and hands control back to the browser it invokes its CSS recalc, layout, repaint and finally recomposition algorithms to redraw the screen. The layout algorithm is quite complex and it's synchronous, which makes it stupidly easy to make thing slow.

Wait, you're saying it's synchronous but what exactly is being blocked here (since you also said the JS hands back control to the browser first)?

I’m not quite sure what it is that you’re asking. When you want to show something in a browser, you go through this process: JavaScript -> style -> layout -> paint -> composite.

The browser will construct a render tree and then calculate the layout position of each element/node in a process where it’s extremely easy to run into performance issues. And since the rest of the render pipeline waits for this to conclude, it’ll lead to very poor performance. You can look into layout trashing if you’re curious.

My point is more along the lines of how you can ask a lot of frontend engineers what the render pipeline is and how it works and many won’t be able to answer. Which isn’t a huge issue, because almost everyone who does complicated frontends either use a virtual dom or exclusive hire people who do know. But for the most part, you won’t be fine with just JavaScript for massive UI projects as the person I was replying to suggested.

> and none of this lets-make-the-whole-damn-runtime-slow to support X feature, looking at you TypeScript

TypeScript runtime? I don't think the deprecated code that sets up enum objects affects anything else...

Not enums. But you don't need a runtime or function mutation for that...

Particularly egregious was (is?) async/await. Upgrade your browser/runtime/don't use it you say? Sure, but first two weren't always possible, and the third isn't possible unless you thoroughly vet your dependencies (easier said than done).

"Compiling to javascript" is all well and good if you actually just compile to normal javascript, as soon as you have any code that simulates other features (classes/objects/what-have-you) you are no longer "compiling to javascript". I mean yeah sure as a sort of intermediary assembly language you are but the performance is not the same. You have a new language with a runtime overhead, that now requires you modify the "core" language to bring in new features, which results in the underlying execution engines (browsers/cpus) becoming more complicated, power hungry, etc....

Anyways, type caching is not all bad. While the TS overhead is likely responsible for the performance wins for javascript in the following chart: https://programming-language-benchmarks.vercel.app/typescrip...

The performance wins for typescript likely source from the ability of the runtime to pre-allocate and avoid type checking.

Providing the type checks without using any non-JS features (and possibly providing the runtime some heads up regarding checks to safely drop) is the ideal.

You can disable those fallback implementations if you don't want to use them. Just use the javascript version you have available as the basis for your typescript. The option to look into the future shouldn't be treated as a negative.

And I still don't see how they make "the whole damn runtime" slow. You don't pay the cost for code that isn't using it.

Also I'm pretty sure the class implementation doesn't slow things down. It's a very simple transformation.

> You have a new language with a runtime overhead, that now requires you modify the "core" language to bring in new features, which results in the underlying execution engines (browsers/cpus) becoming more complicated, power hungry, etc....

I think you have this backwards. Typescript doesn't implement new Javascript features until their addition to Javascript itself is imminent.

The only feature Typescript wants to push onto Javascript is a syntax for type annotations, because then you can remove the compilation step entirely. At which point there couldn't even be a runtime overhead.

> non-JS features

To first approximation, there aren't any. The main one is the old enum syntax, which is why I brought them up.

> Typescript doesn't implement new Javascript features until their addition to Javascript itself is imminent.

I guess we want different things from Type systems.

I want rock solid guarantees that code is correct, so that the only thing left to test as much as possible is the business logic. I don't care about the latest programming fads, and I want stable, performant code.

You seem to just want some boilerplate guarantees and backwards compatibility.

If I were writing/creating TypeScript, I would be not implementing new features before JS upgrades, but long after (possibly as support libraries). I understand the goal of "easing" the transition, but IMO those sorts of "upgrades" should be late, not early, in a tool whose primary goal is static type checking, not JS features.

The things you seem to be worried about are configurable in the tsconfig. You can stay as polyfill free as you would like by instructing the Typescript compiler to error out instead of making the glue for you. Aside from the inescapable quirks of runtime JavaScript, Typescript felt pretty intuitive to me when transitioning to a new job from C# previously. Typescript with ESLint is about as solid as you’re going to get with JavaScript. I know that ideally there’d be something better, but in the real world right now this is the best it gets. At some point reality and business constraints are going to slam into ideations and things are going to get a bit dirty.

Aside from that, no matter what you pick, standard Typescript configs are absolutely compiling to JavaScript, not any other step in the interpreting process. It doesn’t matter if it’s taking your async/await and polyfilling it to run on an older browser engine… it’s still producing 100% JavaScript.

It goes Typescript -> JavaScript during the build, and the JS is what gets distributed to clients.

The JavaScript produced by TS is sent to the browser which performs the same JavaScript -> abstract syntax tree -> byte code -> execution, as usual

"standard Typescript configs are absolutely compiling to JavaScript"

You are missing the point. I want zero cost abstractions (for some level of abstraction - I accept e.g. there is a CPU and a browser). I don't care what it is compiling to.

Typescript is not a zero cost abstraction. (Zero cost meaning, here, that any overhead is incurred compile time only).

"The things you seem to be worried about are configurable in the tsconfig"

That's terrible. I want the Z.C.A. to be by-default, not "configure the heck out of the language to make it so".

> That's terrible. I want the Z.C.A. to be by-default, not "configure the heck out of the language to make it so".

Don't you just set target? Is there even a default for target?

I think it would likely be more technically involved and complicated if it were made with `canvas`.

But large blobs drawing to `canvas` aren't anything new at this point. The part that impressed me is doing it the simple way, using what the browser already provides, and getting it to work this well.

I dunno, once you write the renderer, you essentially have no limits to worry about.

Working within the confines of HTML is way more impressive to me.

I got carried away for ages with this. I was installing extensions in VSCode and got confused when it wouldn't open a link to a repo in a little browserception, because by that point I was fully expecting it to.

Really nicely done.

Are you aware of Theia IDE?

I've been using this as a way of quickly putting a UI over an EC2 instance.

Could you advise on how you'd do the equivalent here? Eg., say I want to provide an EC2 machine with various packages installed (python, node,...) -- or, the equivalent docker image -- is there a way of using your UI to provide access to this?

Consider, eg., using an iPad with your UI in a browser. Could you advise a way that this could provide a complete development experience for datasci/seng? (As above, i'm using theia to do this in a quick-and-disposable way).

Love it!

It would be nice if `~` was mapped to home directory (e.g. `cd ~/Desktop`)

Hard to resize windows. If I want to grab the right edge there is only 1 pixel to work with.

When printing with `cat` from terminal, it would be nice if there was a new line at the end of the text. The prompt shows up on the same line as cat's output.

Copy-paste from clipboard into puter instance.

How do I get python on here?

We have a separate repo where you can submit issues related to the shell: https://github.com/HeyPuter/phoenix/issues

If a file doesn't have a newline at the end then `cat` will immediately start writing the prompt after the last line; this is the same behavior you'd expect from sh or bash. We might later improve this by having a "no newline"-indicator in the promptline instead.

Definitely a `window.onbeforeunload = () => "Are you sure you want to close this browser tab"` missing, or override the keyboard input completely, so it doesn't try to close the tab.

Same problem exists for all browser shortcuts inside the OS.

> window.onbeforeunload = () => "Are you sure you want to close this browser tab"

besides the fact that now all browsers just display the uninformative "Your unsaved data may be lost" rather than any custom message, this would be a perfect addition.

About 30 years ago when I was a programmer and support guy all in one, I had an MS-DOS boot disk and a 300 Megabyte Backpack portable hard drive. It was awesome. I had all of the source code, backups of the customer sites data and my programming environment with me no matter where I went.

Great stuff!

These two posts have awoken old memories for me, because I used BartPE and I had a "magic" bootable MSDOS diskette.

I remember I also created a custom Windows NT build for a company I worked for around 1999. They had about 6 different models of Compaq workstation, and a dozen different departments. They had a disk imaging solution, rather than implement automated pxe builds. That's fine, except that nobody in the team had any "craft". Because NT isn't plug and play and each department had different software, we had about 20+ NT images, each with its own personality (ie major flaws, like hard-coded WINS servers, being already joined to a domain, old user profiles, broken software installations, old drivers). The day I joined the team, the phone rang constantly from 8am to closing time. If you walked around the building to do a desk visit, 20 people would shout at you, "hey IT guy, take a look at this PC, will you?". Coming from a hardware support background I had installed MS stuff thousands of times and got my MCSE, but Lotus Notes, Sunguard, Bloomberg and their awful VB6 apps (unpackaged collecting of dlls and instructions) had a short learning curve. After I figured that stuff out I created a single NT build with everything working perfectly. I cleaned up, defragged, ran sysprep. It used NT's hardware profiles to make the build work on any model of desktop (which just required imaging a new model, creating a profile for it and installing all the drivers. Rinse and repeat 6 times). Then I burned the highly compressed NT image along with ghost.exe onto a CD, and handed copies to the other 2 helpdesk guys. Anyone who called IT over the few weeks, regardless of their issue, got a rebuild. Result? Immediate reduction in workload. So we proactively worked through the whole company. Things were so tranquil afterwards, we could go around to department heads asking if there was any "real" IT work that needed to be done.

That one disk, man.

GRML is a successor of sorts to Knoppix: https://grml.org/

It's an Austrian LiveCD based on Debian; version 2024.02 was just released. It's not as slick as Knoppix, but it does come with lots of utilities and can start an X Windows desktop.

BartPE was my god as a computer repair tech. I had a custom build with everything I ever needed on there!

Data recovery... virus removal... diagnostic tools... the works.

What I'd really love is a net boot image and remote storage that can be mounted on the fly on any computer. All I'd need is my yubikey or whatever secure identifier to connect all the pieces.l and plenty of internet.

I'm partially there with VDI tools like Parsec, but being able to leverage local hardware would also be neat.

It depends on what a standard Linux environment is and what you will need it for. I mean Android is some kind of Linux and with Termux you can get it a bit more Debian-like from a terminal perspective. But I haven't seen anybody start a KDE or Gnome with it.

My biggest issue with Dex is that it can manage only one large display. So if you have two, they are just being cloned. Otherwise, I like to use it sometimes when I don't want to start my PC.

The docs say a this can be used for remote access to servers and workstations.

How does it handle things like privilege escalation and sandboxing?

I'm assuming you mean remote access for a user account like a terminal server as opposed to server management.

Is that the case?

This is really cool--I've played with a lot of these online desktops, but this is by far the slickest.

As someone who is doing something similar (https://gridwhale.com), I'd love to know what your goals were. Did you ever try to commercialize it? If not, why not? If yes, what happened?

Never played Crossy Roads so I don't know the full extent of what gameplay features there are, but from looking at screenshots, looks like the gameplay code could be done relatively quickly (like some days at max), so doesn't seem out of the question that it's a full re-implementation.

Crossy Roads looks like another clone of Frogger, and clones of that game have been done since the 80s.

Can confirm. I just started down the long, arduous journey of building a complex browser extension.

For the first time in like a decade, I added and am using jQuery.

Honestly, I only thought to do after reading about the upcoming version 4.

I don't mean in a browser on a VR headset, I mean on a texture on a game asset in a Unity scene in a Webxr space in a browser on a headset.

This way you have the experience of sitting in front of your computer while wearing a VR headset anywhere in the world.

One of the things I find curious here is that there's no mobile story to speak of. Drag the window narrow, and all that happens is that the taskbar icons look squished.

Is there a mobile mode coming?

This would be dope af if I could get a mobile-esque UI on mobile-like devices, or opt into one on tablet-like devices.

In all honesty, this is perfect for people like me (who are rarely away from a keyboard) but less than ideal for people who live a more 21st century computing lifestyle.

If this thing had a mobile mode it would be revolutionary.

As it stands, it's still definitely revolution-friendly :)

great!

Be careful. If they're paying attention (and you just buried the needle on HN, so assume they are,) you're about to make some very powerful people very nervous. There will be offers, I predict. Not all of them wholesome.

I was a little surprised to see that it doesn't have the few extra tweaks necessary to work as a PWA in fullscreen mode: a manifest, some tags in the <head>, and CSS to lock down the body to prevent unwanted pinch zooming, scrolling and other gestures (which would also benefit the in-browser use case as well).

But still, really incredible work.

Charming.

What I mean is:

- there are strong, empirically tested usability reasons why a desktop-style UI is the pits on a mobile device

- generally, the move to mobile devices inclines to a different UI paradigm -- something finger-friendly and un-windowed (think iOS, Android, etc.)

- if there was a way that Puter could look kind of like a phone with some of the de-facto standard UI motifs and paradigms when it's on a phone, you could do cool shit like replace the Android shell with Puter, and have a pure web UI for your phone that runs web apps

- next step would be to add e.g. the ability to run Puter apps when offline, when reception is going in and out, etc. Sort of like Google Apps used to be (in Chrome)

- now you've got a cross-platform one-UI-to-rule-them-all breakout industry moment.

As it stands, Puter is already really cool, but if it turned into something that behaved a bit less like MacOS and a bit more like iOS at narrow resolutions, you'd have something that would make a lot of people very upset (and this is a good thing, they deserve to be upset)

Yes, it works, but it looks the same.

Remember Windows CE? We've been down this road -- a windowing desktop on a phone is... hard to use, actually.

This is one of the cool elements of the Synology operating system. Would be neat to see this extended further into other areas, using this as a base.

I setup a TrueNAS box for my dad recently and he was yearning for some kind of very light desktop environment for simple maintenance tasks. In hindsight I should have gotten him a Synology device.

We also do a desktop in a browser, but some core differences are you can launch real browsers in our environment and essentially load any web-based app you want collaboratively. It also does screen sharing and has A/V for meetings (we are not open source though, and have a paid product):

https://www.switchboard.app/

Knowing how difficult it is to build something like this, Puter definitely deserves praise.

I believe the original reason was the founder wanted a way to have his guitar teacher share tabs and give A/V feedback on his guitar playing. It was originally a product for teaching with limited sharing features, then the founder realized it could be used for many other use-cases and expanded to be much more collaborative and became essentially a multi-room collaborative virtual desktop-like experience.

We use it daily for things like standups, sprint planning, all hands, operations dashboards, product roadmap discussions, dungeons and dragons sessions, watching videos together and more.

I think this is brilliant, amazing work, opened on mobile Firefox with ublock advanced enabled; everything works first party. Most modern text based websites can't do that!

That being said I thought initially this would compete with ChromeOS, of the ill-fated Firefox OS; however, all other comments and FAQ are on about other things.

So brilliant, but I don't get it.

I tried running it locally and connecting to it with Firefox but it just gives me a log in dialog and trying to create an account fails. With Vivaldi creating an account works.

But where is this account created? Ah,just got an email that includes a link to puter.com so this created an account on a remote server. So it's not quite as local as advertised.

Two places where the project is very impressive:

1. Emulating a desktop with windows so smoothly on both desktop and mobile. This webapp is much snappier than most webapps these days.

2. A storage and file explorer with a friendly API for third party apps. Now any app can use a cloud storage synced across devices where the storage costs are paid by the user.

Can't wait until more apps are available! I see some limitations like VS Code unable to open git repositories which seems a limitation of the storage API (append-only, cannot seek or download partially)? Hope it gets closer to native experience in the future

Hi, I maintain that backend (which we call a "kernel"). For now, yes this is correct. Our goal is to open-source a kernel as well. We have a couple hurdles: we need to ensure the code architecture makes productive contributions possible, and we need to make it possible to run without complex cloud infrastructure setup so that it's relatively accessible.

Seeing the reception of the newly-open-sourced desktop environment, releasing the open-source kernel is going to be a major priority. I'm personally very excited about that, and I'm happy to see that's how other people want to use Puter too.

So, the cloud storage isn't a decentralized system where all users contribute disk space; rather you are providing the cloud storage in boxes you control? It seems like you must have some storage limits to prevent abuse, yes? Could you say what they are?

Also, I ran your hosting example and ended up with a static site at https://quiet-morning-9156.puter.site/. How long will that site be there? I assume not forever?

> isn't a decentralized system

That's right, logically centralized and physically distributed (on our cloud infrastructure). The open-source kernel will likely include a filesystem driver for local disk instead of cloud storage (which is more convenient for self-hosting) with the option to also use cloud storage provided by puter.com.

Storage limits for puter.com start at 500MB for new users, with the ability to gain 1GB of storage by referring users (you and the user referred each get +1GB).

Static sites will be available until you decide to remove them.

In case you wonder about the purpose of the project like I did, here's the explanation in README:

> It can be used to build remote desktop environments or serve as an interface for cloud storage services, remote servers, web hosting platforms, and more.

Looks awesome. I'm thinking about building a niche CMS soon, could this be an interface to it? Mentions cloud applications.

Seems like it might confuse normal folks though—a desktop in a browser. What do y'all think?

Super slick!

What are some common applications for this, though? I can't think of a reason I'd want to access this versus, say, a remote vm?

this is more in line with webOS, from palm. still lives in LG tvs. i mean, the front end of it.

the back end of it would be a much better option than eletron apps btw. but they were too early to the container age, since the paradigm was syscalls proxies

Not to detract from the coolness of this, but I wish new OSes dabbled in new GUIs as well.

Experimental operating systems seem to be dime a dozen by now, but we almost never see experimental GUIs or entirely new "desktop environments".

Just as how almost every "new" programming language is still stuck with semicolons and other C-isms that were ancient back when the Egyptians were laying down the pyramids, we're still stuck with either imitating the macOS GUI or the Windows GUI, or some weird Frankenstein's bastard of the two.

iOS, Android, consoles, and most recently the Vision Pro have proven that eschewing longstanding conventions can be successful — for example the vast majority of people on this planet don't need or care about scrollbars (or even menubars) anymore.

So why aren't the creators of experimental OSes being more experimental with the frontend? Come on guys, none but the nerds among us will be impressed with how it's made behind the scenes. The first impression that most people will get is that's just Yet Another WinMac-Looklike.

Does globbing not work in the shell?

I made (touched) a bunch of shit* files in ~/Desktop to amuse myself, which I guess is fine.

And then I made a few shit* files in ~, which should also be fine.

But when I try to mv my new shit* to ~/Desktop, it fails.

(ls shit* in ~ also fails.)

That warms my heart:

“ - Why isn't Puter built with React, Angular, Vue, etc.?

For performance reasons, Puter is built with vanilla JavaScript and jQuery. Additionally, we'd like to avoid complex abstractions and to remain in control of the entire stack, as much as possible.

Also partly inspired by some of our favorite projects that are not built with frameworks: VSCode, Photopea, and OnlyOffice.

- Why jQuery?

Puter interacts directly with the DOM and jQuery provides an elegant yet powerful API to manipulate the DOM, handle events, and much more. It's also fast, mature, and battle-tested.”

I don't know what's your benchmark to say those things?

OnlyOffice works better than LibreOffice, which is a native app.

Photopea works better than GIMP, which is a native app.

These devs clearly know what they're doing.

React and all the packages you champion were created to foster job security by introducing needless complexity and performance issues.

It would be a better world if we had more Photopeas and less Enriques

That’s a lot of smack talk for someone who didn’t provide a link to their own, even more impressive project.

This kind of reaction reminds me of people who can’t fathom why anyone would use a database without an ORM. (And meanwhile I’m confused because nearly everything I do with a database would be twice as difficult and ten times slower with an ORM in the way.)

I use Prisma and the TS typings in generates automatically have saved me countless times.

I used to hate ORMs like you. But auto generated types were the killer feature.

> Also, VSCode is built on Electron

That's not the point. The point is that it doesn't use a framework like React, Vue, etc., it instead directly creates and manipulates DOM elements, somewhat like Puter.

> This just tells me they don't understand why any of those things were created...

Like very nearly all FOSS, they were created to scratch their own developers' personal itches.

> ... and how to actually use them.

Their itches are not the same as everyone else's itches.

Super slick demo, I'm on mobile and it's impressively fast nevermind functional.

But it is 'just' a DE webapp right? From 'internet OS' here (which actually I don't think you use at TFA repo) I expected to be able to boot to it. I guess there is some other solution that would allow that, but not a package deal?

I suppose I'm just saying be careful/manage expectations with 'OS', but for what it actually is it's really cool.

It's got an app store, and it seems to implement embedding, windowing, and a virtual filesystem for arbitrary apps that have been built for it. I.E., When you open "Polotno" (a graphics editor), or what appears to be VSCode, it opens in a windowed IFrame, but then going to "Save" pops up a file selection dialog controlled by Puter, which lets you create a "file" which can then be accessed by the "Open" button in any other app.

It looks like there are other integrations between the DE/OS and its apps as well, like applications being able to set their window title dynamically (E.G. based on open file/tab), and an API allowing robust support for third-party apps. If you open one of the games like Doom, you'll see that it's usually hosted on a third-party site like DOS.Zone, but according to the query string using a custom build for Puter, which presumably has modifications to integrate with the desktop environment and filesystem. Other apps are hosted on Puter.site, .

So if you treat the browser as the "hardware" (and maybe also the backend services hosting a lot of the apps), maybe you could call it an "OS" in that it abstracts and manages a single environment for multiple other programs to run simultaneously and share information with each other.

I suppose `puter.js` is what passes for its LIBC, or the syscall interface:

https://docs.puter.com/

To OP: The information on publishing third-party apps doesn't seem very discoverable. The only mention I saw is in the popup that shows the first time you launch Dev Center, and after closing that I can neither find it again nor find anything else about it on Google (other than the linked terms, and the app IFrame source, which I presume is from GoogleBot's temporary account):

https://puter.com/incentive-program-terms

> Super slick demo, I'm on mobile and it's impressively fast nevermind functional.

No kidding. As far as I've seen, it's the best open paint app on android

This reminds me of something I made once in "Macromedia" Flash back when I was 16 in like 2001ish or so.

It wasn't really an actual OS, but I managed to get a working desktop with a file browser, fake non functional web browser, and a task bar and start menu.

My flash application didn't accomplish anything, but I felt immensely proud of having been able to create a mock up of a UI, even though it was extremely kludgy and wasn't even able to read or write files in the fake applications.

...No offense to the creator though. I don't mean to compare my high school project to this one. This project is indeed very cool!

I too dream of one day inventing my own kind of spreadsheet and terminal hackery OS, so I salute this person for creating a proof of concept that looks good.

This looks amazing. Also;

> Why isn't Puter built with React, Angular, Vue, etc.?

> For performance reasons, Puter is built with vanilla JavaScript and jQuery. Additionally, we'd like to avoid complex abstractions and to remain in control of the entire stack, as much as possible.

Absolute boss level.

With the new React 19 that changes everything once again™, I wouldn't be surprised if by React 20 or 21 they completely move away from the vdom.

Getting a compiler step seems like a first step towards that.

> the downvote isn’t an “I disagree” button

Take it from a guy that regularly posts unpopular truths: people vote based on the way they feel after reading. It has almost nothing to do with the content.

Edit: for example, try posting a personal opinion about a controversial topic and you’ll still have people downvoting to disagree as if it’s possible to tell someone that they are in fact wrong about a statement of what their opinion on a topic is.

It’s a bit sad if you think about what voting like that means, as content is often amplified or suppressed based on votes. Echo chambers seem inevitable

There is a flag button as well as the downvote.

Throwing in something about Gaza here would be off topic, political, and against HN guidelines.

> the downvote isn't an "I disagree" button

Would that it were so. HN has a down/up pair, which is definitely used to express agreement and disagreement.

IMO, HN would gain a lot by allowing for more flexibility in down votes - eg. being like SO that a downvote is only a quarter of a vote.