This book influenced me tremendously. It explains how can random process (e.g. genetic mutation) builds highly non-random structures (e.g. the human eye). Recently I was using American Fuzzy Lop (http://lcamtuf.coredump.cx/afl/) to find bugs in my software, and was able to appreciate the surprising effectiveness of the "random" strategy it employs to discover structures in the program. For example, AFL could construct a valid JPEG using randomized input: https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-th....
Hey thanks for the link, that jpeg example is really quite cool.
One of the things that I gained from the book was a bit better "feel" for getting the right granularity/modularity in order to facilitate evolvability (as in the chunks I might want to swap out for another implementation, while leaving others in place), as a separate concern from maintainability.
BTW, I've noticed is that the "order blindly emerging from chaos" theme keeps popping up in fiction by writers like Bruce Sterling, Cory Doctorow, and Charles Stross (all favorites of mine).
To quote that in its entirety: “[Rape] ends in just a few minutes with little-to-no harm caused to the victim. Meanwhile, false accusations of rape have a long-term and much more devastating impact on the victim.” - That's really sick.
Yeah, and burglary ends in a few minutes with the victim not even being there. Meanwhile, I have friends who now are having trouble sleeping just because of the mere idea of violation to their personal space.
I don't know what the author was thinking writing the above, but wow.
"Denying world’s poorest free partial Internet connectivity when today they have none, for ideological reasons, strikes me as morally wrong." - Mr Andreesen, given how rich you are, you need to be really careful when you talk about morals. (Quote from Bible omitted)
OCaml is a fine language that most people don't use. If I want a unikernel in my own language, do I need to build one myself? I wonder if someone is building a unikernel that have external language bindings, which will allow one to create "High-level" unikernels. This will open up the possibility to completely bypass the installation of language runtime. For example, I can just type some Python code into a browser editor, the backend can take the source code and fork a Python unikernel to run the code. Docker can currently do this but one still has to rely an underly OS to manage all the packages etc.
Wouldn't it be nice if you could simple write "import xyz", and the unikernel takes care of fetching them automatically?
Will probably be a while before could build a clean-slate unikernel with something like python, but doing what you want in a rumpkernel looks to be just around the corner:
It's getting really close! I have a post detailing how you would run Flask in a rumpkernel[0]. Right now any pure Python modules will run just fine.
We get into tricky situations when you need C extensions, e.g MySQL or PostgreSQL. Since extensions must be statically linked, you have to decide upfront what you want. Either extension can be compiled in, but including both in the package by default.... So a production Python build is fairly custom right now.
Nothing insurmountable, just haven't gotten the workflow perfect.
Thanks :) - we're super early in this space, but are incredibly excited by what how we can use both containers and unikernels to help ease the development process and integrate with your current stack.
Mirage uses OCaml's strong types to generate secure, fast and highly specialised code. It's also very succinct and with LWT, almost as good as Haskell for lightweight concurrency and nonblocking IO. Why would you want to use Python? This is a golden opportunity to learn and use a superior language.
There are a bunch. NodeOS and runtime.js are the ones I've looked into because I like JS but there are unikernel implementations.
The cool part is, if the OS is trimmed down enough (ex < 10mb) it's small enough to fit in version control.
Much like we automate build tools to concatenate/minify web assets, it'll be possible to create a build step that takes a webapp as input and spits out a fully functional VM ready to deploy as output.
It completely inverts the deployment process. Instead of building an environment and deploying an app to it, you focus on building the app and deploy it as a VM when it's ready.
Very true. It changes the perspective a little bit: Instead of worrying about incompatible/incomplete libraries/packages. The application dictates everything all the way down to the VM level, and in a single language.
So the study confirms that people naturally trust what their friends are posting, which then confirms that trust is what bonds friends together.
I view Facebook as a means to strengthen existing "physical" friendship, rather than a place to get unbiased information. So in that sense this is neither surprising, nor detrimental. Imagine what will happen if your friends start correcting your political views...
For less biased information, please refer to twitter. And please don't mix Facebook friends with twitter followings.
The sad thing about changes brought by money and for money is that we don't have a community anymore. We don't even know what it looks and feel like. I honestly want to find such a place to live and raise my kids haven't found an example of it anywhere (in US)
Note that I'm not an expert in the field nor do I consider myself part of a community. I'm just giving an example where you've asked. I'm sure there are many more examples out there.
If a task involves "clicking next", then that task should not require any specialized knowledge to do. I totally agree that all developers should be willing do write code to automate "DevOps" tasks whenever they see fit. I know a lot of programmers who do this. These programmers always have a bunch of scripts sitting in their ~/bin, and you hardly ever see them clicking.
I am a "programmer", but I love "DevOps" stuff, and mostly recently I wrote a large automation framework that got CI team interested. Tons of energy and time is wasted everyday where teams don't understand (and don't want to understand) each other's code.
> If a task involves "clicking next", then that task should not require any specialized knowledge to do
I would disagree with this point. If you're installing anything on a production box you really should know what that installer is going to do to your environment. Have you walked through the MS SQL Server installer wizard? You absolutely do need specialised knowledge if you're running that on a client's server.
SQL Server is probably one of the easiest "big" software systems available in the world. Without having much specialized knowledge you can setup a powerful HA cluster. It's mostly clicking next and following some basic instructions. Out of the box, it'll perform pretty well (just remember to click the "Optimize for Ad Hoc Workloads" checkbox in the properties page).
SQL Server requires vastly less "specialized knowledge" than, say, Postgres. I would be surprised to find that most SQL Server installs come with someone with really in-depth knowledge.
The same applies to a lot of other things MS ships, like setting up AD. Sure, knowing what you're doing helps, but MS sorta built an empire on making a lot of that stuff pretty trivial to do. For another example, look at setting up IPSec. A cute little UI you click on, versus well, the process on Linux.
Sorry no, it's an easy clicky pointy path to hell when you discover one month later no-one understood what the file path options meant (and there can be many when installing Standard+) and then the system volume ran out of space.
Or what accounts to run SQL's various services under and wonder why stuff doesn't work or their SQL box gets hijacked ("oh I'll just run this under the SYSTEM account").
The install wizard for SQL Server 2008R2 Standard Edition has around 20 pages (counting tabs on a page) of user selectable options and settings. You certainly do need to know what you're doing and understand the implications of each every one of those settings.
Sure if you're just doing a quicky install of the Dev Edition on your workstation you can afford to be a bit lax and click on through, but on a mission critical production box you need to RTFM or let a SQL admin who knows what they're doing perform the install.
I've been called in too many times to unf*ck a SQL server because a customer has declined one hour of installation support because their devs thought they knew better.... "oh yeah it's just clicky pointy install, why do I need help with that". Trust me GUI installers do not equate to "easy install" if you have no clue what the installer is asking you.
I'm a SQL (MS and MySQL) admin, amongst many other roles, for a webhoster with 19 years MS SQL Server experience (started on SQL 6.5 in '97), been there seen it all.
I mean, if you consider knowing that databases require disk space to be "specialized knowledge" then, I mean, I guess so. Otherwise the installer is rather straightforward in telling you what the paths are for. And creating a new DB also shows you which files will be used. There may be 20 pages, but most of that is ... pretty straightforward, easy stuff.
I've run SQL Server in life-critical production systems (911 call routing) and found it to be very straightforward. Just make sure the alarms are turned on and enabled for replication.
I've run it in HA clusters, both with a shared DAS and with the new shared-nothing system. A walk in the park. The only difficult thing I've personally run into with SQL Server was figuring out the Broker Service stuff and dealing with replication outside of a domain. And that was probably mostly networking configuration issues - the config wizards are pretty amazing.
I'm not implying that there is no specialized knowledge, and many SQL Server installs are probably suboptimal. But it's far from necessary to know much to go very far with SQL Server.
Compare to Postgres, where doing anything correctly requires mucking around with the config file, and, last time I used it, logging into the shell with a special user. And HA, well, good luck.
Sounds like you both came to the conclusion that to do things it's best if you pay attention and care.
I may be the only one around though that doesn't find config files to be 'mucking' or a form of mysticism that all should kneel before the user who can wade through them. That also, is not 'specialized knowledge'.
I managed to install Postgres from source, and have a standard setup. It wasn't so bad. Run the usual configure make, make install scripts, and go through a tutorial page for setting up the initial user. Ok, I have a fair bit of Linux experience but I am not a sysadmin.
