To watch the “IT Crowd“, this alone would be it:
I wouldn’t mind the “People Pane”, except that in our organization is shows nothing useful. Moreover for a reason I cannot fathom, it always gets opened up, taking enormous reading real estate. So from this (Outlook 2010 at least):
Click the “View” tab:
Select “People Pane” and set it to “Off”:
Same two steps work on Outlook 2013.
I keep getting them from very smart, very security conscious people. However, to make my point:
I love what they offer but…
Some do offer a preview, but users aren’t used to seeing that and unfortunately won’t care (ie: they are so used to getting them without preview, they won’t expect it or demand it).
As a coworker pointed out, there are potentially plugins for Firefox etc. (I couldn’t find one that worked) or you can use a site like this:
It’s already come in handy for me a few times.
I have to say even as a relative newcomer to Python, I find a fair bit of truth in this:
Working in a non-homogenous (that is, heterogeneous OS) environment where Python 2.x vs. Python 3.x is not guaranteed, the lack of backwards (or forwards) compatibility is problematic. If nothing else it erodes trust in the language – will Python 4.x inflict similar pain? Should I be looking to yet another language that isn’t so willing to shoot itself in the foot?
Not all environments, even if they should be, are Puppet-perfect and portability is still a major requirement.
This is to some extent what happens when languages become religion and “purity” to ideological dogma becomes more important than functionality. While I have to praise the desire for perfection, sometimes the perfect really is the enemy of the good.
All that said, as Python becomes more “native” to my mentality, maybe I’ll change my mind. I’ve found the transition to other languages, OSes, etc. offensive to my sensibilities only to later become “assimilated to the Borg” as it were.
Most LDAP servers can be set to return an unlimited number of entries on an LDAP search, however depending on the size of the LDAP database/directory this can possibly exceed your memory. Moreover if you want to write portable code, you probably should not depend on the LDAP server being able to return unlimited entries. For instance, AD’s LDAP generally defaults to 1,000 entries maximum.
Because using LDAP paging isn’t very difficult there’s not a lot of reason to not use it. Adding paging only marginally reduces performance, while certainly putting less stress on the LDAP server(s). Personally I recommend you use it on a general basis, even where not strictly necessary.
Python’s LDAP supports paging, though it isn’t well documented. I found two examples this one and this one. Both had their pluses, but neither explained what was going on too much. I melded them together, added comments, and streamlined a bit. Hopefully this will help you get the mojo…
As a final note, one of the documents I found said the paged controls did not work with OpenLDAP. That’s not what I found – pretty much the exact code above worked without issue with OpenLDAP.
A GitHub “Gist” for the above can be found here.
Mostly for my own edification – use “ethtool”, eg:
You’ll note two important details about this output:
Anyway, simple command, but sometimes you forget them.
Not pretty, but gets you there:
If Firefox is running you may have to copy the “places.sqlite” to a new file then run the “sqlite3″ against it. You can’t dump it while Firefox is running because it locks the database.
Since it’s SQL there are fancier ways of pulling the actual tables, but for a quick script, this will do.
Note if you’re after the time that a URL was accessed (I was), it seems to be the last field in the “VALUES”. It is is in microseconds since 1970. In that case, this little Perl snippet should get you the actual time:
where “HISTORYTIME” is replaced by the time printed in the SQL dump (eg: a big arse number like “1373383738987790”).
Applies to IT as well:
- Commander Chris Hadfield, Canadian Astronaut