Setting up an enriched, system-wide prompt again raised the question where to put the definition code. Spreading the snippet all over the home-located profile-(.bash_profile) and resource(.bashrc)-files is a bad idea, tedious to maintain, you know, don’t ever think about it.
Changing the global profile- and resource-files (/etc/profile , /etc/bashrc) won’t be of any much more brain either, since yet another system update may cause conflicts with the maintainers version. Just reading along the web, I found that there is some mechanism integrated with /etc/profile to source homebrewed definitions from a file within /etc/profile.d . Great, this is what I want, but, as far as I remember correctly, a profile will only be sourced once, upon login, in a login shell, right?!
Oohhm, still can’t recite that poem on command. On login, we source the environment (profile). We won’t do that for sub-shells because the environment will be derived. However, since a login shell is also an interactive shell usually, we still addionally source the aliase- und function-resources as well… And so on and forth in bare theory, which has been depicted nicely in man bash, in the invocation section in particular. Read this now for reference!
On the other hand, living system may not stay with the initial ideas very long, in practice a question may have a multiple of answers (or the other way round). So I parsed and instrumented the profile- and resource-loading process to see what really happens under the bonnt. See what I’ve found.
Save the date to see my presentation about “Oracle Analytic Functions in Practice Applications” along the regular meetup of the DOAG/Oracle-community in Hamburg on Dec 4 2018. Although analytic functions is nothing really new in the Oracle world, I’m again attempting to propagate the thrilling productivity of this SQL-toolset, since practice applications are still not as dispersed as expected. To this extent, I want to stress windowing and aggregation over analytics and statistics in real world scenarios and examples. The presentation will be held in German, I suppose. Event details go here and there:
Every wiki landing page usually features a kind of overview layout to provide links to the most interesting topics or articles. This might constitute a classic table of contents, quite lengthy at times, a tag cloud of the hottest keywords (and relations, maybe), for iterative exploration, or, if you like, a dashboard of context grouped / block visualized widgets of important articles. Whatever you prefer, me, I almost always take on the dashboard approach, because it provides a great productivity in information to space ratio. Furthermore, dashboards also greatly serve the figurative memory in that one can plainly remember some article link resides in a widget up in the upper right corner of the page or yet within another widget with an outstanding background color.
However, I’m not planning to advertise dashboard / widget user interfaces here. What is to follow comprises an implementation pattern and example of setting up a simple dashboard layout in recent Confluence environments. All you need is to employ section-, column- and panel-macros in that order and hierarchy, respectively. For reference see the latest Confluence docs concerning:
I’m not very much into suse linux, only lately for a couple of times. However, I want to share these settings to be injected on each and every new system for essential readabilty of some console screens. Problem is, for some apps, midnight commander and yast so far, the default color scheme settings provide that less contrast, see below, that you’re literally guessing pixels instead of just reading text.
As given in the referenced posts, only small tweaks are actually necessary to achieve much better results, I’ll give examples as well, so go for it, don’t postpone to the next and the next and the next… login 😉
Radius search in PostgreSQL may come in employing a light and/or a much more sophisticated version. This article discusses the light one, namely the cube and the earth distance extensions, most probably sufficient for the web user’s getting here and there requirements. earth distance, depending on cube, assumes the earth to be perfectly spherical, anyone demanding a higher accuracy level, especially for the mountainous parts, may take a look at the PostGIS project.
Although radius search, the light variety, will be up fast and performing well, there may be some mantrap around, for the ones who prefer to read documentation the easy way too. First of all, PostgreSQL: Documentation: 9.1: earthdistance indicates that the point-based earth distance calculation is hard-wired to statute miles in units. You may use this circumstance to your advantage, like datachomp did in Radius Queries in Postgres, as long as you know what you’re doing. Second to that, taking on the alternate cube-based earth distance calculation, the earth_box function, accepting a lat/long and a radius on input, may return locations farther than the actual radius given (documented alike). This is because earth_box, as the name implies, still handles a box geometry on the idealized sphere (and not some higher order circle surface). But more on that below.