France and Germany, in joint collaboration, have developed a Google Docs alternative - and its awesome! (Netherlands are currently onboarded)
-
Wait LibreOffice has a cloud?
-
We already have kDrive you get 1TB storage for only 2€ a month, it's based in Switzerland
Where are you getting that pricing?
-
Where are you getting that pricing?
https://www.infomaniak.com/en/ksuite/myksuite
1.90€ per month for 1TB
-
It's pretty easy if you use NextCloud with the AIO image, but if you're doing anything fancier than that, strap in because there aren't many decent tutorials.
strap in because there aren’t many decent tutorials
Yeah I've noticed. It was rough figuring out how to set up a reverse proxy with SSL too. Self-hosting is a process.
-
I won't argue with the ups and downs of each technos, but I recently looked into docker swarms and it was all I expected kubernetes to be, without the hassle. And I could also get a full cluster with services restored from scratch in 30s. But I am obviously biased towards it, too
Did not realize swarm was still a thing, not trying to be offensive here.
My best find was using traefik as a reverse proxy in docker (compose). It is easily configurable through container labels and pulls resource definitions straight from docker. It is awesome!
-
and why so?
Living under a rock eh?
-
which is fine if you deny network connections for it with a per-process firewall. but with a webapp you can never be sure that they won't snatch your documents.
Depends, if it is open source then you just host it yourself for your organisation.
-
This post did not contain any content.
Now explain this to EU based corporations, which in my opinion needs to be the focus on making the change. They drive the economy. All major assets in software income are being routed to American firms through their licenses.
-
Yeah I thought this was open to the general public, I didn't realize that it was not
I'm sure it will be. This is a government funded thing in the early stages so I can see how they would set it up that way.
-
There's onlyoffice for cloud based office
-
-
The "problem" with k8s is not that it's abstract-y (it's not inherently any more abstract than docker), it's that it's very complex and enterprise-y.
The need for such a complex orchestration layer is not necessarily immediately obvious, until you've worked on a complex infra setup that wasn't deployed with kubernetes. Believe me when you've seen the depths of hell that are hundreds of separately configured customer setups using thousands of lines of ansible playbooks, all using ad-hoc systems for creating containers/VMs, with even more ad-hoc and hacked together development and staging environments, suddenly k8s starts looking very appetizing. Instead of an abominable spaghetti of bash scripts, playbooks, and random documentation, one common (albeit complex) set of tools understood by every professional which manages your application deployment & configuration, redundancy, software upgrades, firewall configs, etc.
A small self-hosted production kubernetes cluster doesn't have to be hard to operate or significantly more expensive than bare-metal; you can buy 3U of rack space, plop in 3 semi-large servers (think 128 GB plus a few TB of SSD RAID), install rancher and longhorn, and now you've got a prod cluster large enough for nearly every workload such that if you ever need to upgrade that means you have so many customers that hiring a k8s administrator will be a no-brainer.
Or you can buy minutes from AWS because CapEx is the absolute devil and instead you pay several times as much in OpEx to make it someone else's problem. But if you're doing that then you're not comparing against "installing things the old-fashioned way".
Thanks for the response!
I personally haven't rolled a k8s or k3s cluster, so it's always felt a bit abstract to me. I probably should though, to demystify it to myself in my work environment.
Complex is definitely what I have noticed when I see my devops team PR into the ingress directories.
I guess the abstract issue I see, that ties in to the meme i shared above, is that sometimes around deploys where we get blips of 503/4's and we appear to be unable to track them down. Is it the load balancer? Ingress? Kong? The fact that there is so many layers make infra issues rough to debug
-
Note: The LibreOffice Online repository at TDF is temporarily frozen. Updates on this will be published on our blog and on our website.
yeah
-
Thanks for the response!
I personally haven't rolled a k8s or k3s cluster, so it's always felt a bit abstract to me. I probably should though, to demystify it to myself in my work environment.
Complex is definitely what I have noticed when I see my devops team PR into the ingress directories.
I guess the abstract issue I see, that ties in to the meme i shared above, is that sometimes around deploys where we get blips of 503/4's and we appear to be unable to track them down. Is it the load balancer? Ingress? Kong? The fact that there is so many layers make infra issues rough to debug
I mean yeah it's all very complex for sure. Managing a cluster is very involved and k8s administration is typically a completely separate role from dev/devops. I am comfortable with the idea and I still run my selfhosted setup on docker because it's easier and I have no personal use for multi-node setups.
However when you get down to it pretty much everything in k8s solves a real problem that in a "traditional" infra would require lots of ad-hoc bullshit. The ingress system of k8s is, at a high level, a standardized recreation of the typical "haproxy+nginx+ad-hoc provisioning" setup you'd find in a "classical" private cloud deployment. TLS in, send to nginx, nginx chooses a relevant healthy back-end and reverse proxies the request. K8s doesn't really do anything crazy complex, the complexity is just inherent to having a many-to-many mapping of HTTP requests while optionally supporting multi-zone setups with local affinity and lifecycle management/awareness.
But unlike with a traditional deployment there's not a greybeard guru in the back who deployed it all and knows the ins-and-outs so it's quite common that the complexity is not understood and underappreciated by the "admins". That complexity is a blessing when you need to leverage it but a curse when you lack the expertise to understand what is happening holistically.
Kind of like a linux distro... It's amazing when it works but when libpam throws an error and you don't even know what that library is or does, well you're in for a fun evening.
-
Living under a rock eh?
I mean I didn't see any alarming need of a Google doc alternative, so I might actually be under a rock
-
So how do I use it?
Here is a get started guide -> https://github.com/suitenumerique/docs?tab=readme-ov-file#getting-started-
-
Do you have Amy sources on that
-
Onlyoffice seems a little slack on the security and updates. I saw the warnings in the desktop package, have they made sure the online offerings are secure?
what do you mean?
-
Cryptpad is French, but they are using OnlyOffice, which is Russian.
Is there any evidence of any wrongdoing or are we just considering all open source software from Russia a bad actor by default?
-
While both of those are great software. Unless I'm not aware of something they aren't cloud/network based office suites like Google docs and office 365.
It seems this is an alternative to office software where you can work simultaneously and share documents in the same cloud/network.
I don't think there is an alternative to office 365 and Google docs at this point that is open source. So this seems like a great project and I'll definitely be considering it for our company.
LibreOffice online exists. It’s not mature, but they could have invest half their time in making it so.
Only Office is natively cloud based, with an optional offline/desktop version.
Both are open source, if the concern is project governance, create a fork and rebrand.
-
Can either of those do collaborative editing? I usually think of that feature when I think of Google Docs
OnlyOffice does for sure, not sure how well it works on LibreOffice Online.