I was hoping that second one was about Scratch, the visual blocks programming language for kids, similar to Logo, based on a Smalltalk development environment (which is a lot better than X!)
If you're interested in visual programming with a powerful Scheme-like language with first class functions, closures, special forms, macros, and even continuations so you can define your own control structures, check out Snap! (The exclamation mark is part of the name, so it's easy to get excited about Snap!)
It's a descendent of Scratch but more powerful, hand-written in JavaScript instead of Smalltalk, and it integrates easily with JS code. (There's a user defined JavaScript function block that you can use to integrate with the Snap VM and the browser!)
Snap was written by Jens Mönig and Brian Harvey, who know what they're doing! ;)
Snap! is a visual programming language inspired by Scratch. Run Snap! in your browser at http://snap.berkeley.edu/run The IIIA1 in the title means that this is the first tutorial corresponding to Chapter III, Section A of the Reference Manual at http://snap.berkeley.edu/SnapManual.pdf
On a tangent, the NSA put out a paper long long ago on X Windows security. (I don't think it was this on but it might have been: "Securing The X Window System With SELinux" [1]) Do you happen to know the one?
I'd also like to thank you for turning me on to NeWS et. al. ages ago in another forum. Blew my mind because at the time I only really knew about MS Windows and X.
Cheers!
Hasn't somebody reimplemented X11 in JavaScript/canvas/websockets yet?
There was an X11 server for Lisp Machines! Not sure who wrote it, but it was probably written inside or at least nearby the X Consortium, and I remember Robert Scheifler used it regularly.
"For example the TI Explorer Lisp Machine came with an X11 server written in Lisp. On my Symbolics Lisp Machine I used the usual MIT X11 server written in C - this was possible because the Symbolics Lisp machine had a C compiler." -lispm
John Steinhart wrote XTool, a nice snappy reimplementation of X11 on top of SunView! ;)
>XTool was very small and
fast compared to the X sample server because I wrote the server from scratch.
I think that I'm the only person to write an X server outside of the X
Consortium. One of the things that I learned by doing it was that the X
Consortium folks were wrong when they said that the documentation was the
standard, not the sample server. There were significant differences between
the two.
>The only really worthwhile thing about X was the distributed extension
registration mechanism. All of the input, graphics and other crap
should be moved to extension #1. That way, it won't be mandatory in
conforming implementations once that stuff was obsolete. As you probably
know, that's where we are today; nobody uses that stuff but it's like the
corner of an Intel chip that implements the original instruction set. As
an aside, I upset many when working on OpenDoc for Apple and saying the
same thing there.
>The atom/property mechanism allows clients to allocate memory in the server
that can never be freed. Some way to free memory needs to be added.
>The bit encodings should be part of a separate language binding, not part
of the functional description.
>Had he done some real design work and looked at what others were doing he might
have realized that at its core, X was a distributed database system in which
operations on some of the databases have visual side-effects. I forget the
exact number, but X includes around 20 different databases: atoms, properties,
contexts, selections, keymaps, etc. each with their own set of API calls. As
a result, the X API is wide and shallow like the Mac, and full of interesting
race conditions to boot. The whole thing could have been done with less than
a dozen API calls.
I recall reading something from one of the Xorg maintainers saying, "There's maybe three people in the entire world who really understand how X works."
So that might go some ways to explaining why building your own isn't a walk in the park.
This is great! I always had this idea of trying to "build my own" to learn stuff ever since I followed along a book called "Rebuilding Rails" and so much stuff "clicked" for me.
I've already starred the repo and when I have time I'll search my Evernote because I know there a few notes there from projects that would fit this collection.
A combination of this and some other tutorials and you can have a “build your own OS”. Some coursera classes I took a while back delved into it but things like a usb controller or getting regular input were a bit of a limiting factor. (I.e. build a keyboard from scratch or support USB, build your own display... etc)
Something that I've been trying to learn how to do, but haven't found any information on and that seems missing from this tutorial, is how to write a 3D game in Vulkan. There are many entries in here about using OpenGL but nothing in here, it seems, about Vulkan. This seems like a common pattern online. Does anyone have any recommendations for a tutorial that could also be contributed to the master list?
I love this idea. I always, take a famous open source project and try to re-create or go through the source of it. Its very tough, but when you do so the learning is very immense. Thanks for the link.
Late comment but a good way to do this when you're digging through the source and look at the early commits to see where it started. I remember going through Linux 0.0.1 to boil down the essentials of the kernel for example.
https://github.com/tuvtran/project-based-learning
https://github.com/AlgoryL/Projects-from-Scratch
https://github.com/rby90/Project-Based-Tutorials-in-C