mlieberman85

Agreed. Also in general the amount of bugs in Nix packages that go unfixed for months at a time is tough as well.

It goes beyond "programming" though. If the issue was that there's not a lot of programmers in general in Senegal you would have a point. However the article specifically talks about how women are discouraged from these careers and the main issue stems from systemic sexism in Senegal as a whole.

http://www.ohchr.org/EN/NewsEvents/Pages/DisplayNews.aspx?Ne...

I think you misunderstood. A dialect of lisp is a fairly trivial exercise. We were able to do it in a single lecture back in college. Now that dialect had trivial and essentially useless functionality but allowed us to easily build on and create new languages, but lisp was designed to allow for these dialects to be made and to be made easily.

As far as security is concerned a unikernel with lower attack surface will beat out a general kernel. A unikernel for AppX will have a completely different attack surface from AppY so most generalized attacks just won't work. Shell attacks like heartbleed won't work because there is no shell. Given that there's a single process, even if you did compromise the system there's not a whole lot you can do with it.

There are chairs that tall they're often referred to as "office stools."

Did it actually have much of a "realistic simulation" though? One of the main reasons I didn't buy the game is because people tore it to shreds for utilizing the same exact algorithm for determining traffic as they did water and other utilities. Also people pointed out that like people themselves weren't actually simulated in anyway they just woke up in the morning found the first open commercial job to work at and at night left and found the first house to live in.

The problem is the consumer has expectations. If you tell them they're getting X and you give them Y and Y is demonstrably of lesser value than X they're going to be pissed off. He just over promises and under delivers.

Now with that said of course he doesn't deserve threats, and I agree that gamers tend to be quite the vicious bunch. It's pathetic on their part. I still bought Godus, I was disappointed by it and believe Molyneux deserves criticism for once again delivering something that's not what was promised but I don't understand how/why people go to such extremes.

I met one guy who was essentially a audiophile zealot. He had a ton of money, very little knowledge but it was like a game to him. He spend something close to a quarter million dollars on his NYC apartment's audiophile system. He described how the engineers "specially tuned" the wi-fi so that he could maintain the right fidelity.

The quality of Uber/Lyft drivers and the service in general has plummeted so much lately that I've just switched back to local car services. I just had a nice conversation with a car service driver, who also does Uber, and he said he prefers the car service over Uber because they pay better and only uses Uber when he isn't getting anything else but the pay has dropped over the past year pretty significantly for him whereas when he had started it was pretty good. That's an anecdote so take it for what you will but I just don't see how lowering prices further helps anyone out long term.

Agreed. I was told to lead a team in all but title, but without the title I was consistently told that I didn't have the seniority nor have I proved myself. Maybe it's different at Delphix, doubt it, but if it is different at Delphix is there just the "Engineer" title and that's it? If so, that's great. If there are titles like Infrastructure Engineer and Front-End Engineer and Chief Architect, etc. then thats on the company culture for being contradictory.

Personally a fan of Ansible, but I've also been pretty impressed by SaltStack as well. Either is much simpler and easier to use than the older generations of configuration management tools (cfengine, Puppet, Chef.)

I disagree. To be honest Aereo's service was about as reliable as your average antenna is (read: not reliable.) To me it felt like I was renting a really large extension cord for a cable. One that I need because I live in a basement apartment and even with 60 dollar antennas I get spotty reception at best. Aereo was more consistent but the quality was that of what you would expect from an antenna. It didn't feel like someone was recording 1080p HD quality from cable and then streaming it to me. Cable is not just crummy antenna quality that is then piped to the home. They get high quality from the channels.

Currently there is no evidence for any relation between his methods and his death. The cause of death either hasn't been determined yet or is currently private.

It's already apparent for reasons exclusive of this that experimenting on yourself is a bad idea. However it is fallacious to just assume that his actions led to his death like this and to claim outright like you are is irresponsible.

There are companies out there where there is that isolation. Especially in the financial sector. I worked as a vendor to several big banks and credit card companies. Devs were expected to write code for functionality, that's about it. If there was an issue with the production environment and it wasn't related to a deployment, it was operations' problem. For example if my app has major memory issues every 3 hours or so it was operations' responsibility to restart that app when need be and ensure it stays up and running not the devs' responsibility to fix the memory issues. This isn't always the case and often what was mentioned above were temporary solutions intended to give devs more time but there was definitely that disconnect where operations is responsible maintaining the running state of the environment and the devs were primarily concerned with writing code that works and provides the functionality it is supposed to but not concerned with making the code run well.

I agree it has its uses but I feel like MongoDB (the company) sometimes puts forth use cases for MongoDB (the database) that are untenable. For example the pre-aggregated reports use case that they tout that fails at any reasonable scale (e.g. hundreds of upserts a second against tens of thousands of documents)

