Logo Umeet2000

Presentación

Registrarse

Programa

Desarrollo

Participación

Normas para los autores

Comité de Honor

Comité Organizador

Comité Científico

Comité Técnico

Patrocinadores

Servidores espejo (mirrors)

Noticias

Recortes de prensa,enlaces


Charlas 9/12/2000

Log de la conferencia. Se han suprimido las líneas correspondientes a entradas y salidas de diferentes personas en el canal durante la conferencia

[22:10] Ricardo> We're pleased having here with us 4 persons from Conectiva:
[22:10] Ricardo> Guilherme Wünsch Manika (gwm)
[22:10] Ricardo> Elvis Pfutzenreuter (epx)
[22:10] Ricardo> Andreas Hasenack (andreas)
[22:10] Ricardo> Arnaldo C.de Melo (acme)
[22:10] Ricardo>
[22:11] Ricardo> They're going to talk us about the recent developments in Linux Based Operating System
[22:11] Ricardo>
[22:11] Ricardo> So, if you're ready, guys... :)
[22:11] gwm> Ok, so this is the time where someone has to do the talking :)
[22:12] gwm> We work for Conectiva, which develops a Linux distribution.
[22:12] gwm> This talk is by no means Conectiva-specific, it's only a coinscidence that we all work here ;)
[22:13] gwm> We'll discuss a bit about the future of Linux distributions, both from a technical point of view and the position in Linux companies will have to adopt in order to survive.
[22:14] gwm> acme is a Conectiva founder, and kept the hat as mantainer for the earliest versions of CL. He's now a CTO (I think :))
[22:14] acme> yap, so they say :)
[22:15] gwm> epx likes KDE, remote file systems and bunch of other cool stuff - he'll talk about what he's doing during the talk, you'll certainly be amused :)
[22:15] acme> maintained the distro from our first to the third version
[22:15] acme> then moved to some more boring things ;)
[22:16] gwm> andreas is our security guy, he issues all the updates and makes sure the distro is hacker proof and all
[22:16] gwm> And I am a mantainer and packager :)
[22:17] gwm> acme will talk a bit about history, then we move to more interesting stuff :)
[22:17] acme> ok, I'll talk a little bit about the motivations for Conectiva doing a linux distribution
[22:17] acme> back in the old days, 1995 IIRC, brazilians had some difficulties to get CDs with Linux
[22:17] gwm> #qc should be used for general discussion, ask questions if you wish; we'll try to answer all on-topic questions.
[22:17] acme> and internet conectivity is only now getting to a point where downloading a distro is something feasible
[22:18] acme> also english is not something that everybody knows
[22:18] gwm> (s/hacker proof/cracker proof/, as someone corrected me :)
[22:18] acme> we worked mostly as a consultancy company
[22:19] acme> doing work for lots of ISPs and other companies that wanted internet conectivity
[22:19] acme> we used Linux for mostly everything
[22:19] acme> initially using Slackware
[22:19] acme> the Red Hat, back in the RH 3.0.3 (aka picasso) days
[22:20] acme> the change was motivated by... packaging made easy
[22:20] acme> in other words: RPM
[22:20] acme> RH didn't had some of the packages we needed, so I started learning RPM packaging
[22:20] gwm> riel: do it
[22:21] acme> things got easier for us, that had to maintain dozens of ISPs and other customers
[22:21] acme> ok
[22:21] acme> but we wanted to make it easier and customers wanted a boxed set of the things we were installing...
[22:21] acme> ok, learned how Red Hat was built
[22:21] acme> and then we had something, A CD and a small manual
[22:22] acme> and something important for lots of people: translations
[22:22] acme> we've started translating things that were already internationalized
[22:22] acme> then started contributing with the free software community sending patches, making programs internationalized, etc
[22:22] acme> then we started selling the boxes and people seemed to like
[22:23] acme> from that point we started to do more and more modifications in our Red Hat based distro
[22:23] acme> things like internationalization, adding more packages
[22:23] acme> including crypto packages not found in the mostly north american made distributions
[22:24] acme> and from that point: training, support, consultncy
[22:24] acme> now we're a Linux company and we're struggling to make the best possible distribution
[22:24] acme> sticking to free software, making all of our modifications and new programs available to the community
[22:25] acme> things like apt with RPM, XFree86 video drivers, linuxconf improvement and new modules to make configuration easier
[22:25] acme> and reliable for more and more people to be able to use all this marvelous software developed cooperatively
[22:26] acme> and paying full time kernel hackers like Rik van Riel, Marcelo Tosatti
[22:26] acme> funding development in high availability
[22:26] acme> fixing kernel drivers, etc
[22:26] acme> well, I think I have talked too much already :)
[22:26] acme> gwm? andreas? epx?
[22:26] acme> :)
[22:27] epx> ok
[22:27] epx> can I begin ?
[22:27] gwm> I'd like to point out that RPM was a very important early decision, though I don't know if it was very conscious at the time :)
[22:27] gwm> epx: go ahead
[22:27] acme> gem: conscious, you can bet on it :)
[22:28] epx> ok. I will talk about some issues of using Linux in desktop (v.g. KDE2, sound servers, CUPS) and about a new initscripts scheme
[22:28] riel> ADMIN: if anybody has questions ... please ask them in #qc
[22:29] epx> linux in desktop is a big issue these days.
[22:29] epx> it is quite well in the server market, but the adoption in desktop is growing more slow than some people expected.
[22:30] epx> the most important issue is a desktop environment standard.
[22:31] epx> most technical people use some window manager (e.g. windowmaker) but to deploy linux to "normal" users something more elaborated is needed.
[22:33] epx> KDE and GNOME are the softwares that are nearest in offering such friendly environment to users. I will talk more about KDE but most advances of it are equal for GNOME.
[22:33] epx> first, obvious one is a standard, constant interface to users.
[22:34] epx> second, not so obvious, is a standard environment/API for applications, because leaving the programmer with X and POSIX alone makes deploying of e.g. corporate programs much harder.
[22:35] epx> third is a component architecture that allows reusing of graphical parts (like KDE::KParts)
[22:37] epx> so, the adoption of the Linxu in desktop, even in corporate environments (where there is some degree of tech support, so users don't/can't install their own machines etc) depends much of the development of programs such KDE and GNOME.
[22:38] epx> Another (really annoying) thing about using Linux in desktop is the printer support.
[22:39] epx> the BSD printer spoolers (e.g lpr, LPRng) do their jobs well but are not really made for end users.
[22:39] epx> they are made for high-volume printing. Example: if you have a printer with
[22:40] epx> 3 possible resolutions, 2 ink economy modes and 4 possible paper sizes, you could
[22:40] epx> end with 2*3*5=30 spooles for just one printer, since lpr does not allow for "run-time"
[22:41] epx> specification of such things. Unless you write your own driver and embed commands in the
[22:41] epx> data, what is hardly possible.
[22:41] epx> CUPS reimplements the spooling system from scratch, and the most important differential (for the end user)
[22:42] epx> is that the representation of every printer meets the "physical" printers
[22:43] epx> so when user wants to print something he will be able to choose which resolution, paper type etc.
[22:43] epx> and most important for we developers, our applications can have a callback of what the user wants to do. BSD printing has nothing near this, and CUPS implements this in the core protocol/AP.
[22:44] epx> s/AP\./API/ sorry ;)
[22:45] epx> so we really believe that CUPS is the future of printing - for the desktop. and, we now that "who owns desktop, may own the servers" in the market out there, so CUPS can
[22:45] andreas> some people like to have many ways to do the same things
[22:45] gwm> (even if cups is so great, it's a bit of a hassle if not everyone adopts it at once, though)
[22:45] epx> well capture the BSD spool "market", also ;)
[22:46] andreas> there is still work to be done with printing
[22:46] gwm> caliMan25> but cups is not free!!! i mean some drivers... do you have any alliance with this company, who developed cups?
[22:46] andreas> putting things on paper is a big step
[22:46] gwm> epx, please...
[22:46] epx> Anyway, the two options will coexist for a long time. An initial problem with CUPS is the lack of free drivers. (There is a commercial package with drivers)
[22:46] andreas> but there has to be a better application support
[22:46] andreas> and drivers, of course
[22:47] epx> This is steadily changing, so CUPS become a viable alternative to free software community.
[22:47] epx> A last note about CUPS is that
[22:48] epx> it presents a stable API for drivers, too, so we may see printer companies distributing binary drivers in the future.
[22:48] epx> (ok, binary drivers are evil, but ... ;)
[22:49] epx> Both KDE and GNOME present a sound server. It is a software that acts like a 'broker'
[22:50] epx> between sound applications and the physical sound device.
[22:50] epx> The most important function of a sound server is to create the possibility of mixing sound stremas. Example: you are playing MP3 but
[22:50] epx> wants to remain able to listen to system notifications or events.
[22:51] epx> Since the multimedia/sound softwares are every day making more use of the DSP (audio) channel, and less use of MIDI and CD-audio,
[22:52] epx> the sound server is not an amusement anymore but a need.
[22:52] epx> the big issue about sound servers is the legacy applications. they try to open /dev/dsp directly i.e.
[22:53] epx> will not try to use the soundserver. Both esound and aRts (GNOME and KDE soundserver, respectively)
[22:53] epx> have a hack to allow legacy applications to play sounds via soundserver. Both hacks use
[22:54] epx> LD_PRELOAD stuff (put a "trap" in open(), close(), write()... functions), so the
[22:54] epx> hack is not that clean and will not work with some applications.
[22:55] epx> So, we see all Linux distributions struggling to make its sound applications work under sound servers
[22:55] epx> and patching the open source apps. (Some, of course, can't be patched, and are still too important to be ignored e.g. RealPlayer)
[22:56] epx> well, these are the things about desktop. Questions can be made at #qc. Now we are gonna talk about initscripts.
[22:56] epx> everybody recognizes that SystemV initscript style has its merits but needs a lift-up. In particular,
[22:57] epx> creating DEPENDENCY relations between services. I.e. if the user start a service that needs another,
[22:57] andreas> like NFS and portmap
[22:57] epx> the latter will also be started without explicit user intervention.
[22:58] epx> yes. NFS needs portmap, portmap needs network, network needs pcmcia if pcmcia is available.
[22:58] epx> but user sees only NFS>
[22:58] epx> so something like "initservices start nfs" should start the others.
[22:59] epx> And, if I enable NFS for the current runlevel, the other ones must come automagically.
[22:59] andreas>
[19:48:21] claviola> @epx> but user sees only NFS>
[22:59] andreas>
[19:48:28] claviola> nao seria bom se os usuarios vissem tudo?
[22:59] gwm> And there's also the issue about parallel execution of init scripts, which may greately improve the time it takes to boot the machine.
[22:59] gwm> SysV doesn't have room for that.
[22:59] epx> gwm: well remembered.
[23:00] epx> Some people have proposed new schemes. Richard Gooch's LSB (linux boot scripts) is the most well-know one
[23:00] gwm> claviola: the user sees all; he doesn't have to care about every minimal low level detail. This is what dependency is all about.
[23:01] epx> Andrew Clausen has another, and we are also working in a scheme.
[23:01] epx> all the 3 implement full dependency tree, dependency loop detection and multithreading.
[23:02] epx> multithreading brings us another net advantage: speed up in the boot process
[23:02] epx> a lot of people complain (with good reasons!) that initialization in linux could be faster.
[23:03] epx> and most initscripts activities demand waiting, not CPU.
[23:03] epx> But multithreading can only happen if we have a dependency tree, so these 2 things need to appear together.
[23:03] andreas> epx: claviola says: you (epx) said that the user would only see NFS being started, and not portmapper, network, etc. Shouldn't the user see all that's happening?
[23:03] epx> (e.g. we cannot start smb if network is not finished)
[23:03] epx> andreas: gwm has answered that.
[23:04] epx> and multhithreading justifies the dependency tree, as I have just said.
[23:04] epx> Gooch's and Clausen's schemes aim for something completely new
[23:05] epx> that is clean for "vi admins" (i.e. power users/admins that use vi or emacs do administrate the system) to cope with.
[23:06] epx> these two schemes do not aim any compatibility with legacy applications and packages made for SystemV-initscritpts sytems
[23:06] epx> our scheme aims for compatibility, so it will still work even if admin has to install some old package that
[23:06] epx> puts a SystemV script in /etc/rc.d/init.d.
[23:07] epx> The LFS (is this the acronym?) comittee is working in this issue too.
[23:07] epx> everybody knows that *something* has to change, and multithreading and dependency tree must walk in, and we can expect the distributions to adopt some scheme in the next months.
[23:08] epx> Indepdendent of the scheme LFS chooses or implements, I am sure it will make all our lives easier and better ;)
[23:09] epx> ok. that's it. time to go to #qc I guess ;)
[23:09] > plas plas plas plas plas plas plas plas plas plas
[23:09] > clap clap clap clap clap clap clap clap clap clap
[23:09] > plas plas plas plas plas plas plas plas plas plas
[23:09] > clap clap clap clap clap clap clap clap clap clap
[23:09] > plas plas plas plas plas plas plas plas plas plas
[23:09] > plas plas plas plas plas plas plas plas plas plas
[23:09] > clap clap clap clap clap clap clap clap clap clap
[23:09] > plas plas plas plas plas plas plas plas plas plas
[23:09] > clap clap clap clap clap clap clap clap clap clap
[23:09] gwm> Shall we move to package management? :)
[23:09] gwm> Thank you, epx.
[23:10] gwm> Well, as you all know, Conectiva has recently "ported" apt to work with rpm packages.
[23:10] Ricardo> Go on gwm :)
[23:10] gwm> apt was Debian's most visible marketing point.
[23:11] gwm> rpm has a few perceived problems, and a few of them has been mentioned on #qc
[23:12] gwm> People perceive rpm packages have poor quality; or are too messy, and they think --force has to be used too often
[23:13] gwm> It doesn't have to be like that. rpm packages and deb packages and all the rest have more common points than most people think.
[23:13] gwm> Debian's legendary packaging quality comes from a strong commitment to policy.
[23:13] gwm> It's not .deb that makes it better, though it has a few features (and lacks a few others)
[23:14] gwm> We were recently forced to review our practices in order to make our distribution apt friendly
[23:15] gwm> We noticed a few things while we did that, and before we decided to go the apt way.
[23:15] gwm> rpm has a few features that work a bit different from deb packages.
[23:16] gwm> For exemple, everyone has already seen a package request something like 'libfoobar.so.1' instead of a "foobar" or whatever the real package is called.
[23:16] gwm> This kind of dependency (we call it automatic dependency) is detected while the package is generated, and works just like virtual packages.
[23:17] gwm> It's really a "Provides" that is automatically added to the rpm header.
[23:17] gwm> This is a great feature of rpm IMO, but it's often misunderstood.
[23:17] gwm> rpm, unlike deb packages, do not come from a single source
[23:17] andreas> you don't have to say that WindowMaker, for example, depends on glibc.
[23:18] gwm> andreas: right, it has to do with how practical it is to generate packages that won't break
[23:19] gwm> Well, anyone could start their own .deb-based distro today *but* there are only a few .deb-based distributions.
[23:19] gwm> Corel and Storm Linux come to mind
[23:19] gwm> Much of the perceived rpm mess comes from the fact that there are many vendors that create rpm packages.
[23:19] Ricardo> gwm: Progeny ;)
[23:20] gwm> Progeny too
[23:20] gwm> Progeny and Storm, I understand, want to keep Debian compatibility though
[23:20] gwm> So they don't work as examples for the kind of effect the RPM world has
[23:21] gwm> Automatic dependencies and files-based dependency are the common ground between Linux distributions until a real standard is published
[23:21] gwm> However, they have that negative effect on users: they don't know where these dependencies come from.
[23:22] gwm> Red Hat and Mandrake include a "rpmdb" package that contains a full rpm database for dependency-solving. This was considered in the past, but it's not much more than a kludge.
[23:23] gwm> The user still has to go through dependencies by himself.
[23:23] gwm> And that's not good, and does not solve another problem: "How do I keep my system up to date?"
[23:24] gwm> andreas has a lot of work to do keeping the distro secure, but the user still has to make sure his system is secure.
[23:25] gwm> So there must be a practical way to keep the user's systems up-to-date. Security must be EASY.
[23:26] gwm> The RPM apt port includes a feature apt didn't have. It's being integrated now to the official tree.
[23:26] gwm> Digital signatures.
[23:27] gwm> We depend on mirrors to make our distro available to our users. No way our ftp server can handle all the traffic they would generate :)
[23:27] gwm> But then, ftp sites could be invaded, and broken repositories could be set up. We didn't want to make apt a cracker-friendly way to distribute exploits :)
[23:28] gwm> So, with apt we solve a bunch of problems.
[23:28] gwm> 1) Our users don't have to deal with dependencies.
[23:28] gwm> 2) Our users can keep their systems up to date.
[23:28] gwm> 3) Our users can be sure their systems are being updated with trusted packages
[23:29] gwm> 4) Our users have a standard way to do all of the above
[23:29] gwm> We could have gone our own way. We could have "Conectiva Magic Updater(tm)" but we chose not to do so.
[23:29] gwm> apt was there; it was good; it was robust; it was stable; it was well-known
[23:30] gwm> Many people use it daily.
[23:30] gwm> So there going our own way would be stupid. Maybe if we were rules by the marketing department, we'd have "Conectiva Magic Updater(tm)" :) But this is not the case. We have chosen to make a difference to the Linux community.
[23:31] gwm> apt is THE most important cross-package format tool today.
[23:31] radtke> gwm: and it was gpl, as RMS said: a good programmer is that who reuse the code.
[23:32] gwm> deb and rpm together cover virtually all of the Linux users.
[23:32] gwm> There's still Slackware, but I believe they'll move to rpm soon.
[23:32] gwm> Now, this is really important. I just read somewhere that id wasn't making their next Quake game available for Linux on retail
[23:33] gwm> The will still have a binary-only unsupported LinuxQuake, but it's not what we as Linux users want.
[23:34] gwm> Their complaints boil down to one issue: there's not much inter-distribution consistency in the Linux world.
[23:34] gwm> There's, however a sincere effort by Linux distributions to change that.
[23:34] gwm> At least most of the serious Linux distributions :)
[23:35] gwm> The LSB was formed to create a real standard ISVs can trust on.
[23:36] gwm> Something reliable. Not some "Foo Bar for Red Hat Linux" thing.
[23:36] gwm> They are working now to define a common subset between rpm and deb that ISVs could use to ship distribution-independent software.
[23:37] gwm> This will be probably a subset of RPM version 3, btw.
[23:38] gwm> Now, imagine if you could install a rpm package on your Debian systems, and vice versa :)
[23:38] gwm> apt can play a role on this.
[23:39] gwm> With apt and rpm, we have a sixth advantage:
[23:39] gwm> 6) Differences between rpm and deb have been brought to light
[23:40] gwm> This is extremely important. Alfredo Kojima and Jason Gunthorpe have written a proposal for the rpm subset I mentioned.
[23:41] gwm> This is being reviewed by a LSB taskforce, and it's also the most important documentation on the issue today, I believe
[23:42] gwm> I think people now understand better a few misconceptions about rpm and apt
[23:42] gwm> RPM apt is great; and it has a lot of potential.
[23:43] gwm> We have been using it for our distro. It's made us rethink our way of work.
[23:43] gwm> With apt, our packages have more quality than ever. Update-when-you-wish is something that didn't exist before; now it's here.
[23:44] gwm> With the old model, users bought CDs every six months and updated it all at once.
[23:44] gwm> Minor problems with upgrades were often forgiven; but nobody needs to acccept that.
[23:45] gwm> It must be possible to update your Linux system now, without having to sit in front of your computer during the process, if possible.
[23:46] gwm> As I said, Conectiva didn't write a "Conectiva Magic Updater(tm)". We have chosen the open way.
[23:46] gwm> This is how the Free Software community works.
[23:46] gwm> So we belive other RPM-based Linux distributions can adopt apt now.
[23:47] gwm> We had problems with packaging quality, and they will have problems too.
[23:47] gwm> They will wake up and smell the napalm and notice that their system is not as flawless as users wished.
[23:48] gwm> or needed
[23:48] gwm> So, with RPM apt I believe there's another big contribution to the Linux community:
[23:48] gwm> 7) RPM apt will raise the bar for Linux distributions
[23:49] gwm> No longer will attended updates be acceptable (unless it's absolutely needed). No longer will a broken system after upgrade will be acceptable.
[23:49] gwm> No longer dependency hunting will be acceptable.
[23:50] gwm> Maybe it's time to answer a few questions? :)
[23:50] gwm> Please, ops who have been following #qc more closely and found interesting questions, help me :)
[23:51] andreas>
[20:00:42] claviola> i hope this is a valid question: since debian doesn't include a way to remove the task packages' dependancies after they are installed, forcing the user to remove them by hand, I would like to know if the Conectiva staff is working on this issue.
[23:51] gwm> task is a special kind of package. I think I like the Debian way.
[23:52] gwm> Of course, this means we have adopted task- packages like Debian's :)
[23:53] gwm> Oh, yes, there are a few things we like about debs that we'd like to see in rpms.
[23:54] gwm> Delayed configuration is the most important one, I think. Debian first installs everything, and then configures the hole batch.
[23:54] gwm> This is great if the user has requested attended installation.
[23:54] acme> http://linuxtoday.com/news_story.php3?ltsn=2000-12-09-008-20-NW-CY
[23:54] acme> sorry
[23:55] gwm> This is a very important functions Debian has in the community: it is the watchdog of commercial vendors.
[23:56] gwm> I won't go as far as saying Debian and your preferred commercial vendor here> compete in the same market.
[23:56] andreas>
[20:24:55] kov> what about the high quantity of rpm kinds? will fhs make 1 of them the default? won't it make the distributors unable to implement new things needed to improve apt for example?
[23:57] gwm> But Debian has a tradition of high quality all commercial vendors should try to copy.
[23:57] gwm> I though I had answered kov's question when I say it would probably be a subset of RPMv3
[23:58] gwm> BTW, the format is a subset. It still allows extensions.
[23:58] gwm> But a fully LSB-compliant package cannot requires something that is not on the standard.
[23:59] gwm> Dependencies, filesystem and such will all be covered by LSB. Filesystem is already here - distributions have really jumped into the adoption of FHS.
[00:00] gwm> I believe part of the standardization process will come from the fact that Commercial Linux Distributions have parent companies; and these companies will have to change their business model (if they didn't already)
[00:01] gwm> There's far more cooperation among distributions then you'd expect. Users love to play say "My distro is better than yours" but even though there are companies, and money, and everything, it's still a community.
[00:01] gwm> Behind the marketing people, there's a bunch of techies not unlike yourselves :)
[00:02] gwm> But the real hit will come when even marketing people won't care about the distributions.
[00:02] gwm> With public Linux companies' low stocks value, it's pretty obvious nobody will survive only because they have a distro that everybody uses.
[00:03] gwm> As Linux distributors become support companies, there'll be no need to rush things as things are rushed today, except to better suit the comapanies' customers.
[00:04] gwm> Even Mandrake, which I thought was the most sales-oriented company has announced it'll be changing its business model.
[00:05] gwm> I think that even this kind of development (distributions becoming less important) is a great step forward for the Linux platform as a stable computing environment
[00:06] gwm> Things have been too rushed lately :) It won't be so in the future.
[00:07] gwm> ISV pressure, users' pressure (keep your expectations up!) and the changing business model of Linux companies promises a bright future for Linux as something to rely on, be it in you server, your grandmother's desktop or on your watch :)
[00:07] gwm> If there are no more questions, I can stop here :)
[00:08] gwm> Maybe andreas can clarify some security-related issues raised on #qc?
[00:10] andreas> people asked about this new feature: a signed hashfile
[00:10] andreas> this is being added to the mainstream apt as well
[00:10] andreas> apt deals with repositories, not exactly individual files/packages
[00:11] andreas> a repository is a collection of packages with or eve without dependencies between them
[00:11] andreas> until today, only md5sums were used to check these packages
[00:12] andreas> if someone breaks into an ftp server, for example, he/she can put a trojaned package there and fix the new md5sum
[00:12] andreas> so that everything looks ok
[00:12] andreas> RPM has support for signed packages for a long time now
[00:13] andreas> so, putting a trojaned RPM means breaking the signature
[00:13] andreas> but apt deals with whole repositories, it doesn't check the signature of each package
[00:14] andreas> instead, there is a file called hashfile which lists the files which in turn lists all files available in that repository
[00:14] andreas> for example, pkglist.main (a binary file) has all the necessary information for apt to do its magic
[00:14] andreas> including the md5sum of each package
[00:14] andreas> each repository has also a source pkglist, so we have now srclist.main as well
[00:14] andreas> two files
[00:15] andreas> these two files are listed in a third file called hashfile which has their md5sum
[00:15] andreas> and this hashfile is what becomes signed
[00:16] andreas> so, if someone changes a package, he/she would also have to change the md5sum in pkglist.main and in the hashfile which lists pkglist.main
[00:16] andreas> with a signed hashfile, such tampering would be detected
[00:17] andreas> when a user runs apt-get update, first the hashfile (signed or not, the user has the option) is downloaded
[00:18] andreas> if the signed file is corrupt (i.e., tampered with), apt stops
[00:18] andreas> if everything is ok, it checks the md5sum of the pkglist files (pkglist.main, srclist.main, etc) and, if it has changed from whatever
[00:18] andreas> apt had locally, it fetches the new files as well
[00:19] andreas> no digital signature check is made on the package itself, although one can still use rpm -K to check it (in the case of signed RPM packages)
[00:19] andreas> only its MD5SUM is checked by apt against the signed hashfile
[00:21] andreas> apt is really a very important tool regarding security updates, it has made my life easier, both as a maintainer and as a home user
[00:21] andreas> what exactly does signing a repository mean?
[00:21] andreas> this whole discussion about signing packages is about trust
[00:21] andreas> you have to choose to trust the author of the package, or you have to inspect it yourself
[00:21] andreas> the same for the repository
[00:23] gwm> kov> I'd like to know about the development of a graphical front end for apt... is it being done by conectiva?
[00:24] andreas> Kojima is working on raptor, but he will have to change the name unfortunately...
[00:24] gwm> apt-supporting tools are still a bit Debian-specific.
[00:24] gwm> Claudio Matsuoka has ported a few of those, including aptitude, apt-listchanges...
[00:25] gwm> When the time for Raptor comes, there'll probably be a more stablished common ground, so yes, it'll most certainly work with Debian too.
[00:26] acme> kov> why will kojima need to change raptor's name?
[00:26] acme> there's already a product
[00:26] acme> by Sun, IIRC
[00:26] andreas> it's already used on another product
[00:26] acme> for firewalls
[00:26] epx> axent raptor
[00:26] gwm> Raptor is too obvious :)
[00:26] andreas> yes, firewall
[00:27] gwm> Though it would be cool. We can have other names, though, like inapt, if it doesn't work as well as we'd like :)
[00:28] gwm> acme, epx, andreas, comments?
[00:29] gwm> (it's been 2h30 since it started... I wasn't looking at the clock, time runs :))
[00:29] acme> :)
[00:29] acme> well, I think that the ones that have remaining doubts are welcome
[00:29] acme> ...
[00:30] acme> at the channel #conectiva in irc.openprojects.net
[00:30] > plas plas plas plas plas plas plas plas plas plas
[00:30] > clap clap clap clap clap clap clap clap clap clap
[00:30] > plas plas plas plas plas plas plas plas plas plas
[00:30] > clap clap clap clap clap clap clap clap clap clap
[00:30] > plas plas plas plas plas plas plas plas plas plas
[00:30] > plas plas plas plas plas plas plas plas plas plas
[00:30] > clap clap clap clap clap clap clap clap clap clap
[00:30] > plas plas plas plas plas plas plas plas plas plas
[00:30] > clap clap clap clap clap clap clap clap clap clap
[00:30] acme> were we informally maintain a channel where conectiva developers hang around
[00:30] gwm> Maybe we can have some chat now, if people don't feel like kicking us out for taking their channel for this long :)
[00:30] acme> :)
[00:30] acme> yap
[00:30] kov> I would like =)
[00:30] kov> heheh
[00:30] acme> trow the stones! oops, the questions!
[00:30] acme> :)
[00:30] > THANK YOU VERY MUCH!!
[00:31] gwm> All those issues raised in #qc but which were inappropriate at the time, please, ask them now :)
[00:31] > tomorrow we have the next conferences:
[00:31] acme> MJesus: I, in name of Conectiva, thank all people involved in this debate for making this possible, keep it up!
[00:31] > :)))))
[00:31] t00R> i'd like to know if redhat and others are taking these changes your making seriously
[00:31] acme> t00R: difficult to sy
[00:31] acme> say
[00:32] gwm> t00R: jbj is on the apt-rpm mailing list, and he's contributed a bit. But we can't say for sure.
[00:32] > 19:== Nik Claiton, about frebsd
[00:32] acme> but RPM's maintainer is subscribe to the apt-rpm mailing list we maintain at conectiva
[00:32] > december 11, 19:00 Nik Claiton, about frebsd
[00:32] gwm> I believe Mandrake will be the first non-Conectiva vendor to take RPM apt more seriously, but it's a wild guess.
[00:32] acme> as are several Mandrake developers
[00:32] michele> very interesting chat. thanks guys!!!!!!!!!!!!!11
[00:32] > at 22:00 hours, Horacio Peña: Routing Policy
[00:33] > at 22:00 hours, Horacio Peña (Horape): Routing Policy
[00:33] acme> michele: you're welcome, thank you for staying here for so long :)
[00:33] t00R> i liked it too, thanks guys
[00:33] michele> no really..loved it!
[00:33] > thank you very much, and thank Conectiva Team by all !
[00:33] t00R> molto obrigado =)
[00:33] gwm> SuSE has a slightly different layout, so they may take longer if the wish to use apt.
[00:34] gwm> And SuSE has too many packages; it'll be difficult to make them all apt-ready.
[00:34] Neron> gwm: quanto tempo mais ou menos vcs demoraram para portar, até agora, o apt?
[00:34] gwm> Neron: Kojima works REALLY fast.
[00:34] gwm> He's a great programmer.
[00:34] claudio> btw, apt packages for redhat 6 and 7 are available at ftp://ftp.uibk.ac.at/pub/software/unix/linux/apt/
[00:35] Neron> gwm: alguma estimativa... só pra eu saber? :)
[00:35] gwm> Neron: he had basic apt-rpm working in one week :)
[00:35] kov> Neron said: how long will did you take to port apt?
[00:35] XFernando> why isn't alfredo here?
[00:35] gwm> Neron: it took a few months (2? 3? I can't count time :))
[00:35] kov> Neron said (2): any guess? Just for me to know
[00:35] claudio> XFernando: he's busy working on apt ;)
[00:35] gwm> Kojima was invited. Dunno why he's not here.
[00:36] gwm> Maybe he's too busy working while we merely talk :)
[00:36] andreas> I believe a couple of months.
[00:36] andreas> But much was done with our packages as well, not only apt.
[00:37] acme> Neron: I said, I want you to work on having apt working with rpms, two days later the first results were there
[00:37] acme> :)
[00:37] XFernando> wow
[00:37] acme> gwm: heh, people said that about Alan Cox as well
[00:37] Neron> acme: Cool! :)
[00:38] XFernando> that was fast =)
[00:38] acme> for him to be so short on his responses to patches, etc
[00:38] Neron> "Nossos japoneses são mais criativos que os Japoneses dos outros"
[00:38] acme> XFernando: not completely working, but showing that, yes, that was possible
[00:38] acme> :)
[00:39] > neron including fujimori ¶:Þ?
[00:39] claudio> experimental apt stuff is available at http://distro.conectiva.com.br/experimental/
[00:40] acme> MJesus: hey, he's back to japan ;)
[00:40] acme> and general information about most of the projects Conectiva employees are involved are in http://distro.conectiva.com.br
[00:40] acme> please take a look and consider helping!
[00:41] XFernando> acme, didn't you guys developed a XFree86 4.0 configurator?
[00:42] acme> XFernando: yap
[00:42] acme> pcpa (Paulo Cesar Pereira de Andrade) is member of the XFree86 team: paulo@xfree86.org :)
[00:42] Neron> will you release a Conectiva (beta) with kernel 2.4?
[00:42] gwm> And the VESA driver, which is the best thing since sliced bread.
[00:42] acme> gwm: nod
[00:42] acme> :)
[00:42] XFernando> is it already in the latest X distribution (4.0.1)?
[00:43] gwm> Well, there's apt too.
[00:43] acme> with XFree86 4.0 we don't have some of the drivers availabe in XFree86 3.3 series
[00:43] acme> because there were not enough volunteers to port all the driver for the older boards
[00:43] acme> so, with a driver for vesa this gap is mostly dealt with
[00:43] gwm> Baiscally the VESA driver works with reasonable performance with virtually all post-1980 video boards :)
[00:44] acme> hey, but it doesn't work with my MGA board! ;)
[00:44] gwm> It's not accelerated support, but I believe it's faster than VGA and it supports higher resolutions and more colours.
[00:44] acme> mmmkay, I can use aalib for that :D
[00:44] claudio> ouch! :)
[00:44] acme> using claudio's fantastic aacam!
[00:44] acme> :P
[00:45] epx> a text-based mirror :)
[00:45] acme> bye gwm!
[00:46] gwm> I usually hang out on #conectiva (openprojects) if somebody feels revengefull.
[00:46] acme> and thank you for you very good talk
[00:46] acme> heh
[00:49] riel> irc.openprojects.net #conectiva - home of Conectiva developers
[00:52] * MJesus ask an aplause for the tanslators: trusmis and t00r from Autralia and Spain
[00:52] > plas plas plas plas plas plas plas plas plas plas
[00:52] > clap clap clap clap clap clap clap clap clap clap
[00:52] > plas plas plas plas plas plas plas plas plas plas
[00:52] > clap clap clap clap clap clap clap clap clap clap
[00:52] > clap clap clap clap clap clap clap clap clap clap
[00:52] > plas plas plas plas plas plas plas plas plas plas
[00:52] > clap clap clap clap clap clap clap clap clap clap
[00:52] > plas plas plas plas plas plas plas plas plas plas
[00:52] > clap clap clap clap clap clap clap clap clap clap
[00:52] > plas plas plas plas plas plas plas plas plas plas
[00:52] t00R> thank you thank you =)
[00:52] acme> applause>
[00:52] byron> q isso
[00:53] trusmis> has been funny
[00:53] FaT^BoY> putzzz
[00:53] trusmis> but why my fingers are SO red ?
[00:53] Kerberos> plas plas plas
[00:53] Kerberos> plas plas plas plas plas plas
[00:53] Kerberos> plas plas plas plas plas plas
[00:53] fireman> clap clap:)
[00:54] > byron all the conference was tranlated to spaniss by Trsumis and T00r in the channel #media
[00:54] > plas plas plas plas plas plas plas plas plas plas
[00:54] > Atención: hora CET (Central European Time o GMT+1) equivale a +1 hora en Israel, -1 hora en Inglaterra, Portugal y Canarias, -3 en Curitiba (Brasil), -4 en Buenos Aires (Argentina), -5 en Venezuela, R.Dominicana y Caribe, 7 menos en Mexico DF, Peru, Panama, Colombia y Venezuela, 10 menos con el oeste USA, 12 mas en Australia y Nueva Zelanda....
[00:54] > plas plas plas plas plas plas plas plas plas plas
[00:54] > plas plas plas plas plas plas plas plas plas plas
[00:54] > clap clap clap clap clap clap clap clap clap clap
[00:54] > plas plas plas plas plas plas plas plas plas plas
[00:54] > clap clap clap clap clap clap clap clap clap clap
[00:54] > plas plas plas plas plas plas plas plas plas plas
[00:54] riel> trusmis! trusmis! trusmis! trusmis! trusmis! trusmis! trusmis!
[00:54] riel> t00r! t00r! t00r! t00r! t00r! t00r!
[01:06] Neron> Where can I find info about the raptor?
[01:06] riel> Neron: http://distro.conectiva.com.br/ (I think)

Y seguimos un buen rato más charlando...




Contact: umeet@uninet.edu