On Friday, August 13, 2010, 5:00:28, Jonathan Wilson wrote:
> Are there any windows drivers in the open source ecosystem?
From the top of my head: TAP-Win32, libUsb-Win32, the WinUSB UPS
driver that apcupsd uses.
--
< Jernej Simončič ><><><><>< http://eternallybored.org/ >
A chain of reasoning
c: Garrett Serack; coapp-developers@lists.launchpad.net
Subject: Re: [Coapp-developers] Questions, Questions, Questions
On 8/13/2010 11:17 AM, Olaf van der Spek wrote:
> On Fri, Aug 13, 2010 at 5:14 PM, Elizabeth M Smith
> wrote:
>
>> I was referring to the fact that by defau
On Fri, Aug 13, 2010 at 5:18 PM, Elizabeth M Smith
wrote:
> The point I was trying to make is that other applications will have similar
> issues and not all are smart enough to have a conf file to specify it (and
> what if the user changes the location?) - we need some kind of way for the
If the
On 8/13/2010 11:17 AM, Olaf van der Spek wrote:
On Fri, Aug 13, 2010 at 5:14 PM, Elizabeth M Smith
wrote:
I was referring to the fact that by default the data directory for mysql
installs is in the application directory
So if you didn't "upgrade" but instead installed both side by side, it
On Fri, Aug 13, 2010 at 5:14 PM, Elizabeth M Smith
wrote:
> I was referring to the fact that by default the data directory for mysql
> installs is in the application directory
> So if you didn't "upgrade" but instead installed both side by side, it would
> have a new blank data directory
> And the
On 8/13/2010 10:37 AM, Olaf van der Spek wrote:
On Fri, Aug 13, 2010 at 1:20 PM, Elizabeth M Smith
wrote:
Heh - this may get REALLY fun when you get to say... a database or a web app
with data lying around... Are we going to provide some way to migrate that
data during an "upgrade" - caus
On Fri, Aug 13, 2010 at 1:20 PM, Elizabeth M Smith
wrote:
> Heh - this may get REALLY fun when you get to say... a database or a web app
> with data lying around... Are we going to provide some way to migrate that
> data during an "upgrade" - cause if not we'll have some pretty angry users.
> "My
On 8/12/2010 9:18 PM, Garrett Serack wrote:
We're NEVER GONNA UPGRADE using MSI.
NEVER.
Windows Installer fucked this up, and we're not gonna follow. We
always want it physically possible to have two versions installed.
This is the secret sauce to "No Reboots. Fucking Ever." :D
G
Heh
c: Garrett Serack; coapp-developers@lists.launchpad.net
Subject: Re: [Coapp-developers] Questions, Questions, Questions
I've been pushing driver support a) because I'd personally like to CoApp-ify
Windows Sensors and b) to annoy Garrett. All binaries will be signed, so devs
will just need
I've been pushing driver support a) because I'd personally like to
CoApp-ify Windows Sensors and b) to annoy Garrett. All binaries will be
signed, so devs will just need to make sure they're signed with one of
the few CAs supported by the Windows kernel.
/rafael
On 8/12/2010 11:00 PM, Jonathan W
Garrett Serack wrote:
I still have to see how twisted and evil we can get with drivers.
Are drivers something CoApp is likely to be shipping?
Are there any windows drivers in the open source ecosystem?
Will CoApp and its signing system (whatever method is used to sign packages
CoApp distributes
I still have to see how twisted and evil we can get with drivers.
From: Rivera, Rafael [mailto:raf...@withinwindows.com]
Sent: Thursday, August 12, 2010 6:59 PM
To: Garrett Serack
Cc: Trevor Dennis; coapp-developers@lists.launchpad.net
Subject: Re: [Coapp-developers] Questions, Questions
: Thursday, August 12, 2010 7:01 PM
To: Garrett Serack
Cc: Trevor Dennis; coapp-developers@lists.launchpad.net
Subject: Re: [Coapp-developers] Questions, Questions, Questions
That what I thought but I'm a little confused. If we use CO_BINDING_POLICY to
specify which versions this package replace
That what I thought but I'm a little confused. If we use CO_BINDING_POLICY
to specify which versions this package replaces for SxS purposes, then does
that mean there's a single SxS assembly for a package? If not, then does
every SxS assembly/binary in the package have exactly the same version
numb
@lists.launchpad.net]
> *On Behalf Of *Trevor Dennis
> *Sent:* Thursday, August 12, 2010 6:07 PM
> *To:* Rivera, Rafael
> *Cc:* coapp-developers@lists.launchpad.net
> *Subject:* Re: [Coapp-developers] Questions, Questions, Questions
>
>
>
>
>
> On Thu, Aug 1
rs@lists.launchpad.net<mailto:coapp-developers@lists.launchpad.net>
Subject: Re: [Coapp-developers] Questions, Questions, Questions
On Thu, Aug 12, 2010 at 6:50 PM, Rivera, Rafael
mailto:raf...@withinwindows.com>> wrote:
Oh, sorry. Wow. I just fell into that GUID-being-a-real-GUID trap that was
Yeah... components in MSI are more fine grained than you think. An install is
almost always made up of many components.
G
Eric Schultz wrote:
My thoughts on ProductCode are just create another 'HUID' but append the word
"product" to the name, version, architecture and public key token befor
microsoft@lists.launchpad.net] *On Behalf Of *Trevor Dennis
> *Sent:* Thursday, August 12, 2010 6:07 PM
> *To:* Rivera, Rafael
> *Cc:* coapp-developers@lists.launchpad.net
>
> *Subject:* Re: [Coapp-developers] Questions, Questions, Questions
>
>
>
>
>
> On Thu, Aug 1
My thoughts on ProductCode are just create another 'HUID' but append the
word "product" to the name, version, architecture and public key token
before hashing. That way every time they build the same package, the
ProductCode is also the same.
Not really sure how to do for the Guid attribute for ea
Think of it as a category namespace.
Type :: Value
Quality :: {Beta, Release, Daily, ...}
Software:: {Editor, Browser, ...}
G
From: Eric Schultz [mailto:wwaha...@gmail.com]
Sent: Thursday, August 12, 2010 6:21 PM
To: Garrett Serack
Cc: coapp-developers@lists.launchpad.net
Subject: Re: Questio
I understand there are different possible keywords i.e.: "Beta", "XML", etc.
I don't understand though why there is a type and value column on the
CO_TAGS table.
On Thu, Aug 12, 2010 at 8:00 PM, Garrett Serack wrote:
> Sure. Different Types of keywords (or tags) … could include “Beta”, etc?
>
>
s+garretts=microsoft@lists.launchpad.net
[mailto:coapp-developers-bounces+garretts=microsoft@lists.launchpad.net] On
Behalf Of Trevor Dennis
Sent: Thursday, August 12, 2010 6:07 PM
To: Rivera, Rafael
Cc: coapp-developers@lists.launchpad.net
Subject: Re: [Coapp-developers] Questions, Questions
On Thu, Aug 12, 2010 at 6:50 PM, Rivera, Rafael wrote:
> Oh, sorry. Wow. I just fell into that GUID-being-a-real-GUID trap that was
> just talked about moments ago. Yikes.
>
> /rafael
>
>
> On 8/12/2010 8:49 PM, Eric Schultz wrote:
>
> Rafael,
>
> We want to be able to provide a consistent ID fo
Subject: Re: [Coapp-developers] Questions, Questions, Questions
I don't think we should call this a GUID if you're not using the official
definition of a GUID/UUID from RFC 4122. If I see GUID in documentation, I'm
going to assume I can call a normal GUID creation function to create one.
: [Coapp-developers] Questions, Questions, Questions
Oh, sorry. Wow. I just fell into that GUID-being-a-real-GUID trap that was just
talked about moments ago. Yikes.
/rafael
On 8/12/2010 8:49 PM, Eric Schultz wrote:
Rafael,
We want to be able to provide a consistent ID for a package no matter how
Sure. Different Types of keywords (or tags) ... could include "Beta", etc?
Yes. Well, sorta. We do require that roles in the same MSI are versioned
together. Since we anticipate many smaller packages, this won't be as silly as
it may sound.
And, kindof.
On one hand, by keeping our required da
Oh, sorry. Wow. I just fell into that GUID-being-a-real-GUID trap that
was just talked about moments ago. Yikes.
/rafael
On 8/12/2010 8:49 PM, Eric Schultz wrote:
> Rafael,
>
> We want to be able to provide a consistent ID for a package no matter
> how many times its built. By using the package
Rafael,
We want to be able to provide a consistent ID for a package no matter how
many times its built. By using the package name, version, architecture and
the publisher's public key token, the same package will always have the same
ID.
Eric
On Thu, Aug 12, 2010 at 7:43 PM, Rivera, Rafael wrote
Maybe I missed something, but these IDs are globally unique. Why are we
hashing again?
/rafael
On 8/12/2010 8:39 PM, Eric Schultz wrote:
>
> I don't think we should call this a GUID if you're not using the
> official definition of a GUID/UUID from RFC 4122. If I see GUID
> in docume
>
> I don't think we should call this a GUID if you're not using the official
> definition of a GUID/UUID from RFC 4122. If I see GUID in documentation,
> I'm going to assume I can call a normal GUID creation function to create
> one.
I think you bring up a good point Trevor. I'm a bit of a stic
Hi,
Here's some suggestions from what I've learned from years of database work
and many articles from SQL development forums.
>
> >> In the CO_PACKAGE table, there is an id field. What type is this field
> supposed to be and where does it come from? (autogen by mkPackage, autogen
> by previous p
Hey gang,
One quick question regarding the MSI tables, one little more complex one
and some food for thought.
- On CO_TAGS, I understand that it holds keywords so what is the type column
there for? Are there different types of keywords?
- Regarding CO_BINDING_POLICY, as Garrett said this is nee
Hey Eric,
(you might as well post these to the mailing list so that we can keep track of
them... and so others can correct me when I'm wr^H^H ... mistaken)
>> In the CO_PACKAGE table, there is an id field. What type is this field
>> supposed to be and where does it come from? (autogen by mkPack
33 matches
Mail list logo
