[HN Gopher] Show HN: 3 years and 1M users later, I just open-sou...
       ___________________________________________________________________
        
       Show HN: 3 years and 1M users later, I just open-sourced my
       "Internet OS"
        
       Author : ent101
       Score  : 1220 points
       Date   : 2024-03-04 22:31 UTC (2 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | yu3zhou4 wrote:
       | Really nice execution! Thanks for sharing
        
         | ent101 wrote:
         | Thank you very much! Glad you liked it :)
        
       | firstbabylonian wrote:
       | > For performance reasons, Puter is built with vanilla JavaScript
       | and jQuery.
       | 
       | jQuery is overdue for a comeback.
        
         | enriquec wrote:
         | could not disagree more. That statement alone makes me
         | completely lose any consideration for this entire project.
        
         | noduerme wrote:
         | It never really went away for me. I still reach for it in every
         | web app. Over time, I've stopped using some parts of it that
         | used to be timesavers... e.g. shifting away from $.ajax calls
         | to fetch, but it's a good base for rolling your own responsive
         | frameworks if that's what you want to do. And it's what I want
         | to do, because I dislike the paradigms for react and vue, and
         | have no interest in relying on those projects.
        
       | jethro_tell wrote:
       | 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?
        
       | rkagerer wrote:
       | Dec 2022 https://news.ycombinator.com/item?id=33838179
        
         | ent101 wrote:
         | Welcome to my annual HN roast :')
        
           | DustinBrett wrote:
           | Is it that time of the year again already?
        
             | ent101 wrote:
             | haha you feel me. We're united in vision and the roasting
             | lol
        
               | pvg wrote:
               | I suggested a name for this at one point and sounds like
               | willing Shubs and Zulls aren't that hard to find...
               | 
               | https://news.ycombinator.com/item?id=32233087
        
       | mixmastamyk wrote:
       | 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?
        
       | mattl wrote:
       | Congrats on getting this out there. Looks slick. I'll take a look
       | tomorrow when I'm back at a computer with a larger screen.
        
       | theogravity wrote:
       | 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.
        
         | orliesaurus wrote:
         | what's the reason you built it?
        
           | theogravity wrote:
           | 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.
        
         | haswell wrote:
         | Was curious to check this out, but no Firefox support is a non-
         | starter, unfortunately.
        
           | theogravity wrote:
           | Sorry about that. It should hopefully be fixed once we change
           | our A/V stack in a few months. I unfortunately do not have
           | specific details on why the A/V stack only works with Chrome-
           | based browsers.
        
       | willguest wrote:
       | I've been looking an OS for a VR computer (i.e. simulated but
       | functional workstation). This should work very well :)
        
         | ent101 wrote:
         | I've tested Puter on Oculus, seems to work pretty well;
         | however, I think very soon I'm going to do very specific
         | optimizations for XR, it's a new, emerging form factor that
         | deserves its own design.
        
           | willguest wrote:
           | 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.
        
       | simon_acca wrote:
       | The experience of making and publishing websites and apps from
       | within puter is sobering for how simple it is. Something to
       | aspire to
        
         | danlugo92 wrote:
         | Can you post a tldr here please...?
        
       | tambourine_man wrote:
       | 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."
        
         | tony_cannistra wrote:
         | Hell Yeah.
        
         | enriquec wrote:
         | This just tells me they don't understand why any of those
         | things were created and how to actually use them. It won't get
         | traction and it'll wallow and get stale since it'll be an
         | unmaintainable project. Also, VSCode is built on Electron while
         | Photopea and OnlyOffice are straight up painful to use.
        
           | simondotau wrote:
           | 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.)
        
             | enriquec wrote:
             | Must not be doing anything very complicated. Wheres your
             | impressive link if thats a prerequisite for discussion?
             | Some ORMs suck, I'll give you that.
        
               | simondotau wrote:
               | It's only a prerequisite if you want to belittle people
               | and accuse them of making ignorant technology choices.
               | (If the discussion was ORMs, I'd be delighted to have an
               | excuse to share and promote my public projects. But my
               | earlier aside doesn't constitute a change of topic for
               | this thread.)
        
               | enriquec wrote:
               | Wrong, its not a prerequisite in any case.
        
               | simondotau wrote:
               | Wrong. It's the rule, and has been thus for at least 270
               | years. Breaking it attracts a $500 fine and a gentle slap
               | in the face with a pair of leather driving gloves.
        
             | aurareturn wrote:
             | 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.
        
           | smarkov wrote:
           | > 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.
        
           | gertop wrote:
           | 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
        
             | tambourine_man wrote:
             | I agree with you, but there's no need for ad hominem
        
           | sgbeal wrote:
           | > 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.
        
       | boomskats wrote:
       | 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.
        
         | ent101 wrote:
         | Thank you! As a side note, we're open-sourcing the VSCode
         | integration soon. Building an integration with VSCode takes
         | quite a bit of work so hopefully the community will benefit.
        
           | mjburgess wrote:
           | 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).
        
       | 1attice wrote:
       | 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 :)
        
         | ametrau wrote:
         | What is a "mobile story"? Can you deliver some messaging in a
         | comment story?
        
           | 1attice wrote:
           | 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)
        
         | NikolaNovak wrote:
         | Did you try it on mobile? Seems to work fine on my iPhone.
        
           | 1attice wrote:
           | 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.
        
         | anon373839 wrote:
         | 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.
        
         | kerneldeimos wrote:
         | A proper mobile UI is something we're looking towards adding.
         | It's been coming up in conversation more frequently lately and
         | we'll probably announce on Discord when we start developing
         | that.
        
           | 1attice wrote:
           | 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.
        
       | qiqitori wrote:
       | Love it! I liked the Solitaire implementation. The terminal seems
       | very lacking, "ls" worked but e.g. "ls *" or the "find" command
       | didn't work.
        
       | redbell wrote:
       | Ah, Puter! That fascinating project surfaced on HN about a year
       | ago, claiming the top spot for most of the day. I'm delighted to
       | witness its transition to open source, allowing us to glean
       | insights from the creator. Gracias for sharing!
       | 
       | The emergence of such front-end projects provides a profound
       | glimpse into the maturation of front-end development and
       | showcasing the incredible possibilities it offers today.
       | 
       | Another really cool project, somehow related, is DaedalOS [2].
       | 
       | Honorable mention, Windows 11 in Svelte [3]
       | 
       | 1. https://news.ycombinator.com/item?id=33838179
       | 
       | 2. https://news.ycombinator.com/item?id=38830132 &
       | https://news.ycombinator.com/item?id=29779753
       | 
       | 3.https://news.ycombinator.com/item?id=35896505
        
         | DustinBrett wrote:
         | Thanks for the mention for daedalOS! I agree that when done
         | well these projects can help demonstrate the maturity of the
         | web as a platform. For anyone interested in checking out mine,
         | it's on my personal website @ https://dustinbrett.com/
        
       | mavili wrote:
       | 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!
        
         | Intralexical wrote:
         | Oh, wow. When this came up before, I don't know if I looked at
         | the DOM, because I assumed you would do this type of thing by
         | drawing pixels on a Canvas. It's actually made of HTML
         | elements? That's impressive.
        
           | Aaronmacaron wrote:
           | I too think it's very impressive but wouldn't it be even more
           | impressive if it was made using canvas? It would mean that
           | you would need to implement your own rendering loop and
           | layout engine. You'd need to reimplement a lot of elements
           | such as input fields or buttons. You get all of this for free
           | when building on top of HTML/CSS.
        
             | noduerme wrote:
             | You do get a lot of UI elements for free, but styling them
             | consistently and getting them to layout properly becomes a
             | lot more difficult.
        
             | Intralexical wrote:
             | 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.
        
             | onetom wrote:
             | It's hard to make that performant.
             | 
             | As a reference, here is a browser-adapted version of the
             | https://cuis.st/ Smalltalk environment, which does its own
             | rendering onto a canvas:
             | 
             | https://github.com/nmingotti/The-Cuis-CookBook/wiki/Run-
             | Cuis...
        
               | MatthiasPortzel wrote:
               | It's not performant if you're using JavaScript APIs. But
               | it's also possible to write to a canvas with WebGL, which
               | is hardware accelerated and is much faster than jQuery. I
               | believe (although I can't find a source for it now), that
               | xterm.js used this strategy.
        
             | mrBurger wrote:
             | 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.
        
             | moffkalast wrote:
             | That would be pretty slow, but with WebGL it could work.
        
         | tambourine_man wrote:
         | You can easily shoot yourself in the foot with jQuery (or
         | direct DOM manipulation for that matter), but it's not that
         | hard not to. It just requires some discipline, like most
         | things. React is also far from foolproof and not worth the
         | added complexity in most cases, IMO.
        
           | smaudet wrote:
           | 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).
        
             | solumunus wrote:
             | Curious which TS features you're referring to?
        
               | horacemorace wrote:
               | The level of easy facilitated in part by ts on
               | synchronous is too damn high, for one.
        
             | Dylan16807 wrote:
             | > 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...
        
               | smaudet wrote:
               | 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.
        
               | Dylan16807 wrote:
               | 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.
        
               | smaudet wrote:
               | > 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.
        
               | codethief wrote:
               | > I don't think the deprecated code that sets up enum
               | objects affects anything else...
               | 
               | TypeScript enums are deprecated now? I mean, yeah, they
               | aren't great and should best be avoided but the
               | deprecation would be news to me.
               | 
               | See also
               | https://stackoverflow.com/questions/70661260/are-
               | typescript-...
        
               | Dylan16807 wrote:
               | I accidentally exaggerated because it's an easy word for
               | a legacy feature you're supposed to avoid.
        
               | codethief wrote:
               | Thanks for clarifying!
        
             | devjab wrote:
             | 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.
        
               | codethief wrote:
               | > 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)?
        
               | pjc50 wrote:
               | Re-layout has to complete before any more JS runs. So if
               | you want to change two things, you get update-layout-
               | update-layout.
        
               | wizzwizz4 wrote:
               | Only if you yield to the layout engine (e.g. `await new
               | Promise(resolve => setTimeout(resolve, 0))`) in between.
               | Which, if you _know_ you want to change two things, why
               | would you?
        
               | pjc50 wrote:
               | .. or you accidentally request a layout property: https:/
               | /gist.github.com/paulirish/5d52fb081b3570c81e3a?ref=a...
               | 
               | (updating innerText sounds like an especially lethal trap
               | https://source.chromium.org/chromium/chromium/src/+/main:
               | thi... )
        
               | devjab wrote:
               | 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.
        
       | DustinBrett wrote:
       | Great to see you finally got it open sourced, congrats!
        
       | whalesalad wrote:
       | 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.
        
         | ghostly_s wrote:
         | Are you saying Synology's DSM is based on this Puter project?
        
           | usefulcat wrote:
           | Probably not but they have had a similar web-based interface
           | going back at least twelve years
        
             | jayknight wrote:
             | This is was more responsive than the Synology UI.
        
           | Renaud wrote:
           | DSM apparently uses Ext.js, not sure exactly which version
           | though.
        
         | whalesalad wrote:
         | Sorry - "this" being the concept not the literal codebase.
        
         | globular-toast wrote:
         | What kind of maintenance tasks? I always found the Synology
         | interface a bit of a pointless gimmick.
        
       | cushpush wrote:
       | When I was young I dreamed on having a USB stick (not yet
       | invented) I could take with me to different kiosks and have a
       | standard OS load my specific instances thanks to my custom key.
       | This approaches that functionality and I think it's pure
       | brilliance that you've included such thorough a demo for us to
       | enjoy that you spent so much time and enthusiastic effort into
       | creating and making manifest. So, I applaud you there and thank
       | you for making it open-source that's super cool, and might
       | inspire someone to make a kiosk that, by default, loads your
       | site.
        
         | DustinBrett wrote:
         | Nearly 20 years ago when I was in IT, I had something like this
         | using a tool called BartPE which allowed you to make a custom
         | WinPE environment that could be booted from a USB drive. As
         | someone who went on to make one of these "web desktops", maybe
         | things like BartPE were a partial inspiration.
        
           | mikewarot wrote:
           | 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!
        
             | peteradio wrote:
             | His name was Max Harddrive and he did kickflips on his
             | keyboard. Nobody could beat his quarter mile downloads.
        
               | ldp01 wrote:
               | Hahaha, I need to go watch Hackers right now!
        
               | pmarreck wrote:
               | I randomly watched a scene from it on YouTube based on
               | this comment, and in the background was a poster I never
               | saw before that said "Trust Your Technolust", and just
               | like that, I have my new life motto LOL
        
               | E39M5S62 wrote:
               | https://mako.cc/copyrighteous/trust-your-technolust
               | 
               | Just need to get the right color for your paper stock!
        
               | pmarreck wrote:
               | NICE!!
        
               | rnts08 wrote:
               | I unironically watched Hackers last night.
        
             | raffraffraff wrote:
             | 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.
        
             | mikewarot wrote:
             | Not a cloth backpack like we used to carry books for school
             | in.... one of these[1] from MicroSolutions. It plugged into
             | the parallel printer port.
             | 
             | [1] https://en.wikipedia.org/wiki/Micro_Solutions_Backpack
        
           | anthk wrote:
           | 20 years ago knoppix did far more.
        
             | int_19h wrote:
             | 20 years ago mounting NTFS read/write on Linux was a risky
             | proposition.
        
               | anthk wrote:
               | You could use ntfs.sys with some wrapper, can't remember.
               | It was almost safe.
        
             | airspresso wrote:
             | fond memories of Knoppix! Was so useful to boot into that
             | to debug, investigate, fix.
        
               | cylinder714 wrote:
               | 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.
        
           | pdntspa wrote:
           | 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.
        
           | cipehr wrote:
           | Oh man I remember BartPE and customizing the apps bundled
           | with it... thanks for the memories.
        
           | cuSetanta wrote:
           | For me it was Hirens BootCD. Seems like a slightly different
           | implementation but we swore by it to fix the most awkward of
           | issues.
        
         | petesergeant wrote:
         | For some reason I'd assumed this was the kind of thing that the
         | original Mac Mini would morph into, but of course I was wrong.
         | Searching for "PC Stick" shows up some interesting options.
         | 
         | I would dearly love to find a use-case for this[0], which with
         | a USB-HDMI might work almost as well
         | 
         | 0: https://store.planetcom.co.uk/collections/gemini-
         | pda/product...
        
         | vel0city wrote:
         | 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.
        
           | orev wrote:
           | Bootable USB that loads iPXE, with a custom boot config that
           | downloads the kernel and initrd from your own cloud server?
        
             | aspenmayer wrote:
             | This might do what you are thinking, and does use iPXE
             | under the hood.
             | 
             | https://netboot.xyz/
             | 
             | https://github.com/netbootxyz/netboot.xyz
        
           | aspenmayer wrote:
           | I replied to a reply to you in a subthread with this same
           | info, but since you're both sorta asking the same thing, I'll
           | post it here for you also.
           | 
           | https://netboot.xyz/
           | 
           | https://github.com/netbootxyz/netboot.xyz
        
         | fennecbutt wrote:
         | Samsung DeX.
        
           | digdugdirk wrote:
           | Is Samsung Dex able to boot/load to a standard Linux
           | environment? Initial look at it seems interesting, but I've
           | never really heard/seen much about it.
        
             | peterleiser wrote:
             | I've used Dex on my Galaxy Z Fold 4 and the apps are
             | Android apps. If you want linux on Android you can try this
             | suggestion (termux + ubuntu-on-android + vnc server): https
             | ://www.reddit.com/r/SamsungDex/comments/opyj6o/linux_on...
        
             | danlugo92 wrote:
             | You can also ssh into a linux vps fwiw
        
             | arendtio wrote:
             | 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.
        
         | whalesalad wrote:
         | Slax
        
         | binarysneaker wrote:
         | Tried Tails? https://tails.net/
        
       | ijxjdffnkkpp wrote:
       | You used the AGPL! Glorious! I commend and salute your efforts.
       | Thank you for your contribution!
        
       | blintz wrote:
       | This is such a neat idea, and you get the gist of it from just
       | the screenshot. I wonder what kinds of 'integration' you could do
       | (clipboard, opening links, drag-and-drop, etc). I could see this
       | as an educational tool for doing development on a Chromebook,
       | because of the (emulated) terminal + filesystem.
        
         | DustinBrett wrote:
         | Indeed the modern Web API's can do all that and more. One of my
         | favorites is dragging out of the browser onto the desktop.
         | Another is ctrl+c'ing a file on the real desktop and then
         | ctrl+v'ing it into the "fake" one. Some super powers sadly are
         | locked away in the need for a PWA, but I think they could one
         | day just be part of what any site can do.
        
         | AlexCoventry wrote:
         | Chrome OS has a developer mode which runs debian in a virtual
         | machine, FWIW.
        
           | danans wrote:
           | Technically it's not developer mode , it's just a regular
           | feature of the OS. "Developer Mode" on ChromeOS is when you
           | remove boot verification for ChromeOS itself.
        
       | infogulch wrote:
       | This reminds me of Kera Desktop [1]. Featured on HN 8 months ago,
       | 343 points, 111 comments [2].
       | 
       | [1]: https://desktop.kerahq.com/
       | 
       | [2]: https://news.ycombinator.com/item?id=36260589
        
         | ambigious7777 wrote:
         | And this anuraOS[0] too! I haven't looked to closely at it (it
         | showed up in my GH feed) but it looks like it uses v86[1] to
         | emulate a *nix environment.
         | 
         | [0]: https://github.com/MercuryWorkshop/anuraOS [1]:
         | https://copy.sh/v86/
        
       | Solvency wrote:
       | I love how this is done with jQuery. And it'll be obvious to
       | literally anyone whose ever used jQuery (and is a good designer)
       | how perfectly suitable and in many ways superior jQuery would be
       | for something like this. But 98% of developers will absolutely
       | balk at this in horror/confusion/wonder, despite the fact that
       | the React/Angular DIYs they'd make would be bloated and
       | outrageously slow.
        
       | OJFord wrote:
       | 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.
        
         | mattl wrote:
         | Yeah "OS" really overused.
        
           | baudaux wrote:
           | But it is a great project. For a real (Unix-like) OS you can
           | have a look to https://exaequOS.com (I am the creator)
        
         | klyrs wrote:
         | > 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
        
         | lphnull wrote:
         | 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.
        
           | Intralexical wrote:
           | Scratch OS is where it was at.
        
           | dietr1ch wrote:
           | Here's the best flash OS that will ever exist,
           | 
           | https://www.jamesweb.co.uk/windowsrg
        
         | Intralexical wrote:
         | 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
        
       | GMoromisato wrote:
       | 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?
        
       | indigodaddy wrote:
       | What's the "publish as website" thingy/functionality all about?
        
       | elwell wrote:
       | Beautiful execution! Though I'm crestfallen it has no Browser app
       | with which to view an inception of Puter within.
        
         | LoganDark wrote:
         | Just open the Puter app: https://puter.com/app/puter
         | 
         | Alternatively, open the PuterPuter app, which contains itself:
         | https://puter.com/app/puterputer
         | 
         | You're welcome
        
           | lagniappe wrote:
           | what about just a browser in general?
        
             | keepamovin wrote:
             | I want to add BrowserBox to it, which is a web browser you
             | can embed in any web app haha! :). It will require a
             | backend tho but it should work.
             | 
             | https://github.com/BrowserBox/BrowserBox
        
           | isuckatcoding wrote:
           | This just sent it in an infinite loop of open puter
        
         | keepamovin wrote:
         | Technically you could fake it with an iframe if puter is served
         | with the correct frame-src CSP rules. But for a full browser
         | experience you'd need a backend and a remote browser.
        
         | pcloadletter_ wrote:
         | You can do this on daedalOS https://dustinbrett.com/
         | 
         | edit: and obviously you can play Doom on it
        
           | smaudet wrote:
           | Are the changing colors on purpose? Noticed it has some
           | issues browsing in firefox (so it might be broken).
        
             | DustinBrett wrote:
             | If you are referring to the background, indeed the colors
             | change on purpose. It would be cool if that wasn't on
             | purpose. As for browsing issues in Firefox, could you
             | clarify the issue? If it's around using the Browser app, it
             | is just an iframe so many sites will not load in it.
        
       | semolino wrote:
       | More web desktops: https://simone.computer/#/webdesktops
       | 
       | Note that most of these are aesthetic / non-CRUD.
        
       | hliyan wrote:
       | Why is this so easy to read compared to React?
       | https://github.com/HeyPuter/puter/blob/master/src/UI/PuterDi...
        
         | ashishb wrote:
         | The JSX syntax makes React hard to read due to multiple layers
         | of nesting.
         | 
         | IMHO, Vue is superior for both maintainability and readability
         | than React. Especially because CSS, JS anda HTML are largely in
         | separate blocks of the same file.
        
           | benatkin wrote:
           | You can see this in that Flutter didn't copy JSX and its
           | usability seems better.
           | 
           | Not that I'm confident Flutter is worth the trade-offs.
        
             | pmarreck wrote:
             | _narrator:_
             | 
             | It's not.
        
             | mightyham wrote:
             | I'm confused about what you mean by this. There's nothing
             | about Flutter's API that encourages less nesting, In fact,
             | it's the exact opposite. Plenty of layout and styling that
             | takes a number of nested widgets in Flutter can be achieved
             | using a single div in React.
        
           | CharlieDigital wrote:
           | I can understand some of the benefits of JSX, but compared to
           | Vue SFC's, it's a mess to read.
           | 
           | React CSS modules feel so unwieldy compared to Vue SFC's
           | inline `scoped` CSS.
           | 
           | Vue's approach to templating using `v-for` and `v-if` means
           | that you won't end up with a big block of logic mixed in with
           | the template (you can still do it, but Vue's nature steers
           | you away from it).
        
           | noduerme wrote:
           | Arguably they should all be in external files. HTML in one,
           | CSS in another, and Javascript to load and cache them without
           | any embedded strings. That's how I prefer to write. For one
           | thing, it lets me choose which things I want to cache and
           | which I don't. I can compile from SCSS and deploy without
           | changing any JS or HTML files. Usually my rollups are just
           | the JS.
        
         | jahewson wrote:
         | Because it's trivial?
        
         | pcloadletter_ wrote:
         | That's a pretty small component and I think folks would find a
         | comparable React component also pretty easy to read.
         | Conversely:
         | https://github.com/HeyPuter/puter/blob/master/src/UI/UIDeskt...
        
           | ent101 wrote:
           | I'm sorry XD
        
             | pcloadletter_ wrote:
             | Ha, I am not criticizing your work at all. It's nothing
             | short of jaw-dropping.
        
         | divbzero wrote:
         | I guess "React makes sense for more complex UIs" is not hard-
         | and-fast rule. jQuery, apparently, is more than enough for
         | clean working frontend code.
        
           | omeid2 wrote:
           | It is not about complex UI per se, it is about complex state.
           | With jQuery, the State is duplicated in the DOM instead of
           | mirrored and is very hard to keep in sync.
        
             | FpUser wrote:
             | >"State is duplicated in the DOM instead of mirrored"
             | 
             | And the difference between duplicated and mirrored is ...
        
               | omeid2 wrote:
               | Fair question.
               | 
               | Mirrored means when you update state, your changes are
               | reflected in the DOM, automagically.
               | 
               | Duplicated means when you change state, you also have to
               | make the changes to the DOM, yourself.
        
               | divbzero wrote:
               | Clear (mostly one-way) data binding is definitely one of
               | React's strengths.
               | 
               | It appears that Puter handles templating with a pattern
               | like:                 let h = ``       h +=
               | `<div>${exampleContent}</div>`       h +=
               | `<div>${moreExampleContent}</div>`
               | $(targetEl).append(h)
               | 
               | And handles events in the traditional way:
               | $(targetEl).on('click', function () { /* do stuff */ });
               | 
               | Searching for "React" or "jQuery" in this thread, there
               | are several other conversations with thoughtful comments
               | about pros and cons. One curious tidbit that I learned is
               | that Visual Studio Code doesn't use a framework either
               | and, like Puter, updates the DOM directly.
        
               | omeid2 wrote:
               | The main issue is that "$(targetEl).append(h)" is not
               | idempotent.
               | 
               | This might seem like a small issue on the surface but as
               | your application grows, this either becomes a big problem
               | or you have reinvented React, Vue, or something similar,
               | but without the extensive testing and developer/community
               | availability. Which is essentially what VSCode does for
               | example, using some sort of MVP* pattern.
        
             | djbusby wrote:
             | Write state to DOM, read state from DOM.
        
               | omeid2 wrote:
               | In sounds nice in theory, but in practice, it doesn't
               | work out. The example linked is a good one, a popover,
               | the underlying DOM disappears, but the "state" behind it
               | remains at least a bit longer.
        
               | QuadrupleA wrote:
               | I've practiced for decades and it works out fine. It's
               | good to explore outside the React cargo cult from time to
               | time.
        
               | omeid2 wrote:
               | Can you share some complex application you have worked on
               | that doesn't use a framework or end-up inventing one
               | internally like VSCode for example?
               | 
               | I did web not just before React but before jQuery and
               | MooTools. So it is funny you ask I should explore outside
               | "React cargo cult".
        
             | rtcoms wrote:
             | Why not use a state management library like xstate with
             | jQuery ?
        
             | xorcist wrote:
             | There is no sync if the state is the DOM.
        
         | blackoil wrote:
         | This component has no state, no data fetch or transitions. It
         | doesn't even have any dynamic part.
        
         | raggi wrote:
         | Despite being asynchronous it contains a single linear schedule
         | and two callbacks. The obvious outcome is two layered
         | constructors, and a single top level API object with two custom
         | events.
         | 
         | You couldn't describe what was going on in an equivalent
         | functional construction of a react version unless you first
         | head off on a diatribe about signals/hooks/state-management-
         | disaster-du-jour, the choice of use of which would have
         | implications to both the event handlers in some way - though
         | they likely couldn't be in-place here, they'd have to be passed
         | down from parent context in a giant dance of inversion of
         | control. At runtime the outcome would likely get parsed twice
         | (once for shadow, once for insertion) if not more times under
         | certain compositions. Here the jquery is almost incidental, and
         | could be quickly replaced by something else - for example want
         | to swap out htmx here, well, just add the markers to the DOM,
         | delete the jquery lines and you're done. You'd probably need to
         | spend at least an hour figuring out if you could fit something
         | independent and platform-native into your react code base, hell
         | I've seen people burn weeks on it.
        
       | maxloh wrote:
       | 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.
        
       | waldrews wrote:
       | Curious how AGPL would apply for something like this. This seems
       | like a tool to put a nice front end on a complex app, but would
       | that trigger copyleft for the the overall backend?
        
       | pdntspa wrote:
       | I hate that these guys have to justify using jQuery. Too many of
       | you have been seduced by all these bullshit javascript stacks
       | that just add a seemingly infinite amount of complexity to
       | something that is already almost too complicated.
        
         | danielovichdk wrote:
         | Amen!
        
         | dartos wrote:
         | Ah, jQuery, that cute little artifact from web development's
         | stone age, where manipulating the DOM directly was the height
         | of innovation. How quaint it seems now, in the shining era of
         | React, where state management is not just a task but, once it
         | gets its hooks in you, evolves to a transcendent experience. To
         | cling to jQuery is like insisting on using a typewriter in a
         | world of voice-to-text AI, but adorably obsolete. React, with
         | its majestic state orchestration, makes jQuery's efforts look
         | like child's play. It's like comparing the glow of a firefly to
         | the brilliance of a laser beam. Truly, we React devotees can
         | only chuckle at the notion of jQuery, for we have tasted the
         | future, and its name has and always will be React.
         | 
         | /s
        
           | lioeters wrote:
           | > state management..gets its hooks in you
           | 
           | Pun appreciated.
        
         | ent101 wrote:
         | Yes, I've been asked why we use jQuery many times so I had to
         | put it in the FAQ. I think we have solid reasons for it but it
         | is controversial sometimes.
        
         | saidinesh5 wrote:
         | Does jQuery by itself offer any value these days compared to
         | plain Javascript though?
         | 
         | I was under the impression jQuery was for the IE5 days where
         | not all browsers provided the same javascript APIs and doing an
         | xmlhttprequest was more clunky than doing a fetch() call these
         | days.
         | 
         | At least for my personal Jekyll based blog, I was able to
         | replace 40-45 lines of jQuery with 50 lines of plain Javascript
         | and was able to get rid of 33kb of jquery dependency.
        
           | QuadrupleA wrote:
           | jQuery is still great. Just take this site (which is
           | ironically arguing the opposite viewpoint)
           | https://youmightnotneedjquery.com/ and notice how all the
           | "modern" (tech's vaguest and most meaningless adjective) code
           | is 2-3x as verbose and complicated.
           | 
           | And 33kb, you can probably gain that by changing your jpeg
           | compresion level from 80 to 79.
        
         | niels_bom wrote:
         | I think there are valuable positions to take in between "let's
         | manipulate the DOM by hand" and "React Server Components,
         | NextJS and the kitchen sink".
         | 
         | I personally think there's great value in the pattern of
         | reactivity where parts of your DOM update based on bits of
         | data. Developing, designing and testing components like this
         | becomes way simpler.
        
       | peterleiser wrote:
       | Looks very cool. Am I correct that this is more like a client and
       | that the persistence (user storage, sessions, etc) is handled by
       | the proprietary non-open source cloud backend? Not a criticism,
       | just trying to understand.
        
         | asveikau wrote:
         | It would be cool to self host the backend. I wouldn't want to
         | put files on some guy's server, both from the eavesdropping
         | angle and from the perspective that it could be abruptly shut
         | down and lost.
        
         | willi59549879 wrote:
         | it is basically a webserver written in javascript. you can
         | clone the git repository and run the server on your pc
        
         | kerneldeimos wrote:
         | 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.
        
           | garyrob wrote:
           | 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?
        
             | kerneldeimos wrote:
             | > 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.
        
               | garyrob wrote:
               | Thanks! Let me ask you another question. I'm making a CLI
               | app that could run in wasm (it's written in Rust).
               | Normally, users will run it on their own machine in their
               | own terminal. But I also want them to be able to access
               | it while they're traveling. I'm wondering if there's some
               | way I could make it available in the Puter terminal, such
               | that anyone with a Puter account could run it there when
               | they are away from their own terminal. Would that be
               | possible now with Puter, or is it something that will be
               | possible in the future?
        
               | kerneldeimos wrote:
               | That will be possible in the future. The shell is also
               | open source (https://github.com/HeyPuter/phoenix) so we'd
               | also gladly accept any contributions that add the
               | capability to execute wasm files from the filesystem.
        
       | FpUser wrote:
       | Beautiful work. Much appreciated
        
       | Th3Alt3r wrote:
       | Very cool, LFG!!!!!!
        
       | koukides wrote:
       | Love it!! I own the domain internet.inc that would be perfect for
       | this - want to use it??
        
         | MH15 wrote:
         | Woah that's a crazy domain. Worth a lot. Love your parking
         | page!
        
           | koukides wrote:
           | It's for sale, email me :)
        
       | arcastroe wrote:
       | Inside the OS, there's a game called Danger Cross, which seems
       | very similar to crossy roads. Did the Puter developer essentially
       | reimplement crossy road? Or was there some open source version
       | already existing could somehow run on this "OS" ? Briefly
       | searching google for Danger Cross didn't yield any results.
        
         | diggan wrote:
         | 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.
        
         | kerneldeimos wrote:
         | Many of the apps are user-submitted apps from puter.com
        
       | codeonline wrote:
       | I just wanted to say well done. I wish other eco systems were
       | this open, hackable and understandable.
        
       | Razengan wrote:
       | 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.
        
         | kerneldeimos wrote:
         | As an avid user of i3wm, the "YAWML" that you described isn't
         | my favorite. The good news is we're working on architectural
         | changes that will make it easier to develop alternative desktop
         | environments that use the same APIs. I have a daily video chat
         | with the author and the topic of custom guis is something that
         | comes up pretty often.
        
       | sn0n wrote:
       | Are you the MS guy with a YouTube channel who's website is
       | basically this? Can't recall the channel right now though.
        
         | DustinBrett wrote:
         | That would be me, the other guy in Vancouver making a web
         | desktop. :-)
         | 
         | Thanks for the mention https://www.youtube.com/@DustinBrett
        
       | Intralexical wrote:
       | So... Somebody submitted Half Life/Xash3D as a Puter app:
       | 
       | https://puter.com/app/half-life-c3j01ag3pyd
       | 
       | It looks like it's using a build of the below, hosted on
       | GitHub.io:
       | 
       | https://github.com/Pixelsuft/hl
        
         | kgeist wrote:
         | I wonder what are the security implications. I just opened a
         | random URL and an arbitrary application was launched inside my
         | Internet OS desktop. What if someone gives me a link to a
         | malicious password stealer, for example? I think a permission
         | system would be nice.
        
           | Intralexical wrote:
           | 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.
        
           | evere wrote:
           | Maybe it could be "sandboxed" in an iframe?
        
         | splatzone wrote:
         | I can't get past the menu, is it just me?
        
           | samieljabali wrote:
           | Got to use the keyboard to navigate the menu.
        
           | TrackerFF wrote:
           | worked fin here, launched a multiplayer game - everything
           | seemed smooth.
        
           | RobotToaster wrote:
           | Not working on firefox for me.
        
         | LeonM wrote:
         | 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.
        
           | Intralexical wrote:
           | 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.
        
       | soloknight wrote:
       | This is soo freaking amazing !! What a legend
        
       | lovestaco wrote:
       | Pretty slick
        
         | geek_at wrote:
         | Kind of reminds me of EyeOS [1] I was using it heavily in 2005.
         | Mindblowing experience at the age of Windows XP
         | 
         | [1] https://en.wikipedia.org/wiki/EyeOS
        
       | isoprophlex wrote:
       | 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.
        
         | theK wrote:
         | Does this argument really still stand nowadays, with all the
         | virtual DOM and whatnot that those frameworks bring OOB?
        
           | trashburger wrote:
           | Not sure why you're downvoted, it's a valid question (the
           | downvote isn't an "I disagree" button). I believe the answer
           | the Puter author came up with is that the VDOM takes away too
           | much of the control from the author. They do make life easier
           | but they have an abstraction cost (mental overhead) and in
           | case of some of them performance issues (execution overhead).
        
             | zarathustreal wrote:
             | > 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
        
               | isoprophlex wrote:
               | Hello! Would you like to post any opinion at all, or in
               | any possible way mention anything about, the humanitarian
               | situation in Gaza?
        
               | sam_goody wrote:
               | 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.
        
               | zarathustreal wrote:
               | I try to minimize posting (edit: and having) opinions
               | most of the time, they don't tend to generate interesting
               | discussion (edit: and are highly limited by perspective).
               | Kinda hard to come to a conclusion when the assertions
               | all boil down to "this is my experience"
        
             | sam_goody wrote:
             | > 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.
        
           | lopis wrote:
           | I thought we're moving away from virtual DOM?
        
             | trashburger wrote:
             | Who's "we"? React is still by far the most popular
             | framework. I personally like Solid better but I'm just one
             | person vs. many who actively write React code.
        
               | monsieurbanana wrote:
               | With the new React 19 that changes everything once
               | again(tm), 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.
        
           | isoprophlex wrote:
           | I'm not really writing that to stir up js framework shit,
           | mostly just commenting on the insane dedication to ideals
           | needed to go "fuck it i'll just use jQuery" on a project of
           | this scope. At least, from my brainlet dev perspective, a
           | move like this is 100% boss level.
        
             | theK wrote:
             | Yeah, I got that. The reason I asked is that to me it is a
             | genuine question. I would have thought that with all the
             | effort that is going into component frameworks (and into js
             | runtimes too), the performance difference would be small
             | either way. As it has happened with compilers in a sense.
        
           | rakoo wrote:
           | Virtual DOM has always been about ease of programming, never
           | about performance. Since this model has existed, all the work
           | has been made to gain more performance but still not fast
           | enough compared to direct DOM access.
        
       | lavrton wrote:
       | 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.
        
         | ent101 wrote:
         | Thank you, Anton! Polotno is incredible. I recommend everybody
         | to check it out!
        
         | samsquire wrote:
         | 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.
        
         | genuine_smiles wrote:
         | Could you elaborate on how Puter helped?
        
           | lavrton wrote:
           | 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.
        
             | exodust wrote:
             | 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?
        
               | lavrton wrote:
               | 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.
        
         | dwilding wrote:
         | 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/
        
           | Ajedi32 wrote:
           | Interesting! What's the advantage of Puter in this scenario
           | compared to, say, Google Drive, or Dropbox?
        
             | lavrton wrote:
             | I would say much simpler integration. puter.js SDK is super
             | straightforward and fast to integrate.
        
             | dwilding wrote:
             | 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.
        
       | mouzogu wrote:
       | "Puter is built with vanilla JavaScript and jQuery"
       | 
       | respect.
        
       | gorkaerana wrote:
       | A slightly unfortunate name for Spanish speakers, I'm afraid:
       | "putero" can mean either "brothel" or "man who maintains sexual
       | relations with prostitutes" [1].
       | 
       | Fun fact: the Mitsubishi Pajero had to be marketed as Montero in
       | Spanish speaking markets as "pajero" is Spanish for "wanker" [2].
       | 
       | [1] https://dle.rae.es/putero
       | 
       | [2] https://dle.rae.es/pajero
        
         | Beijinger wrote:
         | Wanker is a family name in Austria. I knew a scientist who
         | started every talk with the origins of his family name....
        
           | ClikeX wrote:
           | We've got Dutch people that are literally called Dick Cock.
        
           | gorkaerana wrote:
           | Spanish also delights us with unlucky surnames. E.g., three
           | acquaintances of my father have the family names "Feo",
           | "Bastardo", and "Gay"; which translate, respectively, to
           | "ugly", "bastard", and, of course, "gay".
        
             | Beijinger wrote:
             | Well, I know European Companies that wanted to expand into
             | the US market.
             | 
             | One was named PMS LLC and one had a product that was named
             | xfriend.
             | 
             | Both names are very memorable, but not the best choice.
             | 
             | Xfriend was actually a pretty good software:
             | https://xfriend.soft112.com/
             | 
             | (only description, not for download anymore)
        
         | henryackerman wrote:
         | Similary, the Hyundai Kona is called the Hyundai Kauai in
         | Portugal as "cona" literally translates to "pussy".
         | 
         | Languages are fun :)
        
         | pantulis wrote:
         | Not forgetting the case of the Seat Malaga that had to be
         | marketed in Greece as Seat Gredos because Malaga sounded too
         | similar to "Malaka". I'll let any fellow greek readers explain
         | the meaning ;)
        
       | anonzzzies wrote:
       | Possible to write our own window manager? I guess just diving
       | into the code, but that would make it very hackable of course.
       | And fun.
        
       | ulrischa wrote:
       | Make JQuery great again
        
       | Zenst wrote:
       | Impressive and reminded of
       | https://en.wikipedia.org/wiki/Java_Desktop_System
        
       | jaequery wrote:
       | jQuery? :D
       | 
       | it's true, coding was easy with jQuery ...
        
         | ent101 wrote:
         | username checks out :D
        
       | sgbeal wrote:
       | It's all fun and games until we reflexively hit ctrl-w to close a
       | virtual window and end up closing the browser tab that window is
       | running in :/.
        
         | diggan wrote:
         | 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.
        
       | throwaway11460 wrote:
       | Anybody remembers the original (not Apple) iCloud web desktop?
       | 
       | Or EyeOS?
        
         | 1oooqooq wrote:
         | 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
        
           | throwaway11460 wrote:
           | Why do you think so? It seems to be exactly what eyeOS was -
           | especially given the enterprise use cases the author listed.
        
         | nhanhi wrote:
         | I used to mess with EyeOS a lot back in the day - same thing,
         | and although I enjoyed it, I suspect the utility will be just
         | as limited.
        
       | thatgerhard wrote:
       | What is this used for?
        
       | kwhitefoot wrote:
       | 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.
        
       | RGamma wrote:
       | 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.
        
         | oblio wrote:
         | 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.
        
           | projektfu wrote:
           | Was that the merino massacre of 1887?
        
           | lukas099 wrote:
           | Something to do with the Silk Road?
        
             | oblio wrote:
             | Silk, and in general almost every type of clothing until
             | modern cotton processing. Most traditional clothing was
             | very coarse and one of the most obvious class indicators,
             | across millenia.
        
               | scarby2 wrote:
               | silk was so in demand and so lucrative a product that at
               | one point smuggling silk worms out of china was
               | punishable by death. I think the price of a silk shirt in
               | the middle ages was roughly comparable to a luxury car
               | today.
        
               | szundi wrote:
               | These comparisons always bring up the fact in my mind
               | that the lowest class people today have so much better
               | sanitation, like toilets compared to kings back then
        
           | yowayb wrote:
           | Convenience is the mother of invention
        
             | tamimio wrote:
             | *laziness
        
           | mc32 wrote:
           | Was linen itchy? At least modern linen is not itchy.
           | Presumably it would have been less itchy than coarse wool
           | even nice wool.
        
         | RobotToaster wrote:
         | Can the browser on puter run puter though?
        
           | ssl-3 wrote:
           | It can.
           | 
           | https://puter.com/app/puter
        
         | lloeki wrote:
         | The Birth & Death of JavaScript
         | 
         | https://www.destroyallsoftware.com/talks/the-birth-and-death...
        
         | jauntywundrkind wrote:
         | 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.
        
       | marcinioski wrote:
       | I've spent whole yesterday evening for finding something like
       | this. Great work!
        
       | eisbaw wrote:
       | I still don't get the appeal. Why would you want this again?
        
       | 0xDeveloper wrote:
       | I used it, I loved it!
       | 
       | But why would someone use it?
        
       | Kalanos wrote:
       | 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?
        
         | kerneldeimos wrote:
         | 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.
        
       | BMSR wrote:
       | First thing I tried was checking if I could use it to share
       | images. Which would be a nice way to organize what I share in
       | folders. But apparently it can only be opened inside Puter
       | itself, and it asks the user if they want to download it.
        
       | Jemm wrote:
       | Been looking for something like this for use with a VR headset
       | for coding.
        
       | thomasfl wrote:
       | If anyone was in doubt; jQuery is not dead. For anyone who wants
       | to write minimalistic and efficient vanilla javascript, jQuery is
       | still being maintained and used by many.
        
         | kilroy123 wrote:
         | 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.
        
       | rocky_raccoon wrote:
       | Here's my "contribution":
       | 
       | https://puter.com/app/browser-n70yre8kj1
        
       | tcgv wrote:
       | Interesting to see that it's written more "low level": vanilla JS
       | and jQuery (nostalgia kicks in). I guess it's analogous to why
       | linux/windows kernels are still written in C language.
        
       | stochastimus wrote:
       | Thanks for this, OP. This is why I come here.
        
       | dlivingston wrote:
       | I just want to point out how clean and pleasant to read this
       | codebase is. I'm starting to learn JavaScript, coming from a
       | background of systems programming, and I bookmarked this codebase
       | just as a benchmark example of what good JS code looks like.
        
         | ent101 wrote:
         | Thank you! I'm glad you liked it. Follow along on Github, we're
         | a friendly community and open to contributors with all levels
         | of JS experience :)
        
       | chse_cake wrote:
       | how can I pip install on this?
        
       | account-5 wrote:
       | 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.
        
       | caycep wrote:
       | is this basically a VM (w gui) running on the browser?
        
       | rbanffy wrote:
       | It has an interesting similarity with IBM's ZOWE web UI. Is there
       | any commonality in the building blocks?
        
       | renonce wrote:
       | 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
        
       | ssl-3 wrote:
       | 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.)
        
       ___________________________________________________________________
       (page generated 2024-03-06 23:02 UTC)