Permalink
Browse files

Added collection of blog posts. Fixed docid for pages - docid can not…

… be too long or can not conists of colon or many hyphens.
  • Loading branch information...
1 parent 08b752a commit b62edc03613b64d0127206f92467bbf99479c264 @mloskot mloskot committed Jan 8, 2012
Showing with 773 additions and 0 deletions.
  1. +1 −0 src/dynamic/developers/development-environment.html.md
  2. +1 −0 src/dynamic/developers/email.html.md
  3. +1 −0 src/dynamic/developers/git.html.md
  4. +1 −0 src/dynamic/developers/irc.html.md
  5. +22 −0 ...namic/news/2007-02-05-What-is-the-master-key-that-is-used-to-create-the-key-pair-and-PPID.html.md
  6. +92 −0 src/dynamic/news/2010-03-31-The-common-opensource-application-publishing-platform-CoApp.html.md
  7. +34 −0 src/dynamic/news/2010-04-07-What-is-this-CoApp-all-about.html.md
  8. +60 −0 src/dynamic/news/2010-04-13-CoApp-FAQ-Why-demand-all-code-be-signed.html.md
  9. +44 −0 src/dynamic/news/2010-04-13-Notes-about-shared-libraries-in-CoApp.html.md
  10. +53 −0 src/dynamic/news/2010-04-13-The-90-second-description-on-how-CoApp-packages-will-get-built.html.md
  11. +42 −0 src/dynamic/news/2010-04-14-CoApp-FAQ-How-can-I-bind-to-a-very-specific-version-of-a-library.html.md
  12. +107 −0 src/dynamic/news/2010-04-15-CoApp-FAQ-Can-you-explain-how-side-by-side-WinSxS-works.html.md
  13. +30 −0 src/dynamic/news/2010-04-20-Things-my-pappy-always-used-to-say.html.md
  14. +32 −0 src/dynamic/news/2010-04-30-1998-The-year-i-built-my-first-package-management-system.html.md
  15. +24 −0 src/dynamic/news/2010-05-05-What-CoApp-packages-would-you-like-to-see.html.md
  16. +161 −0 src/dynamic/news/2010-06-24-When-scripting-goes-bad-er-insane.html.md
  17. +53 −0 src/dynamic/news/2010-06-28-CoApp-in-the-first-90-days.html.md
  18. +15 −0 src/dynamic/news/2010-07-17-Ramblings-a-model-for-a-sustainable-meritocracy.html.md
  19. BIN src/static/images/toolchain-diagram.png
