Re: Concerns with Open/OS Corporate Linux ads?
On Tue, Aug 29, 2006 at 07:17:39PM +0200, martin f krafft wrote: > I am holding in my hands the 09/06 copy of the German Linux Magazin, > and on page 76, opensourcefactory.com has advertised Open/OS > Corporate Linux [0], which apparently makes Debian "mature". > While I applaud their efforts and I think it's exceptionally great > how they are open about Debian forming the basis of their product > (!), the ad also leaves a weird aftertaste, > and since their ad is entitled "Debian of full age", it kind of > suggests that Debian per se is immature, a child, an assertion I'd > strongly oppose. > I'd be interested in what people think. Am I just overreacting? Martin, this is an *ad*. Ads lie, as long as it cannot be unambiguously proven they lied. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Concerns with Open/OS Corporate Linux ads?
* martin f krafft [Tue, 29 Aug 2006 19:17:39 +0200]:
> Then they go on to state that Debian is
> - reliable
> - secure
> - upgradeable
> - integrateable
> - preconfigured
> - remotely administratable
> and that they add support and maintenance, which adds the features
> - reliable release cycle
> - newest packages
> - security team
> - preselected packages
> - security administration
> - certification
> - software tests
> I'd be interested in what people think. Am I just overreacting?
I think you're reacting in the wrong direction (or at least, in the
wrong direction for a *first* reaction.)
With this I mean that, if Debian initiates contact with this entity, I'd
like for it to be to mention that, if they're interested, they can
contact DPL-delegated Project Member Joe to work out and discuss
possible ways to have some of their work go back to Debian. (See below)
I'd offer myself, but while I know the Debian side well, I'm quite
unfamiliar with the enterprise environment. I'd be happy to act as an
assistant of the delegated person, should anybody step. :-)
* * *
Having their work go back to Debian may sound impossible to you if you
think of "straightaway", but it should be workable. To mention a couple
ideas:
* release the backports they produce ("newest packages") after a
while; eg. release backport for AppFrog X.Y.Z right after they've
made X.Y.Z+1 available to their clients; or X.Y+1.0; or X+1.0.0.
* allow the staff that prepares security updates for them, to spend 1
out of each X working hours preparing a patch for a vulnerability
present in a stable package they don't support, coordinating with
the Security Team as to not duplicate effort.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
«Ara que ets la meva dona, te la fotré fins a la melsa, bacona!»
-- Terenci Moix, “Chulas y famosas”
signature.asc
Description: Digital signature
Re: Concerns with Open/OS Corporate Linux ads?
On Tuesday 29 August 2006 10:17, martin f krafft wrote: > I'd be interested in what people think. Am I just overreacting? Ironically, suggesting Debian is immature is in itself childish, especially to pitch a product with zero track record to date. That aside, they give the impression that they're just doing a cut-and-run on the process instead of being part of the cure. > Should we do anything about this? If so, what? Perhaps ask them kindly to either contribute their work back to Debian, or stop using "Debian" in their advertising and packaging. -- Paul Johnson Email and IM (XMPP & Google Talk): [EMAIL PROTECTED] pgpS9zbCdKDsD.pgp Description: PGP signature
Re: Concerns with Open/OS Corporate Linux ads?
Scripsit martin f krafft <[EMAIL PROTECTED]> > also sprach Henning Makholm <[EMAIL PROTECTED]> [2006.08.29.2310 +0200]: >> July 6 - bug goes public through upstream's BTS, Debian bug filed >> July 21 - fixed in sarge, DSA released > I know this is a ridiculous time span, but it's better than nothing. Certainly it's better than nothing. My point was merely that there is plenty of window for opensourcefactory.com to do _better_, and if they actually manage to, they do get the moral right to brag about it. -- Henning Makholm "Al lykken er i ét ord: Overvægtig!"
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 10:07:55PM +0100, Mark Brown wrote: > On Tue, Aug 29, 2006 at 03:07:11PM +0200, Sven Luther wrote: > > On Tue, Aug 29, 2006 at 11:00:44PM +1000, Hamish Moffatt wrote: > > > > To those who consider ROM-less hardware cheap and nasty I suggest the > > > opposite is true. I design hardware (FPGAs) professionally for expensive > > > communications equipment. We avoid ROMs as much as possible, because > > > they are difficult to upgrade reliably and they are a waste of money. > > > Do you consider FPGA config files as programs, or would you say that the > > normal DFSG requirement for source applies to those also in order to be > > considered fit for debian/main ? > > > I am interested in your profesional opinion on this, since you clearly seem > > to > > either be, or in close contact to someone who is, an upstream author of such > > firmwares. > > Speaking as someone with experience of the software rather than hardware > side of this I'd call FPGA images hardware. From the point of view of > working with it it looks very much like hardware. That's just my > opinion, though. Well, but it is stuff with sources. You could argue that actual hardware also has sources (the design document, schematics and routing files) though. > I'd also observe that newer FPGA chips often feature encryption support: > the hardware has a secret key blown into it during manufacturing which > must be used when building FPGA images to be loaded onto the hardware. Nice. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Concerns with Open/OS Corporate Linux ads?
also sprach Henning Makholm <[EMAIL PROTECTED]> [2006.08.29.2310 +0200]: > We also shouldn't fool ourselves into thinking that a commercial > repackager with a real dedication to security support (say, by hiring > a handful of full-time employees to keep it current, and also by > restricting their attention to one or a few architectures) could not > beat _our_ overworked, underpaid (etc) security team. Of course not. Yet I still thought their ad makes it look like we don't have anything... > July 6 - bug goes public through upstream's BTS, Debian bug filed > July 21 - fixed in sarge, DSA released I know this is a ridiculous time span, but it's better than nothing. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck http://debiansystem.info `- Debian - when you have better things to do than fixing systems "a man who does not realise that he is half an animal is only half a man." -- thornton wilder signature.asc Description: Digital signature (GPG/PGP)
Re: Concerns with Open/OS Corporate Linux ads?
Scripsit Benjamin Mesing <[EMAIL PROTECTED]> >> - we have our own security team > That isn't negated by their add, in fact they state that Debian is > secure. And Debian has lacked security support for new software for a > long time (I believe testing is supported now). We also shouldn't fool ourselves into thinking that a commercial repackager with a real dedication to security support (say, by hiring a handful of full-time employees to keep it current, and also by restricting their attention to one or a few architectures) could not beat _our_ overworked, underpaid (etc) security team. As a random data point, take DSA-1116 (a buffer overrun with no known exploit, in a quite popular piece of desktop software), where I happen to have a timeline: July 1 - reported privately to security team, with patch July 6 - bug goes public through upstream's BTS, Debian bug filed July 7 - upstream releases fixed version July 7 - fixed in NMU to unstable July 13 - bug reaches front of security team's attention queue. DSA and update to sarge prepared, but is stalled by some buildd problem on a minor architecture. July 18 - fix propagates from unstable to testing July 21 - fixed in sarge, DSA released It is not my point to criticize the security team; I have no reason to think they are not doing an absolutely fantastic job within the externally-imposed constraints of volunteer work, unstable supplies of free time in which to do the work, donated autobuilder machines spread around the world and run by a different set of volunteers, and so on and so forth. But it is also clear that a business which makes it a strategic priority to compete on the timeliness of security updates *could* well provide some real value over our stable and testing suites here, even - as in this case - when we have a 5-day head start. Whether the company in question *is* actually such a business or it is just making empty promises, can of course not be discerned just by reading their ad. > I do not think that Debian as a whole should take action, but you could > sent an email to them and tell them that they've hurt your feelings (and > you, as opposed to me, form a part of Debian). But please take care to express that it is an individual that you complain, rather than as a representative of Debian as such. -- Henning Makholm "Jeg har tydeligt gjort opmærksom på, at man ved at følge den vej kun bliver gennemsnitligt ca. 48 år gammel, og at man sætter sin sociale situation ganske overstyr og, så vidt jeg kan overskue, dør i dybeste ulykkelighed og elendighed."
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 03:07:11PM +0200, Sven Luther wrote: > On Tue, Aug 29, 2006 at 11:00:44PM +1000, Hamish Moffatt wrote: > > To those who consider ROM-less hardware cheap and nasty I suggest the > > opposite is true. I design hardware (FPGAs) professionally for expensive > > communications equipment. We avoid ROMs as much as possible, because > > they are difficult to upgrade reliably and they are a waste of money. > Do you consider FPGA config files as programs, or would you say that the > normal DFSG requirement for source applies to those also in order to be > considered fit for debian/main ? > I am interested in your profesional opinion on this, since you clearly seem to > either be, or in close contact to someone who is, an upstream author of such > firmwares. Speaking as someone with experience of the software rather than hardware side of this I'd call FPGA images hardware. From the point of view of working with it it looks very much like hardware. That's just my opinion, though. I'd also observe that newer FPGA chips often feature encryption support: the hardware has a secret key blown into it during manufacturing which must be used when building FPGA images to be loaded onto the hardware. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: Concerns with Open/OS Corporate Linux ads?
Hello, > And Debian has lacked security support for new software for a > long time (I believe testing is supported now). What I meant to say here is, that testing with the latest relatively stable software in it, had no security support in the past. > > and since their ad is entitled "Debian of full age", it kind of > > suggests that Debian per se is immature, a child, an assertion I'd > > strongly oppose. > Well, I would be to hard on that. Being young does also have its > benefits :-) Of course that should read would _not_. -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Steve Langasek <[EMAIL PROTECTED]> writes: > If it's the latter, I maintain that this is precisely the subject matter of > the proposed GR; we obviously *don't* have agreement in Debian over what > should or should not be considered a "program", so I think that's begging > the question. However, your proposed amendment declares that "firmware" should not be considered a program. Can you please tell me what "firmware" is? I've seen a half dozen definitions tossed around recently, and I haven't a fig of a clue which one you mean: 1) A program which runs on a peripheral processor 2) A program which is distributed by the hardware manufacturer 3) A program which is controlled by the hardware manufacturer 4) A program which runs out of NVRAM or ROM instead of RAM 5) A program which, if you change it, voids the warranty for the hardware on which it runs, 6) A program which is necessary to support a piece of device hardware and for which we don't happen to have source I can't properly evaluate or think about this amendment while this rather crucial element remains unresolved. Also, it would seem very bizarre to say "a program which ... is not really a program", so can you find a wording in which you don't define firmware as a particular sort of program, only to then declare that programs of that sort aren't really programs at all? > Yes, these are reasonable definitions of both "program" and "firmware." What is the definition of "firmware" which you are using? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Concerns with Open/OS Corporate Linux ads?
Hello, > It calls our distro "reliable and secure" and states that they add > "maturity and corporate readiness". Then they go on to state that > Debian is > > - reliable > - secure > - upgradeable > - integrateable > - preconfigured > - remotely administratable > > and that they add support and maintenance, which adds the features > > - reliable release cycle > - newest packages > - security team > - preselected packages > - security administration > - certification > - software tests [..] > - we have our own security team That isn't negated by their add, in fact they state that Debian is secure. And Debian has lacked security support for new software for a long time (I believe testing is supported now). > - we have preselected packages (tasks) Well, but they probably have others, focused on the business domain. > - we are definitely ready for the business world > (I know what they mean, I guess) I would debate that. Sometimes companies simply need to pay money for a product to have someone to blame. Debian is volunteer driven, and thus noone can be put under any real pressure. For companies it is sometimes better to pay for the service and thus have someone who is responsible for that. In fact I would see the security team statement in that light, they provide security support for money and thus probably guarantee that updates are prepared in a certain time frame. > and since their ad is entitled "Debian of full age", it kind of > suggests that Debian per se is immature, a child, an assertion I'd > strongly oppose. Well, I would be to hard on that. Being young does also have its benefits :-) > Should we do anything about this? If so, what? I do not think that Debian as a whole should take action, but you could sent an email to them and tell them that they've hurt your feelings (and you, as opposed to me, form a part of Debian). Perhaps they'll act on your criticism. Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Concerns with Open/OS Corporate Linux ads?
Hi, I am holding in my hands the 09/06 copy of the German Linux Magazin, and on page 76, opensourcefactory.com has advertised Open/OS Corporate Linux [0], which apparently makes Debian "mature". 0. http://www.open-os.com/cms/index.php?page=Home It calls our distro "reliable and secure" and states that they add "maturity and corporate readiness". Then they go on to state that Debian is - reliable - secure - upgradeable - integrateable - preconfigured - remotely administratable and that they add support and maintenance, which adds the features - reliable release cycle - newest packages - security team - preselected packages - security administration - certification - software tests the result is Open/OS Corporate Linux, which is thus - stable - secure - business-oriented While I applaud their efforts and I think it's exceptionally great how they are open about Debian forming the basis of their product (!), the ad also leaves a weird aftertaste, specifically because - we have our own security team - we have preselected packages (tasks) - we are definitely ready for the business world (I know what they mean, I guess) and since their ad is entitled "Debian of full age", it kind of suggests that Debian per se is immature, a child, an assertion I'd strongly oppose. I'd be interested in what people think. Am I just overreacting? Should we do anything about this? If so, what? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck http://debiansystem.info `- Debian - when you have better things to do than fixing systems if loving linux is wrong, i don't want to be right. signature.asc Description: Digital signature (GPG/PGP)
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 11:00:44PM +1000, Hamish Moffatt wrote: > To those who consider ROM-less hardware cheap and nasty I suggest the > opposite is true. I design hardware (FPGAs) professionally for expensive > communications equipment. We avoid ROMs as much as possible, because > they are difficult to upgrade reliably and they are a waste of money. > > We deliberately load our FPGAs with different functionality at different > times and that isn't possible from ROM. The emi62.c sound driver seems > to do something similar - it loads different firmware for midi and spdif > modes! Very interesting. Do you consider FPGA config files as programs, or would you say that the normal DFSG requirement for source applies to those also in order to be considered fit for debian/main ? I am interested in your profesional opinion on this, since you clearly seem to either be, or in close contact to someone who is, an upstream author of such firmwares. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 08:03:39PM +0100, Mark Brown wrote: > Within a Debian context people normally seem to use the term "firmware" > to mean any binary blob that gets programmed into hardware. This could > include things like register settings or FPGA images as well as programs > to execute on embedded processors. I'm not sure if there are any > instances of these other types in the upstream kernel, though. FWIW (and a few days late) I did some searching for drivers in the kernel (2.6.17.11 from kernel.org) which refer to FPGAs and found the following: drivers/usb/atm/ueagle-atm.c drivers/media/video/bt8xx/bttv-cards.c sound/pci/vx222/* sound/pcmcia/vx/* sound/pci/pcxhr/* sound/pci/mixart/* sound/drivers/vc/* -- These load image via the standard kernel interface (hotplug) drivers/media/video/stradis.c drivers/net/wan/lmc/* -- Loads FPGA image supplied by an ioctl drivers/net/hamradio/yam.c -- Loads firmware from const arrays in yam*.h drivers/net/pcmcia/smc91c92_cs.c -- Loads firmware from const array in ositech.h drivers/usb/misc/emi26.c, emi62.c -- Loads firmware from const array in emi26_fw.h / emi62_fw*.h drivers/isdn/hardware/eicon/* -- Loads firmware from file directly (?) drivers/media/video/dabusb.c -- From file I think. Driver is confusing. arch/sh/boards/overdrive/fpga.c -- Loads from missing file To those who consider ROM-less hardware cheap and nasty I suggest the opposite is true. I design hardware (FPGAs) professionally for expensive communications equipment. We avoid ROMs as much as possible, because they are difficult to upgrade reliably and they are a waste of money. We deliberately load our FPGAs with different functionality at different times and that isn't possible from ROM. The emi62.c sound driver seems to do something similar - it loads different firmware for midi and spdif modes! Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
