We are a small data consultancy, so we use other/more diverse things for customers, but our internal stack is fairly simple:
Hubspot/Jira/G Suite → (Python) → PostgreSQL → (SQL) → Tableau
Since we are Tableau partners, we have a bunch of internal licences either way. We host Tableau Server, ETL, and PostgreSQL ourselves, all on Centos cloud servers.
> It also doesn't look like a comfortable place for bikes. In fact, where are bikes even supposed to go on this street?
Another issue for cyclists is the permanent danger of getting your wheels in the rails, which means you are likely to either come to a sudden stop or, worse, come off your bike. There were experiments with "self-sealing" tram tracks that would lessen these risks, but no real solution exists quite yet, as far as I am aware.
I'm not a big fan of putting my password (encrypted or not) somewhere where I don't have control. Therefore, I am using Passbolt[0] at work, since that gets me a browser addon plus web ui, while it also allows me to host it myself, i.e. where I can physically check what ends up written where in the database. Passbolt is open-source, encryption and sharing is GnuPG-based, and they have paid plans available.
"This guy" was Niklas Luhmann, by the way, an influential (and regularly misunderstood) German sociologist and social theorist, heavily inspired by Parsons and cybernetics.
I think Tableau Server works better on Linux, where upgrades etc. are also somewhat less painful and require less downtime.
That said, it baffles me why I have to restart Tableau Server 3 or 4 times during installation, and why I have to restart it for trivial changes more generally. For a piece of software that specifically ships with a cluster controller and full-blown zookeeper, somehow their engineers (or "engineers", as I sometimes get the impression) manage to make things that should be trivially solvable with reloads, partial restarts or spawning new workers (e.g. SSL certificates for the built-in Apache webserver) require a complete restart of the whole node.
edit: Regarding Power BI -- I feel that Tableau Server is (for better or worse) one of the killer features for many enterprise customers, because it means all of your data can remain within your own infrastructure and does not have to rely on external cloud providers. If that is not a requirement in your organisation, Power BI might make sense depending on your overall IT landscape, as well as your users' specific needs. On the other hand, if your organisation requires hosting things yourself, I guess it doesn't matter how miserable the experience is for you as an administrator. That's basically Tableau Server in a nutshell.
Oh hey, maybe this will mean somebody at Tableau has to start to give a damn about enterprise features, such as a way to do product activation and registration that doesn't fail completely in non-persistent virtual desktop environments.
Or Tableau can continue to pretend that this isn't a real issue and stonewall customers and partners alike.
I think the actual visualisation part is neat, and better than many competitors, but many of the server-side parts are various levels of disastrous (as is their support), and their "data preparation" tool needs some serious improvements to be borderline useable.
15+ billion seems like a lot to me given how Tableau interacts with customers and partners alike, especially seeing how they are activelly alienating existing enterprise customers, all in favour of new sales, but perhaps something will change for the better here.
Note that a data lake does not necessarily replace the data warehouse, but rather often complements it. As such, you store your raw data from various sources in a centralised data store (Hadoop-like, NoSQL, etc.). From there, you prune, clean, select, and potentially aggregate data that you would like to provide in a quality-controlled way to your business users, in a data warehouse. This data warehouse most often will be a more traditional relational data store (usually some flavour of SQL database), which allows users to select data from a curated, pre-selected slice of the overall data stored in the data lake, and which enables easier integration with common reporting tools, whether more traditional standard reporting tools or self-service BI tools.
Kyle Rankin gave a (very good) keynote at FOSDEM 2019 about this topic, harkening back to the Unix wars, Sun etc. He has some really nice one-liners. Video is available here:
There is a "suggestion" somewhere that asked them to implement service accounts for API access. They essentially replied with "this is a good idea and we should do this". That post was from 2012 or so, and we still don't have service accounts.
openSUSE still "uses" YaST, as in, if you choose to change something via YaST, it will happily do so. You can also simply install/uninstall various components. It also happily integrates with changes made elsewhere (e.g. the "Firewall"-module wraps around firewalld nowadays, which you can influence either via YaST or firewall-cmd etc.).
I sometimes use the Package Management part of it, since searching for something is sometimes quite nice in it. That said, I don't use it for installing software or doing updates etc., so you can absolutely use e.g. zypper & YaST side-by-side.
Correct. I'd say openSUSE is more akin to Fedora in that context as both base and development distribution for SLES, much like Fedora is for RHEL (which in turn then "becomes" CentOS).
It is, or rather it would be, if more cloud providers etc. bothered to provide images.
Indeed, I think that RedHat & SuSe are very similar in their ideas and in their usage patterns. Both contribute quite a bit to upstream projects (there is a lot of work being done on CNCF-stuff in both places, both are RPM-based and both offer a number of different "tracks" depending on your needs). openSUSE also has been very good at keeping up with things that are in development.
On the desktop-side, I think openSUSE is actually nicer, since they officially support a myriad of DEs (notably both Gnome and KDE).
For what it's worth, I use (and have been) using openSUSE both on my work laptop and my private laptop as my daily driver, and I use openSUSE on various private projects as a server OS, though I'm using CentOS 7 at work for all our servers because some of the software we use only supports Ubuntu LTS and CentOS (because the vendor is incapable of building non-idiotic RPMs/DEBs...).
Ugh, just saw your comment now. I wrote a bit more in a sibling comment about openSUSE. For some reason, people seem to either sneer at openSUSE (probably people who go way back?) or are simply unaware of anything it does and/or its existence. I briefly asked the people at the openSUSE stand at FOSDEM 2019 why they don't advertise things such as OBS more, and the answer suggested that some people basically don't see a point in it? It's a pity.
openSUSE uses the Open Build Service[0] to build, well, openSUSE. OBS also supports other distributions etc., but it makes it fairly easy to put up a package.[1]
For RPM-based distros (e.g. openSUSE), you write a .spec-file, check it in via OBS's version control alongside your sources, and off you go. OBS builds the package (and pulls in dependencies as needed etc.) and publishes the result as a repository with GPG keys and all the jazz, which you can just add to your own distro, and which is openly visible, so everybody else can use your package(s), too.
OBS also supports forking existing packages, and you can merge them back together, which means you can fix something in an existing package (whether a distro-package or something somebody else put up) and if they accept the changes, congratulations, you just fixed something in the distribution.
This means a lot of building, compilation, versioning etc. is out in the open, and you always have the sources available on top of it.
As an aside: I doubt people will "flock" to openSUSE, since many people sneer at them for no good reason (YaST, still?!), but they do a lot of good work, are good upstream contributors (like RedHat and unlike Ubuntu) and some of the tooling is absolutely amazing, except that nobody really knows about it.
Podman doesn't have a daemon like Docker does. It also more tightly integrates with buildah, which the article doesn't expand on. Have a look at this (very brief) overview to get a bit better idea of their relationship: https://github.com/containers/buildah#buildah-and-podman-rel...
Podman also uses the same notion of pods, and it doesn't support docker-compose syntax/files, because RedHat strongly believes that Kubernetes has already won. Basically, podman/podlib allow you an easy migration path from your local computer to a k8s cluster, with the same images and same concepts. Have a look here: https://github.com/containers/buildah#buildah-and-podman-rel...
There is a video from th 35C3 on that website which gives a primer to what it is they mean, and where he also explains that "operating system" is to be understood as a metaphor for the patterns, habits and reflexes that guide our own (human!) actions.
Essentially, this seems like it combines ideas from Tai Chi, Aikido, mindfulness and a bunch of other sources to reflect upon the automatisms we all necessarily develop and have developed.
It sounds a bit esoteric, but not more so than other martial arts, which also similarly suggest to help us develop insights that apply beyond the martial art itself.
I think the UK examples are quite good though. They show that you don't even have to change language to run into massive problems with addresses. More than being anglo-centric, the issue of addresses is often even more specific, i.e. US specific.
Japan et. al. add another layer of complexity, other text encodings etc. etc., but even in the seemingly simple case of English being used, it's not quite as simple as many forms make it out to be.
Hubspot/Jira/G Suite → (Python) → PostgreSQL → (SQL) → Tableau
Since we are Tableau partners, we have a bunch of internal licences either way. We host Tableau Server, ETL, and PostgreSQL ourselves, all on Centos cloud servers.