France and Germany, in joint collaboration, have developed a Google Docs alternative - and its awesome! (Netherlands are currently onboarded)
-
Is there an open source implementation of kDrive as well?
It is already open-source. All of the source code is on their github and, for docs, they use an implementation of onlyoffice very similar to the one in Nextcloud
-
I would assume (without having looked at the codebase) that if they use minio they are, by default, not reliant on AWS.
Minio is its own S3 implementation which can be self-hosted.
S3, being an AWS protocol originally has
AWSenvironment variables all over the place but that does not necessarily mean a reliance on the service. Rather, they rely on the protocol and you bring your own S3 endpoint I would assume. be that minio, hetzner or what have you.Thanks for the clarification, that makes sense, closing the issue then.
-
I thought that MinIO is a Open-Source S3 implementation, which you can just install on your own system. S3 is a "protocol" here IIUC.
Is your complaint that they are using the S3 protocol, because it was invented and is controlled by AWS?
Or that some services might use it without MinIO, directly on AWS?
Seems I misunderstood, if it's solely the branding (of that implementation) then it's fine. I thought they relied on AWS itself.
-
It is already open-source. All of the source code is on their github and, for docs, they use an implementation of onlyoffice very similar to the one in Nextcloud
Oh that is good to know then. At a cursory glance I only saw the clients' software available as github repositories and the German and French wikipedia pages called it a proprietary service.
-
Honestly, a lot of the time I don't understand why a lot of businesses use k8s.
At my company especially, we know almost exactly what our traffic will look like from 9am-5pm. We don't really need flexible scaling, yet we still use it because the technology is hyped. Similar to cloud, we certainly don't need to be spending as much as we do, but since everyone else is on or migrating to the cloud, we are as well.
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".
-
This post did not contain any content.
-
it’s easier to develop for just the browser than for Mac, Windows, and Linux.
They also work on android and IOS. You are also not dependent on the different toolkits. Also it is so much more performant.
I’ve never found them to be more performant, and i can’t understand the logic of why a programme running inside another programme would be more performant except in comparison to unoptimised alternatives.
I’ve never used a web app that i thought was better than a local app. But i definitely understand why developers prefer them.
-
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
-
System shared this topic on
-
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.
