PhillipTaylor/Patchwork
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
( _`\ ( )_ ( ) ( ) | |_) ) _ _ | ,_) ___ | |__ _ _ _ _ _ __ | |/') | ,__/'/'_` )| | /'___)| _ `\( ) ( ) ( ) /'_`\ ( '__)| , < | | ( (_| || |_ ( (___ | | | || \_/ \_/ |( (_) )| | | |\`\ (_) `\__,_)`\__)`\____)(_) (_)`\___x___/'`\___/'(_) (_) (_) Patchwork is a tool that allows you to recursively add and remove diffs from a project. It provides a simple interface for moving your code between various different states. It's primary role is to be a software configuration management tool (whatever the fuck that is) rather than to replace / be a version control system. To change the feature set of the software rather and to act as an alternative to version control's branching. To give you an idea of how patchwork actually works, there is a file called patchwork.ogv in the repo. It's a video that'll play in VLC. It shows creating two patches, one depending on another. There isn't much point elaborating on what it is. I don't even know what it is myself. This readme is more of a rambling blog post than the description and usage of this tool. -- I absolutely love operating systems. They're the core of a modern computing. They interact with the hardware, abstract it, provide a consist platform for business logic and are full of intricate interesting algorithms. When I grew up using Windows they were the user interface too. The single most common aspect of all machines shaping how the user worked. The baseline, the commodity, the one central, important interface on which everything sat. I used to dream of being a Windows kernel developer. They were the equivalent of rock stars in my mind. Weird isn't it? What people think. Just plane fucking bizarre. After my degree I was messing with Linux and obviously all that Windows kernel developer stuff evaporated along with that stuff about the link between the OS and user interface. However I do love operating systems still. I even started one taken from an example on the internet. It's called Farmix and it's here on github. It's a piece of crap though. It's not going to be unique, just a boring half implemented *NIX clone designed to show someone at Sun Microsystems (Oracle) so I can get a job working on Solaris (if it still exists) ten years from now. All I want is it to be as clean, small and easy to read as MINIX and also as functional as Linux. Not possible you say? It can't be simple and feature rich? It can't be easy to read and heavily optimised? I had this idea. I start thinking about writing a patching tool. In git you have a basic simplistic operating system and you apply series of patches to it to get more features out. A 'faster scheduler' patch. On top of that? A POSIX patch providing full capabilities and a whole series of patches in between, managed by a program that allows me to switch them on and off as simply as I want. The simplicity of MINIX at the base. The feature set of Linux in a few key strokes. Being able to drill in and out of complexity would make my OS easy to study and un-daunting to work with. And this is it, in this github repository. The result of the idea. See what makes my operating system unique (or will do) is not the operating system itself but the tool that manipulates it and controls it allowing me to have my cake and eat it. I can switch on arrays of patches to strongly manipulate the way the OS works. The algorithms used, If it is realtime, if it's compatible with Linux drivers. The patching system allows me to support _any_ direction I want to take the software and allows me to pursue every route at once. In one slightly drunk revelation I actually realised my operating system kernel would be _more_ free than Linux itself. For years people complain about Linus's OOM Killer. This feature in their memory management that causes it to kill apps at random. Whilst anyone can modify the Linux kernel, add to it, maintain their own copy, maybe steer it a certain way, Linux at it's heart had a team to control the base line of features. They have a generic kernel to a certain low extent. With Farmix, you don't even need that. I can accept any patch from anyone and the patching tree allows everyone to build the operating system they want. Oracle could provide steamlined kernel algorithms for a dedicated database server and the user could also patch in some other commodity interface. Such a level of granularity and control gives you the power of a dedicated machine with widespread understanding of how the OS works and how to use its tools. So you got a few trees of diffs that need to be applied on and off and when changes are made to the code you need to test them as well, in all possible states. Having simplicity and features in my software does mean a fuck ton of complexity in managing the project behind the scenes but isn't that the job of the project or the team? To manage complexity. You gotta do more work behind the scenes to provide so much power but it is doable. Regardless of me not being able to sell the idea to my friends I can't see any reason not to try and write the program. I should finish it to see it through to completion. So I get halfway through writing patchwork and I kind of think to myself, this isn't _that_ difficult, there isn't _that_ much to it. In fact, it isn't really much more than a wrapper for diff and patch. I stop working on the software about a month ago. There's something 'off' about this whole project. I don't know why the idea is flawed per say at this point but patchwork as a program is definitely a steaming pile of useless bullshit. Fundamentally I can't see what it does. I forced myself to finish it this week just to wrap it up. I thought that even with the existence of #ifdefs in C code in git repos, there is a clearly proof that branches aren't the solution to everything. The problem is that #ifdefs are in the code are visible. Hidden diffs mean you don't know what you're reading or how it lines up with your code. But I don't really know anymore. I haven't used the product properly yet and I don't think I will. Half of it doesn't work because I can't see it being useful but I can't put my finger on the problem. Can anyone else? I was telling this idea to an interviewer last week. He asked if it was like Quilt. Something similar, written by Andrew Morton, ironically a Linux kernel developer. The more I read into it, the more it looks identical to my software. In fact his looks more sophisticated than mine because you can edit patches within the chain although I don't think his patches are designed to stick around forever. I guess the problem is the way the patches, although easily applied, hide the complexity of the software in a way that #ifdef's don't. In conclusion to my blog post, sometimes you have a good idea and sometimes you don't. Sometimes you think you're on to something cool and then it fizzles out. I took this project to completion for the sake of completion but I doubt it'll make it out of alpha. I'm branding this a failure. A positive, at least I tried something failure. Maybe something out of ashes? Probably not. Here's to the next hair brained, open source, idea :-) It's funny what people think. ---- Phillip Taylor. 5th May 2011
About
Develop features of your program as a tree of patches you can turn on and off really easily.
Resources
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published