I don’t want to go all “you darn kids” so I won’t. But the pervasiveness of web technology I think has made the majority of us forget why it’s pervasive. Cross platform can be really fucking hard, especially if you don’t respect the challenges and end up down a blind alley.
One of my favorite books starting out was the Stevens book about Unix. It only covers the differences in system call availability and behavior across Unix OSes. It doesn’t even touch graphics. It’s a big fat book just covering file, network, processes, and memory operations. No Mac, no Microsoft, just Unix.
I worked on making the Read activity usable in book mode (keyboard folded away, but gamepad buttons usable), and I vaguely recall putting in an ioctl to put the CPU to sleep after you turned a page, but I'm not sure if my changes made it in.
One of the positive outcomes of the OLPC project was the "stone soup" effect, in that it inspired many different people and companies to contribute useful ingredients, which could be folded back (or spun out) into other independent projects.
For example, the "tickless kernel" power saving stuff in the Linux kernel that consolidates bunches of non-exact timer wake-ups to all happen at the same time came out of RedHat's work on the OLPC project.
EA released the original SimCity source code for the OLPC, under GPLv3, so it could be ported to other platforms and further developed (under a different name, Micropolis).
Sugar had a long way to go, and wasn't very well documented. They were trying to do too much from scratch, and choose a technically good but not winning platform. It was trying to be far too revolutionary, but at the same time building on top of layers and layers of legacy stack (X11, GTK, GTK Objects, PyGTK bindings, Python, etc).
Sugar was written in Python and built on top of PyGTK, which necessitated buying into a lot of "stuff". On top of that, it used other Python modules and GTK bindings like Cairo for imaging, Pango for text, etc. All great industrial strength stuff. But then it had its own higher level Hippo canvas and user interface stuff on top of that, which never really went anywhere (for good reason: it was complex because it was written for PyGTK in a misshapen mish-mash of Python and C with the GTK object system, instead of pure simple Python code -- hardly what Alan Kay thinks of as "object oriented programming"). And for browser based stuff there were the Python bindings to xulrunner, which just made you yearn for pure JavaScript without all the layers of adaptive middle-ware between incompatible object systems.
The problem is that Sugar missed the JavaScript/Web Browser boat (by arriving a bit too early, or actually just not having enough situational awareness). Sugar should have been written in JavaScript and run in any browser (or in an Electron-like shell such as xulrunner). Then it would be like a Chromebook, and it would benefit from the enormous amount of energy being put into the JavaScript/HTML platform. Python and GTK just hasn't had that much lovin'.
When I ported the multi player TCL/Tk/X11 version of SimCity to the OLPC, I ripped out the multi player support because it was too low level and required granting full permission to your X server to other players. I intended to eventually reimplement it on top of the Sugar grid networking and multi user activity stuff, but that never materialized, and it would have been a completely different architecture than one X11 client connecting to multiple X11 servers.
Then I made a simple shell script based wrapper around the TCL/Tk application, to start and stop it from the Sugar menus. It wasn't any more integrated with Sugar than that. Of course the long term plan was to rewrite it from the ground up so it was scriptable in Python, and took advantage of all the fancy Sugar stuff.
But since the Sugar stuff wasn't ready yet, I spent my time ripping out TCL/Tk, translating the C code to C++, wrapping it with SWIG and plugging it into Python, then implementing a pure PyGTK/Cairo user interface, without any Sugar stuff, which would at least be a small step in the direction of supporting Sugar, and big step in the direction of supporting any other platform (like the web).
None of that work would have been possible without the OLPC project, which inspired EA to give SimCity away for free in a way that made it possible to port it to other platforms.
So I believe some good did come out of the OLPC project, including some interesting discussions about constructionist education, visual programming and teaching kids to program, with Alan Kay, Guido van Rossum and others!
SimCity for OLPC (One Laptop Per Child): Applying Papert's Ideas About Constructionist Education and Teaching Kids to Program:
http://www.donhopkins.com/drupal/node/129
A related question: in your opinion, what were the successes and failures of the OLPC project, what openings and obstacles contributed to that, and where do we go from here?
https://news.ycombinator.com/item?id=11942313
>Even if we didn't achieve those goals for Sugar, we made progress in the right direction that have their own benefits independent of Sugar.
>Choose your lofty goals so that when projected onto what's actually possible, you still make progress!
So devops conferences will no longer sound like "Docker docker Docker? Docker. Docker docker docker docker? Ahh, Docker docker Docker docker docker." Now they'll sound like "Moby moby moby...?"
This seems absurd from a branding point of view.
I personally find this a little bit vindicating. I'm 39, which is like 120 in programmer years. I feel like one of the advantages of being an "old" (in quotes!) programmer is that I'm pretty good at spotting a fad. Unfortunately whenever I point one out I get mocked and down voted to oblivion, so I've learned to just sit on the sidelines and watch the fads go past and just work to avoid them in my own projects.
Programming is very faddish, and I've seen fads come and go. Here's a few of the ones I've seen in my tenure:
- "Design patterns" heavy "enterprise" programming, such as commonly seen in the older work in the Java and .NET ecosystem.
- XML for everything.
- Agile. Oh god, agile.
- Test driven development.
- Dynamic languages (as productivity magic pixie dust).
- Service oriented architecture (SOA).
... I could go on.
Not everything in these fads is bad. Fads often contain good ideas and some fads contain non-fad elements that stick around. But they're fads insofar as they are over-hyped as magic cure-alls.
The key characteristic of a fad is this:
It's heavily hyped as a cure to some set of very hard problems in programming or system administration, but all it really does is move the problem somewhere else or hack around it in some trivial gimmicky way. There is no real innovation. Meanwhile the fad often introduces new problems that nobody thinks about until the shine wears off.
My simple heuristic for recognizing a fad is to ask "where's the innovation?" A real innovation is a conceptual leap forward. It has a certain "meaty" feel to it and seems worthy of at least one solid CS paper. It often reduces complexity, since when deployed you can now dispense with all the mountains of hacks you used to work around the problem prior to the innovation.
Here's some current things that I very strongly think are fads:
- Microservices, which is just a reboot of SOA. The idea is not inherently bad and often results in more scalable systems, but the faddish part is the idea that replacing local API calls with RPC API calls or event queues is going to make some major class of programming problems go away. No, and you've also just introduced a new set of problems around network unreliability.
- "Serverless" cloud, a.k.a. total lock-in to a proprietary mainframe. Everyone doing this is going to regret it in 5-10 years except Amazon's shareholders. It's a roach motel. Compute will get another order of magnitude cheaper and prices for everything else will drop accordingly, but these prices will not since you drank the kool-aid haha.
- Containers.
... yes, containers.
Like most fads, containers are a response to a real set of problems. These are mainly:
- System/VM configuration drift and variability.
- Dependency and DLL hell.
- The fact that Linux/Unix has devolved into a single-tenant operating system where it's hard to deploy more than one thing on one "server." (This debacle is deserving of a whole very long blog post.)
Containers are a fad because they don't address any of those problems with real innovation.
System configuration drift, dependencies, and DLL hell are are addressed by the gimmicky hack of basically tar'ing up whole Linux images and treating them like gigantic statically linked binaries.
If you're going to do that, why do you need Docker/moby/whatever? Just use a static Linux distribution like http://sta.li and run every service in its own home or chroot. Keep your service trees in git and manage systems with Chef, Puppet, or f'ing shell scripts.
I fail to see why orchestration (a.k.a. provisioning) systems like Kubernetes could not work in such an environment without the container cruft.
Containers don't solve multi-tenancy much in practice. Their security profile is not good enough for true multi-tenancy, and if you try to run too many on one server you're going to run into stability problems that derive from all the bugs that exist in all that extra complexity they add.
Real solutions to these problems would... you know... really solve them. A real solution would make it possible to deploy stuff easily and forget about DLL and dependency hell. A real solution would restore true multi-tenancy to Unix, allowing users (not root) to install and run services on commodity identically-configured Unix systems. A real solution would reduce complexity.
Edit:
I do wonder a little if the idea of throwing out dynamic linking, which both containers and some newer compilers like Go do, is not a bad idea. Maybe it's obsolete. Maybe the tiny memory savings of dynamic linking are no longer justified by the complexity overhead of dependency management.
> there are still security issues with containers no?
In Linux, perhaps. However FreeBSD jails and illumos zones are rock-solid. There's this crazy hype around containers these days and people just ignore the stable, secure, and tried technology, I don't understand it at all!
FreeBSD and illumos are not Linux, but their still Unix-like, it's not like you'd have to use OpenVMS. Plus you'd get other benefits too, like DTrace and ZFS. And on illumos now you can even run Linux binaries in a zone.
So why do people simply pretend these secure technologies don't exist? Can someone explain?
To this day, this 'uh-oh!' sound makes me tingle all over.