eeZi

> FreeBSD has for years had some features that are only now reaching 'mainstream' popularity

It's also lacking a bunch of features that reached "mainstream popularity" a long time ago.

Example: ASLR, the most important exploit mitigation technique

  - 2001 - PaX Linux
  - 2003 - OpenBSD
  - 2005 - Upstream Linux
  - 2007 - Windows
  - 2007 - OS X
  - 2011 - iOS
  - 2016 - NetBSD

FreeBSD is still lacking ASLR support despite a number of attempts and an actively maintained fork.

Linux even has Kernel ASLR (even though its effectiveness is debatable and it's much better with the Grsecurity patchset).

I'm a FreeBSD user and run it on a number of firewalls, but FreeBSDs approach at security worries me and I consider porting everything to OpenBSD or Linux.

It did not even have signed packages until recently!

Nope no ASLR. They're working on it but not yet.

Yes, the log is static. It only contains the subject name if the certificate.

But there's little to fear from exposing internal domain names. DNS names are more or public knowledge - they are transmitted unencrypted, end up in plenty of caches etc. Attackers can probably brute force it or the PTR records anyway.

Yes, check_mk is great. I rolled out a 30000+ checks installation on a single server today. I've looked at most monitoring products on the market and check_mk easily wins. It's really popular in Germany, many huge companies are using it.

The English documentation isn't that great, the German one is better. That being said, it's mostly self-explanatory and all checks are very well documented in man pages.

My favorite features:

- Auto discovery for literally everything, including SNMP interfaces.

- Fine grained rule system for customizing check threshold and parameters

- All configuration is automatically versioned and you can integrate it with Git - this includes the changes you make in the web interface.

- It's very easy to set up a distributed monitoring system (multisite) with a central node which aggregates all states and replicated configuration changes, yet each site is fully autonomous.

- The agent takes zero network input, so no attack surface.

- Even though it's extremely featureful, it's architecture is very simple and it's easy to contribute code and write custom checks.

Their Git is public: http://git.mathias-kettner.de/git/?p=check_mk.git;a=shortlog...

It works well with Naemon and Nagios 4. Been using it for a number of projects, ask me anything!

Monitoring systems not to use:

  - Shinken (zero security awareness and dishonest PR, when I tried it, it has so many bugs that I wouldn't ever trust it to keep my data safe)

  - Zabbix (it has some brilliant features, but the architecture is a mess, configuration and time series stored in a MySQL database which is hard to manage and automate, I found it cumbersome to debug, written in PHP)

Firefox is significantly less secure though. Chrome has its sandbox and a highly effective XSS auditor. Firefox has neither.

I do not appreciate this change, however, and I hope that they reconsider it.

I have location history turned off, yet it still shows me previous destinations (thankfully, I like that one).

Note that most BSDs (with the notable exception of OpenBSD, of course) lack modern anti-exploitation features like ASLR.

FreeBSD is working on it, but it took surprisingly long.

Windows Docker is just around the corner!

For Python, you can just use Pyrasite (https://github.com/lmacken/pyrasite) and inject a script which prints a stack trace for all threads.

I've done this to debug OpenStack in the past and it worked very well. There are many similar projects for Python, I used this one since it's in the RHEL repo.

Useful summary on StackOverflow: https://stackoverflow.com/questions/4163964/python-is-it-pos...

You can disable the remote management and the entire embedded network stack though.

They'd backdoor your machine instead. Same result.

On Thinkpads at least it can be much longer.

It does actually encrypt your data, and if it's correctly implemented, it's fine. Those drives sell for a few years now and not a single exploit is known.

For most people this is more than enough.

The Python foundation won't budge on the 2020 EOL date, for sure. RedHat will support it until RHEL 7 is EOL (~2027), but that's security/critical fixes only - while Python 3 gets all the new features and development efforts.

At some point, the opportunity cost of staying with Python 2.7 is higher than the one-time effort of porting everything to Python 3, so companies will move. Especially the likes of Google and Dropbox.

gevent vs. asyncio - sure, gevent is more mature. But asyncio is undoubtedly the better/nicer API. asyncio's explicit await syntax is much nicer than gevent's implicit monkey-patching, which makes it harder to reason about the code.

Tensorflow isn't really a new library, it was only recently open sourced.

As for Python 3-only libraries:

- https://pypi.python.org/pypi?:action=browse&show=all&c=595

- https://github.com/aio-libs

Also note that Django will drop Python 2 support in time with the Python 2 EOL: https://www.djangoproject.com/weblog/2015/jun/25/roadmap/

Also, many new Python-based open source projects are Python 3 only.

It is NOT a different language. It's not backwards compatible, sure, but usually, only minor changes are required and 2to3 helps a lot. At this point, pretty much all of the libraries are ported and their API stays the same. The libraries which haven't been ported yet are either notable exceptions (Twisted!) or are unmaintained.

Very helpful for porting: http://python-future.org

Nah. I'm a long-time Python developer (10 years+) and I moved everything over to Python 3 because there are so many advantages. This includes a number of massive internal code bases that I maintain at my day job. Porting is surprisingly easy nowadays, it used to hurt a lot more.

Management is fine with development time spent on migrating to Python 3, since it's an investment in the future (Python 2 will be EOL in 2020!).

A few reasons which made me switch:

  - Python 2 will be EOL in 2020, that's four years

  - vastly improved Unicode support

  - a number new libraries are Python 3 only

  - asyncio and the new async syntax

  - exception chaining (!)

  - type annotations

  - lots of improvements all over the place

Just use Phabricator! It's the best code review system I've used so far. Many large open source projects and companies have adopted it.

Someone neatly wrote up the main advantages:

http://cramer.io/2014/05/03/on-pull-requests

Phabricator's issue tracker is also an excellent choice over GitHub's simplistic issue tracker.

Also, Gerrit isn't that hard and I've seen small teams get productive with it within a 1-2 weeks.

No need to reinvent the wheel!

By the way: I live in Europe and I haven't worked for one single company which would allow their developers to host proprietary source code with a third party SaaS provider.

How does this compare to Autobahn / crossbar.io?

http://autobahn.ws/

http://crossbar.io/

I really like the service discovery in Crossbar ("routed RPC").

> Another thing that was missed was that Lennart wasn't being unreasonable, nor was he saying it wasn't a problem (he specifically stated the opposite, in fact). I had a feeling at the time (based on his responses) that the reason he wasn't specifically stating he was going to fix it or open a bug report for it in systemd was that he was going to push it up-stack to a more appropriate place, and it looks like that's what happened.

This. It's really hard to blame this on systemd (not that people didn't try anyway).

If you mount to r/o, a bunch of userspace applications break. Mounting it r/w is correct.

You should take a look at Phabricator, then: http://phabricator.org/

It has more features than Gitlab, anyway.

Good advice, except the "remove all system passwords" part. Do not do this. It's a really bad idea. There are occasions where you do need to authenticate using a password, most importantly on the local console - what if your server lost network access?

And that sudo workaround is bad since it requires agent key forwarding, which you shouldn't use for the reasons the author himself noted a few paragraphs up.

There's nothing in PCI which prevents the use of SSH keys. In no scenario is password auth more secure than key auth.

Then the VPN breaks, and you're out of luck.

For interactive data analysis, this is one very nice iPython library:

https://github.com/catherinedevlin/ipython-sql

Bonus points for native Pandas integration.

Even wget can (and does) have critical vulnerabilities:

https://community.rapid7.com/community/metasploit/blog/2014/...

Why would I use it instead of SQLAlchemy? Simplicity?

Well there are use cases where you'd want to remove an EFI variable.

If they changed it to "ro" by default, people would complain as well if it breaks something.