@@ -2,6 +2,7 @@
layout: 'article'
title: 'Setting up the developer environment'
version: '1.0'
+docid: "developer:development-environment"
---
### Requirements
You'll need the following in order to correctly set up your development environment for working on CoApp:
@@ -2,6 +2,7 @@
layout: 'article'
title: 'Mailing Lists'
version: '1.0'
+docid: "developer:mailinglist"
---
The CoApp mailing list is the place where most of the detailed discussions about CoApp project development occur. It also is the place where users send support requests and e-mail questions which do not fit very well the real-time chats on [IRC](/developers/irc.html) channel.
@@ -2,6 +2,7 @@
layout: 'article'
title: 'Setting up Git and GitHub for development on Windows'
version: '1.0'
+docid: "developer:git-setup"
---
### Requirements:
@@ -2,6 +2,7 @@
layout: 'article'
title: 'IRC (Internet Relay Chat)'
version: '1.0'
+docid: "developer:irc"
---
### Requirements
@@ -0,0 +1,22 @@
+---
+layout: post
+author: Garrett Serack
+twitter: fearthecowboy
+title: What is the "Master Key" that is used to create the key-pair and PPID?
+tags: ['developer', 'signing']
+docid: "news:20070205"
+---
+
+James Manger asks a couple of pertinent questions, considering my last post on PPIDs:
+
+> What is the "Master Key" that is used to create the key-pair and PPID? Could youexplain this process?
+
+Whoa! You might as well ask what's in them sausages you just ate...
+
+Seriously, the Master key is a posse' of bytes that we use to seed the entropy for creating the PPID and the private/public key-pairs.
+
+The Master Key is generated by the CardSpace built-in STS when you create a personal card, and is stored with the rest of the data in the cardstore. It is the only peice of data in the card that the user doens't have control over.
+
+I don't have the exact algorithm in my hands (I'm at the RSA Conference in San Francisco!), but I'll post it when I get back. If I recall correctly, it's kina along the same lines as GUID generation (takes a bunch of different data bits) and corrals them together to generate a stream of bytes.
+
+I always like it when people ask questions about CardSpace's implementation, the cryptography behind it or really, any other security questions... It reminds me of somethin' my pappy told me... **"Always take a good look at what you're about to eat. It's not so important to know what it is, but it sure is crucial to know what it was"**. That kind of advice works really well for security, just as it did for those odd-tastin' sausages we barbeque'd up that night.
@@ -0,0 +1,92 @@
+---
+layout: post
+author: Garrett Serack
+twitter: fearthecowboy
+title: The Common Opensource Application Publishing Platform (CoApp)
+tags: ['news' ,'planning' ]
+docid: "news:20100331"
+---
+
+Listen up folks, this stuff is big.
+
+Today, I'm announcing the beginning of a project that intends to bring a little joy into the hearts of Open Source aficionados on the Windows Platform.
+
+The biggest challenge to using/building/maintaining many Open Source applications on Windows, is that Windows does a lot of things differently than Linux and Unix . Different filesystems, command lines, APIs, user experiences ... well, pretty much everything. Regardless of personal opinions about it being the 'right-way' or 'wrong-way', it suffices to say that it is just simply different.
+
+In order to build an Open Source application like PHP for Windows from scratch, I need to have a collection of libraries created from a fair number of different projects. This creates a dependency between the code that I'm working on-PHP-and the project that supplies the library that I need. It's pretty important that I not simply rely upon a previously compiled version of the library (provided either by the project itself, or a third party) for a number of reasons:
+
+* I want to make sure that the library is compiled with the same version of the compiler and libraries as I use.
+* In order to fine-tune performance, I'm going to need to change the compiler settings.
+* As a security precaution against malicious third parties creating flawed binaries.
+* Hey! - It's Open Source. It's pretty much a **moral imperative** that I compile the code for myself. Well, it is for me anyway.
+
+Now, unfortunately, those dependencies don't necessarily share the same development environments, practices, tools, operating systems, or even ideas as to how things should-from one's own perspective-be done (because, as every developer knows, one's own way is the 'one true way').
+
+Interestingly, this problem really doesn't happen on Linux (and other *NIX-like substances). When someone builds that same application (PHP) on Unix, they do so knowing that the OS works a certain way (generally speaking), and along with the dark magic known as autoconf, you can put the source code on nearly any Unix-variant and just build it.
+
+> Let me take a moment to talk about how this is done in the Linux/Unix world.
+> This isn't nearly a problem there because nearly all libraries come with a
+> 'configure' script of sorts which the developer runs prior to building the code,
+> and the script checks the local development environment, determines the
+> appropriate settings, compilers and dependencies, and creates a build
+> script to match.
+>
+> You download the source, unpack it, run:
+
+``` text
+ ./configure, make && make install.
+```
+
+> If you are missing any dependencies, you download them, unpack, run:
+
+``` text
+ ./configure && make && make install, and go back to the app.
+```
+
+> Shared Libraries end up in a common spot (/usr/lib), header files end up in a
+> common spot (/usr/include) and binaries can go into a common spot (/usr/bin).
+>
+> There are some tools and conventions that make this all work pretty darn good,
+> and when it doesn't, it's usually not much of a stretch to get it there.
+
+When that same application needs to be built on Windows, it takes some effort. Finding the dependencies (like OpenSSL or zlib), and getting **them** to compile (which is inconsistent from library-to-library on Windows) and then building the application itself-again, inconsistent-generates a binary that you can run. Nearly all of the time, if someone posts those binaries, they bundle up their copies of the shared libraries along with the application. The trouble is, that there is no common versioning, or really, sharing of shared libraries on Windows. If your app and my app both use the same library, they could (and often do) ship with a different version of it.
+
+
+## And, there is the user side of the equation...
+Of course. Consumers of open source software on Windows have been relegated to manually scouring the Internet for binaries, and they are often out-of-date, compiled against older compilers and libraries, and pretty hard to get working. Clearly there is a strong need for a package management system, along the same lines as apt, rpm, synaptic (and others) but built for the Windows platform, and compatible with Windows features.
+
+
+## Why not adapt the Unix-way on Windows?
+
+There are two fundamental reasons: Primarily, because it's just not done that way on Windows. And since Windows doesn't "look" like Unix, it's not very easy to use the same scripts on Windows as Unix. Sure, there are Unix-like environments for Windows (Cygwin, Mingw and Microsoft's own SUA), but they really isolate the developer from Windows itself. While they do try to create a very Unix-like environment, you end up building Unix-style apps on Windows, and pretty much forego the platform benefits that are available.
+
+Secondly, open source software that was originally written for Windows won't be using Linux-style tools anyway. Since I want to unify these two groups, I'm going to want a one-size-fits-all solution.
+
+Really, the solution is to **build it right** for Windows.
+
+## So, what exactly does "Building it Right" mean anyway?
+
+That is, in a nutshell, the sixty-four kilobyte question.
+
+For starters, this means using the tools, methodologies and technologies on Windows, as they were meant to be used, in order to take advantage of everything that Windows has to offer. I'm not interested in simply making a knock-off of the Unix-style way of doing things. Windows doesn't store binaries in c:\usr\bin (/usr/bin) and libraries in c:\usr\lib (/usr/lib), so we're not going to do things like that.
+
+CoApp will:
+
+* Provide a distributed, community driven package management system for open source applications on the Windows Platform
+* Handle multiple versions of binaries using WinSxS (I know, even the **mention** of side-by-side components evokes fear, anger and the desire to go off-diet, but bear with me, I think we've got a solution), including multiple copies of the same version of the same library, compiled with different compilers.
+* Support 64 bit and 32 bit systems, without hassle or collisions.
+* Place binaries, libraries and header files in a logical and consistent location.
+* Have tools and methods for handling dependencies.
+* Create reliable installer packages (MSIs) for installing open source software.
+* Facilitate sharing of components and allow multiple projects to easily both participate and consume them.
+* Allow for upgrades and patching of both libraries and applications.
+* Be Windows developer friendly. No forcing of building using 'make', but rather taking advantage of the nifty IDEs we already have.
+* Also be Windows admin friendly. Even if it's open source, you shouldn't have to be a developer to put Open Source applications on Windows.
+* Use advanced optimization techniques like Profile Guided Optimization to produce optimized binaries.
+* Support future technologies as they come along.
+* Aid in the adoption of Windows Error Reporting (WinQual) to assist in making software run better on Windows.
+* End the eternal struggle between Green and Purple. Unless of course you're a Drazi and are conducting elections.
+
+Tall order? You bet. Still, I believe that it's all achievable. I've spent the last several months working on some proof-of-concepts, fleshing out some ideas, and talking with some open source community members. Nothing is currently set in stone, and even the specifications are very fluid at this point.
+
+I've started a project on Launchpad at http://launchpad.net/coapp and the wiki at http://CoApp.org. I'm just starting the specifications and tools to make this happen, and I welcome everyone's input and contributions.
@@ -0,0 +1,34 @@
+---
+layout: post
+author: Garrett Serack
+twitter: fearthecowboy
+title: What is this 'CoApp' all about?
+tags: ['news' ,'planning' ]
+docid: "news:20100407"
+---
+
+Last week, I [posted][news:2010-03-31] about a new open source project that I've launched called "CoApp" (The Common Opensource Application Publishing Platform). As I've mentioned on the project site, "CoApp aims to create a vibrant Open Source ecosystem on Windows by providing the technologies needed to build a complete community-driven Package Management System, along with tools to enable developers to take advantage of features of the Windows platform."
+
+Ugh - a mouthful-and all chocked full of them shiny marketing words.(Uh.. yeah, I know wrote that.).
+
+## So, what does that mean?
+
+Well, while Windows provides some pretty good stuff for packaging applications in the form of Windows Installer* technology (aka "MSI" [[1]](#MSI), the down side is that the open source community hasn't really picked it up in the same way that they have picked up packaging on other platforms where they create repositories and distributions of software, and so we're missing out on having these nice, consistent collections of all these great open source apps. That's where I really want to be.
+
+'Course, my pappy always used to tell me *"it don't take a genius to spot a goat in flock of sheep"* ... Sure, it's easy to see what the problem is, question is, how do we go about fixin' it?
+
+Last fall, I started to sketch out what that should look like, and what it would take to get there. After a few months of poking the right people, I started to get agreement here at Microsoft that this really is a great idea, and we should be spending time on it. (And, 'course, by 'we' I mean 'me') I know from personal experience with building open source software on Windows, that things are not only sometimes tricky, but often downright impossible to build correctly, and even harder to make sure the software is built in such a way that anyone on Windows could use it. I've come up with a plan for building a set of tools to help open source software build better on Windows, along with automating the packaging in such a way that will allow us to build yet more shiny tools to locate and install them.
+
+Along with the tools, we're going to need to lay down some guidance on how to use them to build packages that play nice with each other-I want to make sure that I'm never running into "DLL Hell", never having to search for missin' bits, and always getting the right package for the right job. At the same time, I really want to use some optimization techniques to help open source software run better on Windows.
+
+Starting with [ApacheCon](http://port25.technet.com/archive/2009/11/03/microsoft-and-apachecon-2009.aspx) last fall, I began to reach out to people I know in open source communities, not only to get their buy-in that this is a good idea, but solicit their help. I've already secured a handful of folks who are interested in helping, and I can always use a few more.
+
+Over the course of the next month or so, we'll be the filling in the details on what all of this looks like on the [project site](http://coapp.org/), and discussing the merits on the [mailing list][developer:mailinglist]. From there, we'll begin to build the tools, and with a bit of luck, we'll start producing packages a few more months after that. We'll probably start with the packages that make the most sense (Apache, PHP and Python) and work our way out from there.
+
+## And just how does Microsoft fit into all of this?
+
+Well, the folks here at Microsoft have recognized the value in this project-and have kindly offered to let me work on it full-time. I'm running the project; Microsoft is supporting my efforts in this 100%. The design is entirely the work of myself and the CoApp community, I don't have to vet it with anyone inside the company. This really makes my job a dream job-I get to work on a project that I'm passionate about, make it open source, and let it take me where it makes sense.
+
+Sure, it's a large project, but I'm pretty sure that we're headed in the right direction-if you'd like to come out and help (or even just come get more details about what I'm talking about), you can start at http://coapp.org.
+
+[[1]](!MSI) I know, some people don't particularly like MSI, but trust me, it's all in how it's used - ya don't blame the horse for throwin' a shoe.
Oops, something went wrong.

0 comments on commit b62edc0

Please sign in to comment.