[HN Gopher] Spacedrive - an open source cross-platform file expl...
___________________________________________________________________
Spacedrive - an open source cross-platform file explorer
Author : microflash
Score : 239 points
Date : 2023-10-11 04:54 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| quyleanh wrote:
| > After 15 months of development we are extremely excited to be
| releasing the first version of Spacedrive as an early public
| alpha. [1]
|
| [1]
| https://github.com/spacedriveapp/spacedrive/releases/tag/0.1...
| brianhorakh wrote:
| What is blocking android release. Keen to beta.
| edrxty wrote:
| So what's this get you over something like syncthing?
| hobofan wrote:
| Since when is Syncthing a file explorer?
| buster wrote:
| And since when do file explorers come with their own
| distributed file system?
| PurpleRamen wrote:
| Since always. Technically, any file explorer is accessing
| distributed storage. First the multiple storage-devices in
| your local system, later the different storage in your
| local network, which then grew to support remote servers
| like FTP, Webdav, etc. And modern file managers have for
| some years now also support for cloud-storage like OneDrive
| or Dropbox. Nothing new here, except being an app build
| from the ground up for supporting this specific targets.
| hobofan wrote:
| Since cloud storage solutions come preinstalled with the
| operating system. E.g. Finder + iCloud, Windows file
| manager + OneDrive.
| graemep wrote:
| That is because the OS developer wants to push their
| product, not because it is something users want.
|
| A third party cannot decide to provide something users do
| not want. Maybe they can get it preinstalled on Windows
| PCs or ANdroid phones. I cannot see MS (Or Google) being
| very happy with that.
| sandebert wrote:
| It seems to me that an alternative could be to simply pair FUSE
| with any standard file explorer.
|
| https://github.com/libfuse/libfuse
|
| https://github.com/libfuse/libfuse/wiki/Filesystems
| oblio wrote:
| Heck, they could do it with FTP and call it a day!
|
| https://news.ycombinator.com/item?id=9224
| risyachka wrote:
| Obviously this is targeted at users like me that have zero
| intention and interest in pairing anything and just want it to
| work out of the box.
| sandebert wrote:
| I agree. Just as long as you know you can't directly open
| files from other filesystems in your regular apps, just
| because you see them in Spacedrive.
| graemep wrote:
| That was my reaction too, but FUSE is Linux only while this is
| cross-platform.
|
| I am not convinced file managers need to be cross platform.
| There are plenty that will run on any desktop, IMO mobile
| platforms need different functionality and a very UI.
|
| The real product as described on their website (not the github
| repo the linked) is that it is a drop box like sync service
| integrated into a file manager. I think most non-geeks will
| find it confusing compared to something that integrates with
| the familiar OS default file manager.
| sandebert wrote:
| Yeah, FUSE is Linux only. But for completeness, for macs
| there is macFUSE, and for Windows there is winfsp. Both of
| these have fewer filesystems than FUSE, and I've used neither
| so I don't know how well they work.
|
| https://github.com/osxfuse/osxfuse/wiki/List-of-macFUSE-
| File...
|
| https://winfsp.dev/doc/Known-File-Systems/
| drpixie wrote:
| Absolutely agree.
|
| If they think they can make a better file manager, great, go
| ahead. But including transports in the file manager means that
| remote data only _looks_ integrated, it isn 't actually
| available to local apps.
|
| Or (just as bad) they'll decide they need a copy-to-local and
| copy-back-to-network mechanism, which will work for some files
| opened by some apps but not all. Arghh.
|
| Nemo (under Linux) does that for some protocols (eg. Android
| media transfer), and it is very annoying, especially as there
| are already FUSE drivers for (at least some) such protocols. In
| practice it means that the only thing you can do using Nemo is
| copy/move files around.
| sandebert wrote:
| That's a very good point, I didn't even think about the
| aspect that FUSE is available system-wide, for all other
| applications to use transparently. That makes Spacedrive seem
| to come up really short, in comparison.
| CivBase wrote:
| Can we stop treating "written in Rust" as a feature? It's one of
| the first things in the README. Whenever I see that I don't think
| "more stable", I think "someone's pet project".
| Klaster_1 wrote:
| Decided to try it out. After the installation, it asks to "create
| the library", share the analytics and log in - not exactly what I
| expected compared to other file explorers. Next, I decided to
| navigate to a random directory on one of my drives. After double
| clicking, nothing happened. Opening a dir with a context menu
| action did nothing too. Turns out 15k files in a directory make
| it effectively non-navigable. Total Commander and Window Explorer
| have no such issues. Spacedrive still has to iron out the basic
| file explorer features, it seems.
| offices wrote:
| Windows Explorer does struggle with many files in a directory
| on a HDD. It doesn't cache the sort order, so opening it with
| anything other than alphabetical order means waiting 5+ minutes
| for it to sort them.
| Void_ wrote:
| Seems like most React apps never think of supporting large
| amounts of data.
|
| Not blaming them - the framework should support it out of the
| box. You shouldn't have to understand virtualized lists.
|
| I made a TableView in SwiftUI and I can scroll through
| thousands of without having the slightest idea how it works
| under the hood.
| SoKamil wrote:
| I presume that by TableView you mean List { } component.
| Sadly, there is no component for large horizontal lists in
| SwiftUI and no, ScrollView with LazyHStack is not an answer
| due to memory issues.
| Void_ wrote:
| There's a table view now. I made iTunes-like UI for my
| Spotify songs. Buttery smooth.
| SoKamil wrote:
| https://developer.apple.com/documentation/swiftui/table
|
| This one?
| throwaway50702 wrote:
| You can use one of the React-Virtualized components without
| the slightest idea how it works. TableView from SwiftUI is
| the same thing - a component that implements virtualization
| on top of the base GUI library for you.
|
| React is not a UI framework, it's a low level reactive
| library with very limited scope - even the DOM bindings are
| shipped separately, and it can be used for much more than
| just GUI, for example VR experiences or cloud infrastructure
| deployment. Bring your own batteries.
| jwells89 wrote:
| The issue with the "bring your own widgets" approach in my
| experience is that it's unusual for third party widget
| packages to have anywhere near the sort of depth and
| breadth of capabilities compared to the same widgets that
| come OOTB with native UI toolkits. This means "shopping"
| for the widget with the best tradeoffs for one's particular
| use case and making up for whatever inadequacies it comes
| with yourself (or just living with the inadequacies,
| resulting in a crappier app), which is annoying at best.
|
| It's so much nicer to just be able to trust that an
| extensive library of stock widgets will be able to do
| whatever it is that you need, as tends to be the case with
| AppKit/UIKit.
| throwaway50702 wrote:
| That'd be something provided by the Web platform (through
| the DOM bindings), not React. React provides a way to
| work with the DOM elements/native components/etc in a
| reactive way.
|
| The real problem is that the Web platform doesn't offer a
| good set of customizable UI elements other than the most
| barebone basics.
| threeseed wrote:
| When you're building a cross-platform app OSX isn't the
| weakest link. It's older versions of Windows and Linux.
|
| And UI libraries like Tailwind, Shoelace etc are
| surprisingly extensive and constantly being improved. And
| if something isn't to your liking it's often to trivial
| to change it.
| trollied wrote:
| Something has gone wrong somewhere when your file manager UI
| is written in React.
| mrtesthah wrote:
| Oh yikes, this runs in a browser? What a waste of time to
| build something like this.
| oblio wrote:
| I tried to build something much simpler than this.
|
| For integration with cloud services you're going to run
| into OAuth, and guess what, that dance happens in a
| browser: get access to cloud drive -> get sent to
| provider login <<web>> page (or authorization page) ->
| get sent somewhere else.
|
| I mean, you can build it without the browser, but a key
| and very early step involves a browser, you need it
| anyway. Might as well ship your own if you can do it.
| throwaway50702 wrote:
| Seems like a very nice app that works on multiple
| platforms, and it's even gifted to the community as open
| source. I don't know where you found the audacity to call
| something waste of time, but please keep it to yourself.
| threeseed wrote:
| It uses Tauri which is the Rust equivalent of Electron.
|
| I'm building an app using it now and it's significantly
| better than past attempts at browser-based, cross
| platform app development. It is extremely fast and
| efficient so apart from UI controls not looking the same
| it will be on par with a native app.
|
| And one of the big advantages for me is that I get to
| leverage Rust's excellent low-level capabilities e.g.
| cross platform SIMD support, io_uring with minimal
| investment.
| artursapek wrote:
| On the bright side, they could still switch to using a
| proper pure Rust UI library like iced.
| threeseed wrote:
| Their documentation [1] is completely empty.
|
| I do applaud anyone that tackles the challenge of
| building a proper native cross-platform UI.
|
| It is one of the ultimate goals in software so wish them
| all the best.
|
| [1] https://book.iced.rs
| troupo wrote:
| > t is extremely fast and efficient so apart from UI
| controls not looking the same it will be on par with a
| native app.
|
| It uses system-provided WebView (WebKit on MacOS and
| Linux, and Edge on Windows) to display the UI shell, so
| the UI portion will be just as slow as any Electron app.
| threeseed wrote:
| Sure but most of the issues with Electron apps aren't to
| do with the web layer.
|
| It's the fact that the app is so slow to launch, consumes
| ridiculous amount of resources, does not take advantage
| of the hardware, is unstable etc. And then when you're
| using the app all of the interactions are slow because
| NodeJS's concurrency is so poor.
|
| Rust and Tauri fixes all of those. It's not perfect but
| for a cross-platform app development library I've not
| seen anything better. Happy to be enlightened with
| alternatives.
| troupo wrote:
| > It's the fact that the app is so slow to launch,
| consumes ridiculous amount of resources, does not take
| advantage of the hardware, is unstable etc.
|
| You've just described almost any web-based UI ;)
|
| > And then when you're using the app all of the
| interactions are slow because NodeJS's concurrency is so
| poor.
|
| Most of the slow interactions come from the web-based UI.
| I mean, Slack needs 17% CPU to draw an animated emoji.
| And it's already running in a hyper optimised Chrome:
| https://twitter.com/dmitriid/status/1486364312910368769
|
| > Happy to be enlightened with alternatives.
|
| Qt :)
| shubhamkrm wrote:
| > Qt
|
| Unfortunately, it's licensing is not suitable for
| everyone.
| hobofan wrote:
| > so the UI portion will be just as slow as any Electron
| app
|
| Or as fast as any website built with a pinch of care to
| performance.
| jamiepine wrote:
| Hey thanks for trying Spacedrive! The bug you're experiencing
| is known when browsing _before_ adding a "Location". We index
| Locations ahead of time to generate a cache that makes browsing
| super fast, Spacedrive is, contrary to some replies here,
| designed for big data, we cache and virtualize everything.
|
| Next update we'll fix the bug browsing non-locations, as those
| who open the app tend to try browsing first, before adding as a
| location it seems. It's alpha software so I hope you give us
| time to iron it all out!
| Rodeoclash wrote:
| A lot of bitter people in this sub thread. I for one think
| what you're doing looks amazing and once polished, will use
| it.
|
| Likewise if you decide to charge for some parts of the tool
| then you're more than welcome to.
|
| Ignore the haters.
| troupo wrote:
| Honestly, you can't call yourself a "file explorer" if you
| fail the basic task of exploring files without an additional
| step of "adding a location" (wat?)
|
| Also, judging from the GitHub description, it's not a file
| explorer. It's a slightly extended Dropbox:
|
| --- start quote ---
|
| From cloud services to offline hard drives, Spacedrive
| combines the storage capacity and processing power of your
| devices into one personal distributed cloud, that is both
| secure and intuitive to use.
|
| --- end quote ---
| jamiepine wrote:
| We're early alpha, our product is free and open source
|
| At the end of the day, it is an amazing experience simply
| just to search and organize files from not just devices,
| but disconnected drives. Search is lightning fast, the UI
| is clean and you own all the data, given its local first
| and peer-to-peer.
|
| Hate it if you must, but we're super passionate about it
| and are ruthlessly working to reach full stability across
| all platforms.
| threeseed wrote:
| > Hate it if you must
|
| I don't think many people on here actually understand it.
|
| Comparison table on your website showing what makes it
| different to Dropbox etc. would help.
| Ilnsk wrote:
| Free and open source until you have enough users to start
| locking off premium features and charging for a
| subscription lol.
| pietro72ohboy wrote:
| FOSS does not mean free of charge. They're not obliged to
| write Free Software AND give it you for free.
| unrealhoang wrote:
| how is that bad? You still have all the features until
| the opensource version and can fork it to your liking,
| no?
| devmor wrote:
| You are definitely suffering from miscommunication here.
| Calling it a file explorer is a bit misleading. I think
| what your project aims to be is _really_ cool and very
| useful, but a file explorer is a secondary trait to what
| it actually is.
| wetpaws wrote:
| [dead]
| PurpleRamen wrote:
| The explanations tell's me it's loading and interacting
| with remote file systems, not hosting them on their own.
| Which makes it different from dropbox&co., and a file
| explorer.
| meatjuice wrote:
| I've been following the project for a long time but we still need
| to package the software by ourselves.
| tanaylakhani wrote:
| That's a really neat product. Starred it.
| smcleod wrote:
| It's a neat idea with potential - but why the need for a login?
| That makes it feel like my files are now someone else's.
| jmbwell wrote:
| A searchable, browseable meta-index of all my disparate cloud and
| local, mounted and unmounted file repositories is certainly
| interesting and has been a bit of a holy grail for some time.
|
| Digital Asset Management is nothing new, but it is not a category
| currently flush with options. Things like Portfolio and <waves
| hands> Adobe's tangle of things offer a lot of this, with less
| emphasis on cloud repositories and more emphasis on workflow and
| metadata.
|
| These days I would have to consider yet another cloud-dependent
| service very carefully. Self-hosted/on-premises could be an
| absolute requirement, considering the potential sensitivity of
| "all files, including local and offline." If accounts are
| required, I would want integration with existing identity
| management through OIDC or SAML (which, you know, does what this
| does but for accounts). I would also be looking at continuity
| facilities... if I build workflows around this and it becomes an
| essential single pane of glass over all my files, I'll want to be
| confident in its availability.
|
| Keep at it. Nobody has solved all this yet. Good luck!
| unixhero wrote:
| I love the name.
| nidnogg wrote:
| I've been keeping tabs on this for quite a while. Some feedback:
|
| - Indexing one of my localdev directories has taken a robust 35+
| minutes so far, and I will likely not wait until the end of it
|
| - Like others have commented, latency is an issue (macOS M1
| 14inch base model). I've added a location and even there it
| sometimes takes 2-4 seconds after opening a folder to see any
| files
|
| - Am I missing something or are there no tabs yet?
|
| - Extremely lean (too much) in the ways of file sorting and
| grouping (non-existent), although I wager this will be worked
| upon during development
|
| - It does feel like I have to do a lot of work to get to sensible
| indexing (add lots of locations by hand, and so forth)
|
| - I know it's local first, but the way telemetry and login work
| really does not sit right with me.
|
| Overall I'm almost sure it's not a fit for me, as interacting
| with it was a bit disappointing, but I can see an audience and
| there's still ways to go. It looks really good. Best of luck!
| nidnogg wrote:
| Update on this: I actually forgot it on and it was still
| indexing stuff on that same localdev folder for over 4 hours.
| :(
| netbioserror wrote:
| File explorers really should be one of the simplest tools
| available in a given desktop environment. Really, there are many
| tools getting the Electron treatment which should be vastly
| simpler than this insane upward ratchet of complexity JavaScript
| dominance has introduced into the equation.
| miduil wrote:
| Super nice someone working through this, as it's the perfect
| target for Tauri, the motivation inside the GitHub makes it an
| exciting project that goes beyond just a regular file browser.
|
| Since it has some glorified web app functionality, a non-tauri
| web demo with a remote `core` daemon would be super nice.
| woodylondon wrote:
| The old age problem of having an open project where people don't
| understand what an alpha is.
|
| You give this out to the world for feedback and people moan its
| not working.
|
| I am old geek and back in the day you knew an Alpha was just for
| the playground to kick around - most likely will crash, worse
| case will destroy you PC but you have a play / provide some
| feedback and wait for the next release.
|
| A lot of other projects do everything in the dark and do a big ta
| da at the end - and missed the opportunity for the community of
| "alpha" or "beta" testers to provide some feedback along the way.
|
| Keep going - its added to my list to take look once in beta as I
| prefer to play in that playground rather than the alpha one these
| days.
|
| I like the idea!
| troupo wrote:
| It's the old-age disconnect between the marketing, the claims
| and the actual functionality.
|
| For example, the title _claims_ that it 's a file explorer.
| However, someone in the comments shows that it fails at
| actually exploring files. Something which even an alpha project
| would not fail to do _considering the claim_.
|
| Only when you read through the marketing copy and the comments,
| you realise that it's a hybrid cloud/local/cross-device Dropbox
| that creates a view of your files across systems/locations, and
| only once it's done that, only then can it do the actual file
| exploring. At least for now.
| voshond wrote:
| I was actually thinking about exactly this when I read the
| headline. Reading this is disappointing
| placesalt wrote:
| _age old_
| swagempire wrote:
| Well, English evolves...
| troupo wrote:
| I personally prefer "age old". I was going for the same
| opening statement as the original comment :)
| PH95VuimJjqBqy wrote:
| you're not wrong but perhaps being a bit unfair.
|
| the project page has that front and center, it's only really
| the submission title that's implying otherwise.
| lionkor wrote:
| Why is this written in React? I understand Rust doesn't have any
| GUI frameworks (like Qt), but is this the way, then? Is it an
| adversity to learning something new?
|
| You can reasonably write a C++ app or with Qt and write your GUI
| stuff in QML, and even plug in Lua, Python, or JavaScript as a
| scripting language. Yes, thats work.
|
| Using a browser to render is just an easier version of using a
| GPU API like OpenGL to build your GUI. Your OS comes with gui
| stuff, use it.
|
| Other than that, cool enough, though something like pcmanfm
| support adding remote locations as well...?
|
| Another question, why Prisma?
| jenadine wrote:
| > Rust doesn't have any GUI frameworks (like Qt)
|
| And Slint? And egui? And the Qt bindings crates?
|
| You can say that they aren't as mature as Qt, but they are
| often good enough compared to something that runs in a browser.
| threeseed wrote:
| > but they are often good enough compared to something that
| runs in a browser
|
| You can't make an app that looks even half as good as
| Spacedrive using QT, egui etc.
| jenadine wrote:
| I don't see why not. For example Rust and Qt:
| https://gyroflow.xyz/
| omneity wrote:
| This is an incredible piece of software. Thank you for
| sharing it!
| nidnogg wrote:
| That really doesn't look half as good as Spacedrive or
| any other one of the hundreds of browser based UIs we see
| thrown around. Just ok.
| xigoi wrote:
| Do any of those natively support mobile?
| lnxg33k1 wrote:
| Try to do something with the qt rust binding please
| hobofan wrote:
| > I understand Rust doesn't have any GUI frameworks (like Qt),
| but is this the way, then?
|
| Yes. If you want to build a cross-platform desktop app with
| Rust, Tauri + React would also be me recommendation right now.
|
| Tauri makes it quite easy to drop down to Rust if you need to
| (for high-performance operations and everything interfacing
| with the OS), and it also comes with pre-built packaging for
| the main different platforms. With React you are able to
| leverage a great ecosystem that has existing UI components for
| many things (unlike most native Rust GUI frameworks). It also
| allows you to reuse you frontend engineers and all their
| expertise when it comes to web technologies (and working with
| designers).
| lionkor wrote:
| Thats a great overview, thanks. That actually does answer
| most of my question.
| kwanbix wrote:
| I am a heavy user to Total Commander on Windows, and Double
| Commander everywhere else. I highly recommend both.
| kwhitefoot wrote:
| I downloaded the .deb file and installed on Linux Mint 21.1 Vera
| on a Lenovo T460s
|
| $ spacedrive spacedrive: error while loading shared libraries:
| libssl.so.1.1: cannot open shared object file: No such file or
| directory
| hobofan wrote:
| Already opened a bug report for that:
| https://github.com/spacedriveapp/spacedrive/issues/1481
| piyush_soni wrote:
| Ok, I don't know if I'm doing it correctly, but there is no way
| to type some letters to jump to the folder starting with that
| name right? Also, no Cut/Copy/Paste/Delete yet I guess. Also, the
| one reason I run away from Finder on macOS is that it has no way
| to set 'Enter' to open or 'Delete' to delete files, and refuses
| to simply add a 'Cut' and paste option for files and folders (I
| know how to 'Move' after 'copying', but that's not the point, the
| point is that it's just stupid). Please make sure you don't do
| those mistakes. Keep whatever defaults you want, but at least
| have an option to enable 'Cut', 'Open', and 'Delete' with their
| expected buttons.
| wongarsu wrote:
| I like the idea. The vision is similar to Window's Explorer:
| seamless integration between offline files and online resources
| like Google Drive, Dropbox, OneDrive, Webdav, Samba, etc; fast,
| cached thumbnails; an indexer for fast search; encryption, backup
| etc. Of course in Windows Explorer all those features suck to
| varying degrees, some so hard they might as well not exist. So
| seeing an alternative implementation is nice, especially if it
| tries to take all these concepts even further. Most other file
| explorers stop far short of that vision.
| hobofan wrote:
| It was kind of inevitable that after VC-funded terminals, mail
| clients, launchers sooner or later there would be file explorer.
|
| As someone on Linux (popOS), I also gladly welcome it, as even
| the best file explorer I know (nemo) could use niceties that you
| find on Windows or macOS.
|
| I'm highly skeptical of the economics of it though. The only way
| I would see it working out, if their planned "sync" product would
| be able to overcome the entrenchment of iCloud/OneDrive/Dropbox,
| which seems like a tall order. As a user I'd pay ~$50/year, but
| that would take a lot of customers to sustain even the current
| team size.
| PurpleRamen wrote:
| What do you mean? Commercial file mangers exist for decades
| now. They are a bit out of style with everything being open
| source, but the old guard is still around on Windows & MacOS,
| and new fledglings appear on mobile regularly.
| kwhitefoot wrote:
| If you only want sync then Syncthing [1] is better than all of
| those and doesn't put you data in the cloud.
|
| [1] https://syncthing.net/
| hobofan wrote:
| The cloud storage is the part I'm not interested in. I
| already use Syncthing, and it fills that need really well
| (tough with a UX so meh that I'd be hesitant to hand it to
| non-developers). I'm interested in e.g. tagging of files and
| a good GUI, and Syncthing doesn't really do any of that
| (unless I've missed something).
| kwhitefoot wrote:
| What I would love to see is a UI on top of Syncthing that
| would allow for remote management so that it would be
| easier to add and remove folders without having to visit
| the remote devices physically.
|
| I suppose I really should just get on and do something
| myself. :-(
| hobofan wrote:
| I think for there are two already okay options. As
| Syncthings UI is already in the browser, one would be to
| just host that page in a way that it's remotely
| accessible (e.g. in you VPN, where I can highly recommend
| Tailscale). The other would be to use the option that
| Syncthing has built in to auto-accept folder invites from
| certain devices (that's what I have set up on my always-
| on server so I don't have to SSH into it every time).
| MacsHeadroom wrote:
| Remote management sounds like a security nightmare.
| graemep wrote:
| What niceties? I cannot remember when i last used a MacOS file
| manager, but the default one in Windows felt worse than the
| Linux ones.
|
| Have you tried Dolphin on Linux?
|
| These days I mostly use broot.
| OJFord wrote:
| I do miss the preview sidebar (bigger than thumbnail, renders
| and paginates PDFs even) and spacebar to pop a lightweight
| Preview.app modal window from when I used macOS.
| sherr wrote:
| "It was kind of inevitable that after VC-funded terminals, mail
| clients, launchers sooner or later there would be file
| explorer."
|
| Well, Nautilus [1] (nw "Gnome Files" apparently) was created
| for Gnome quite a long time ago now. The company was Eazel and
| included some ex-Apple luminaries. So money spent on file
| managing is nothing new.
|
| [1] https://en.wikipedia.org/wiki/GNOME_Files
| sanitycheck wrote:
| OK, that explains why I have so many problems with the
| Nautilus UI! I switched to Thunar but it's missing some nice-
| to-haves. I'll have to check Nemo.
|
| Regarding Spacedrive... Seems a solid idea but I think their
| UI goals (looks fancy) might not be aligned with my
| preferences (minimal, fast, high functionality, no jank).
| oblio wrote:
| > OK, that explains why I have so many problems with the
| Nautilus UI!
|
| Eazel was 22 years ago, I highly doubt your problems with
| Nautilus have anything to do with them.
| darkest_ruby wrote:
| Can someone describe a proper usecase for this software? I
| couldn't understand from the readme
| taskylizard wrote:
| As a centralized file manager for all your dropbox and google
| drive files? Yes, otherwise nothing really special.
| filchermcurr wrote:
| Essentially it's an aggregator of file metadata from multiple
| sources. Accessing the local database can be a lot faster than
| accessing the data where it actually lives. It also allows for
| offline access if the device containing the files is
| temporarily removed. (Well, by access I mean previews and
| metadata.)
|
| For example, I have a gigabit LAN with a Synology NAS, a server
| with a bunch of hard drives, and various networked machines.
| Gigabit LAN is pretty slow. Getting image previews of RAW
| photos on the NAS is insanely slow and frustrating. With
| something like SpaceDrive, you have basically instantaneous
| access to those previews, metadata, and Everything-like (the
| Windows application) search capabilities.
|
| I'm really excited about it! I have files strewn about in so
| many places. Having access to them from a central location,
| with a single interface, not relying on a slow network, is
| really great. I might even go crazy and start to organize
| things with tags.
| atoav wrote:
| What do you mean? It is a file manager. You use it to manage,
| explore, order your files. It could replace Explorer on
| Windows, Finder on MacOS or your file manager of choice on
| Linux.
|
| Apparently they also have some special use cases in mind (if
| you read the roadmap) like multimedia conversion using ffmpeg
| woth the ability to offload the processing onto multiple
| computers.
| troupo wrote:
| > What do you mean? It is a file manager. You use it to
| manage, explore, order your files. It could replace Explorer
| on Windows, Finder on MacOS or your file manager of choice on
| Linux.
|
| It's not. Read their description more carefully: it's a
| Dropbox with slightly extended functionality.
| PurpleRamen wrote:
| Dropbox is a storage with sync-client, not a file manager
| (even though it does have a filemanager-view). This app is
| working on top of storage-services, but it seems not to be
| like them.
| lbltavares wrote:
| spacedrive-bin on aur is exactly 69.69MB
| ehutch79 wrote:
| Does this intentionally have almost the same icon as orbstack?
| Hamcha wrote:
| I don't wanna rag on this project and all the bugs since it's
| clearly in its super early days, but I keep wondering if there's
| something I'm missing:
|
| Why no miller columns? Not a question just to Spacedrive but
| really any file manager, it's the main reason I pay and use
| OneCommander and it's surprising to me how few of them actually
| implement it, everything else feels a downgrade to me.
| _1tan wrote:
| Finally, congrats on launching!
| reacharavindh wrote:
| I remember looking at it a good long time ago. They didn't have
| release packages for me to play with so I told myself that I'd
| check it out later when they are ready. It looks like they
| released an alpha version an hour ago - hence this is on HN
| again.
|
| It is a welcome concept. We have blurred the lines between
| strictly local files and all the cloud storage options these
| days. I personally maintain those boundaries and almost never
| mount cloud storage on my Mac, but my wife(as an academic) deals
| with Dropbox,iCloud drive, Google Drive and whatever Microsoft
| calls theirs, because the people she works with shares files
| through them and collaborate with reviews and such. If a solution
| like this can mask the vendor specific connection hiccups and
| quirks and provide a transparent file system that appears local
| but may be backed by $x cloud storage, that would be a nice boost
| to her workflow.
|
| The key is the usability of such a tool. If the latencies are so
| high that it feels slower than Finder, then its chances are slim.
| moelf wrote:
| The first screen after "welcome" is a login
|
| why do I want to login a file explorer man this timeline is weird
| koolba wrote:
| > why do I want to login a file explorer man this timeline is
| weird
|
| From the first line of the link:
|
| >> Spacedrive is an open source cross-platform file manager,
| powered by a virtual distributed filesystem (VDFS) written in
| Rust.
|
| You log in because it's a remote file system. Think Dropbox,
| not file explorer.
| mcosta wrote:
| Yeah, there. It says "file manager"
| awegio wrote:
| In their FAQ
|
| > How does it work?
|
| > Using a "Virtual Distributed Filesystem" (VDFS), in other
| words; a decentralized database that emulates a filesystem.
| It indexes hardware filesystems to create a master database
| that is synchronized in realtime between your devices running
| Spacedrive.
|
| > What makes this different to Dropbox or Google Drive?
|
| > It is not a storage provider, Spacedrive is simply a
| database that exists on top of existing storage layers, from
| cloud services like Dropbox, Google Drive and iCloud to
| physical devices and external drives you already own. It
| doesn't provide you more storage, rather a supercharged view
| of your existing storage.
|
| So more like Syncthing? Or rather Windows File Sharing/Samba?
| I don't really get it
| PurpleRamen wrote:
| That explanations read like it's taking in any kind of file
| system, local or remote, and combines them into one unified
| file system. Not really new, but most other file managers
| focus on the popular storage-services (Dropbox, Google
| Drive, OneDrive, samba, ftp), and are not open source. If
| you can easily create plugins for any remote storage, not
| just the traditional file storages, or even make up your
| own, then it could become something promising.
| ysw0145 wrote:
| A cross platform file explorer that has a nice UI and plugins is
| awesome. Many people have more 2 devices runing with different
| OS. But still, Web techs maybe not a good fit for system tools,
| for its heavy stack.
___________________________________________________________________
(page generated 2023-10-11 16:00 UTC)