Tooling is still difficult. I've used Puppet, Chef and Ansible all in production environments and though I like Ansible the best I just think none of them are all that great yet. Chef had some major issues between versions (entire suites of cookbooks made obsolete) and certain operations weren't deterministic. Puppet's DSL is just awful in my opinion though they have probably the best feature set . Ansible is definitely much simpler than the other two and easier to use, but a lot of the gotchas are just frustrating, e.g. jinja2 templating issues, a lot of new features that have unintended side effects when used with certain other features, where you can use conditionals and where you can't use conditionals seem arbitrary, etc.

For too long Operations and Development have had an adversarial relationship that bordered on belligerent. At a lot of large organizations I've had a working relationship with development didn't really care how efficient their app worked or whether it crashed every half hour, just that it provided the functionality that it was supposed to. This became a nightmare for operations. The same goes the other way around. Operations didn't really care much about how the development environment is setup and don't care how difficult it is for developers to deploy and test their code.

DevOps, as widely debated what the actual meaning is, brings development and operations into a more symbiotic relationship. Whether that means that devs have a more operations minded outlook, or operations looks into how to make development more efficient, or automating operations or any of the other various definitions in the end it's about making sure the entire life cycle of an app is run more efficiently. From initial development and testing through scaling.

DevOps means different things to different people it seems. I've spoken with dozens of companies and each one seems to have a different definition. Some view it as an SA with a brain. Others view it as a full stack developer, still others view it as guys focused on developing configuration management and just that. Others consider DevOps tools developers. Some just say DevOps and they mean "guy we can ask to just do whatever needs to get done, helpdesk, networking, configuration management, training, etc"

I disagree with the central thesis of his argument that being generalized is a detriment and that operations and other factors should remain siloed at your average large company. I've worked at both large companies (10k+ employees) and small companies and many things in between.

In general a Full Stack DevOps oriented approach always tends to be more efficient. You have less monolithic hard to maintain applications because you force the teams to be small and agile. People will have their specialties (operations, backend, frontend, etc.) but still remain generalized enough to have an idea of the big picture. If your application has issues where the frontend developer doesn't know the general idea of how Varnish and Nginx in your stack are setup then perhaps your application is too big and complex.

I think this approach is a breath of fresh air given the track record of so many other companies that say "no comment."

In the end they're protecting their brand. For as long as they can they have to be the company that goes above and beyond when it comes to reliability, safety, customer satisfaction, etc. Otherwise they just end up becoming the next Fisker. It makes sense why they're so militant, especially given the media's often negative attention and how it can kill a small company (compared to the big car companies) like this.

If there's alternatives then why do so many pieces of software (nginx, Apache, etc.) use OpenSSL as opposed one of these alternatives?

I disagree that there is a disproportionate number of crazy ultra-libertarian members of the Bitcoin community and it seems more likely that the more fringe members of the community are also the most vocal and they tend to drown out the more reasonable and level headed members of the community.

There are valid criticisms and parody of libertarianism. There are valid criticisms and parody of Bitcoins. This article doesn't provide any of that. It's just a big straw man.

Exactly. My girlfriend worked for Megaupload for a few years and said the whole copyright infringement stuff is just the tip of the iceberg. His big business was laundering money for European organized crime. This man is no folk hero.

False equivalence. Microsoft doesn't snoop every single email hoping to protect their property. This was a very controlled situation.

How so? He definitely took a risk. He is taking an elevated risk because the company might not be there in 6 months. Especially with a young startup. It's one thing if the guy is becoming a chef at lets say Mastercard or Bank of America or some major company that there's a reasonable expectation that the company isn't going to go out of business tomorrow.

With that said I actually think stock options are a good incentive for all employees. It provides some reasonable guarantees on both parties. On the one hand the employee is given incentive to work hard because the more productive they are the better the company does and the better the stock does. Also it gives them something nice in case they get laid off and the stock goes up. Also the company sees those same benefits. The employee will probably work harder and more productive because they have more incentive to.

Your argument is fallacious. You've cherry picked a single line from her argument and misrepresented it.

Her argument is against holacracy, not against management. What I got out of the article is that when you have a system with no conventional management structure you end up filling the vacuum with people who take advantage of it. In this case some of the people at GitHub who have been accused of harassment would have been dealt with earlier if there was a better management structure in place.

If Nagios was a lightweight monitoring solution I would agree with you. Nagios however is a large monolithic system that is hard to integrate with third party metrics solutions, inventory management, etc. Though something like inventory management isn't part of monitoring it is still part of your whole system and if your monitoring solution can't easily integrate with your inventory management solution it gets frustrating.

I also tend to think service discovery or at least a flexible API that allows other systems to create new checks is a huge part of monitoring. Nagios' configuration files are a nightmare to deal with especially in a configuration managed environment.