On Mon, 2007-05-14 at 14:55 +0200, Mgr. Peter Tuharsky wrote:
> Ask somebody, what distro would he install at desktop for novice or
> M$ refugee?
For me the choice is clear. I use Debian for myself. I choose to support
Ubuntu for people that do not want as many choices. This is what M$
refugees think they want. Ubuntu is channelized into a few "platforms"
as you put it. It has:
Ubuntu == GNOME Desktop Environment ("platform")
Kubuntu == KDE Desktop Environment ("platform")
Xubuntu == XFCE Desktop Environment ("platform")
Each is release accordingly to the "GNOME" release schedule, as that is
the driving force behind Ubuntu's release schedule. This release
schedule is 6 months.
> Why many are choosing Ubuntu instead of Debian, and even worse,
> abandon Debian in favor of Ubuntu?
The same reason many people choose Fedora Core or Mandriva or Gentoo or
<insert other distro> because they can. I abandon Debian for other
people, only because it has a (as you put it) more "friendly" support
system.
> Why do most people consider Debian to be user-unfriendly and
> server-oriented distro?
It is a misnomer that Debian is all about "elitism" or that it is hard
to install or that the developers/mailing lists don't speak "newbie-ese"
or that it doesn't support "new hardware" really well. I have to tell
you the only thing in that list that *might* be right is the hardware
thing for "stable". Stable... more on the stable/ testing/ unstable/
thing in a bit.
> Debian developers often see "Ubuntu the enemy" and are mocking it as
> inferior technology. However, they fail to see, what does the Debian
> really offer to desktop users eventually.
Sure, there is a bit of friction. Not "Ubuntu is TEH 3N3MY, 7HR0W R0XX
47 7H3M! D13! D13! D13!" or "Argh, there mateys, we be sailing up the
port side of the "Ubuntu", prepare the starboard side cannons!"
Nothing of the sort. Ubuntu and Debian have a tremendously different set
of motivators for releases and development.
Debian, is all about volunteers, free and Free software and
policy to implement them without much ado. This also has to
occur across 10 or so Hardware architectures at the same time.
Ubuntu, is all about volunteers, free and Free software, except
where is interferes with the release schedule and the "quality"
of the user experience. And it only supports three hardware
architectures. And apparently soon, only 2 as Apple dropped
PowerPC as an architecture. AND it is supported by a commercial
entity.
> They fail to understand, why are they using Ubuntu happily and
> reference it to novices. It seems, that desktop users don't see Debian
> fitting their needs. What are the means?
It is more about the fact that Ubuntu is indeed a niche OS. Debian runs
on a plethora of Hardware Architectures and is consistent across those
architectures.
> The answers:
> 1, needs
> 2, release cycle philosophy
> 3, community
> 4, priorities
>
> As many see, all of them are different in server and in desktop world,
> and many times Debian chooses to dictate the users "we know the best
> what You need" instead of listening to them.
Why then are there 28000+ packages in Debian? If Debian only dictates,
why then are there *FAR* more packages available for install than in
*ANY* other Distribution? How many Window Managers? How many alternative
packages to do the same thing, like word processing, editors, music
clients, rss feed readers, web-browsers? I could go on for days, but I
hope you get my point.
Come on, we know the answer, you can say it.
> Let's think a while about the current situation. First define, what I
> need from my _desktop_, being an ordinary power user:
>
> a, The system must work well with available hardware, automatically
> and "naturally"
This depends on *MANY* things. Primarily the Kernel. But also side
projects to deal with vendors that produce *WINDOWS ONLY* device
drivers. Case in point Wireless drivers. NDIS wrapper is a very good
attempt to cover this. There are other device manufactures that only
develop Windows drivers only. This is a case of "Why bother, Windows
cover 90%+ of the field"
> b, Stable without (too many) crashes
Do you realize Debian's stable is classified as this:
Stable means stable package list. No changes in API and ABI
names or versions. This means no newer versions will ever make
it into "stable". It is in "maintenance mode". This makes a very
good setup for those wishing for "Rock Solid" machines. Doesn't
crash. "too many" comes from the "Windows World", does not
typically apply to Debian's Linux.
> c, Applications should work generally
Okay, what specifically does not work in Debian? I have a few obscure
problems, but they are obscure. Currently in Sid, I have an xnest
problem, but it was only just introduced, will be fixed very shortly. I
don't see your "should work generally", mine just *DO* work.
> d, Applications should work together well
Again, if you are using a Desktop environment, they just DO. Even across
different Desktop Environments they typically work. Are you saying "Word
and Excel work just fine together"? Well then OpenOffice.org does this
just fine, it includes a Word Processor, Spreadsheet, other "office"
type applications. Again, I don't problem.
In fact, I use XFCE. If I click on a link in my e-mail client
(Evolution) it opens up my preferred Web-browser (Iceweasel). If I open
a "Word Document" in Iceweasel, it opens the doc in OpenOffice.org
writer. If I make a mailto link in Writer and click on it, it opens an
Evolution "new mail" interface. So, once again, I don't see your problem
here.
> e, The serious security problems should get fixed ASAP
Ever heard of Microsoft doing this? They sit on some problems for YEARS!
Some *HIGH* profile problems, sure they get it out by "Patch Tuesday".
Debian's Stable cannot introduce new versions. This complicates things.
It makes it tough, the security team has to "backport" the fixes from
the "new versions" and force the changes to not bump the ABI numbers.
This may seem trivial to you, but it is NOT. This is the only delay any
Security fix may delayed.
In general, security fixes for most Open Source projects and programs
are published within a few hours to a few days after the exploit/problem
is discovered. Far better than Microsoft does.
> f, Usability problems, wishes and bugs should get fixed too. I should
> be able to report a problem, participate on it's solution and see
> fruits of that.
Have you even looked at Debian's BTS? Unless your patch or bug is a
security related problem, it won't make it into "Stable". "Stable" is in
maintenance mode. Not in "New features or versions or additions or
design improvements" mode. That would be "testing".
> g, I _need_ the new features of some applications -for example
> improved import/export filters and so on, and I need them now, because
> yesterday it has been already late
Then compile it and install it yourself. If you need something bleeding
edge, then you will have to do it yourself. *NO* Linux distribution does
this.
> h, I wish to profit from Linux desktop progress -improvements on
> usability, features, design, performance and so on. I wish to show the
> Linux to friends with pride.
I do it everyday. My youngest daughter takes LiveCD from the Debian Live
project to school, everyday. She typically hands out 2-3 a day. The
school system contacted me about this possibly pirated "Linux" my
daughter was handing out as all the kids wanted to run it at home.
The threatened to report her to the Local Police and things like the BSA
(which is like the RIAA and MPAA, but for software). I said, please go
*READ* the licensing of the Debian LiveCDs
They called back and apologized, asked if they could keep the CDs they
confiscated from my daughter. I asked if they wanted more.
> We must make clear that:
> 1, Any distro is only as good as the software it offers.
So, with 28000+ packages in the Debian Repositories, what does this say
then?
> 2, Any software does, and will have, bugs.
Of course, many have yet to be discovered.
> ***** How does the Debian reallity look like ***
>
> a, Hardware support
>
> It depends mostly on version of kernel, X.org and some specialised
> libraries and programs (wpasupplicant, libgphoto, and so on).
> Generally, the newer is the said software, the better support.
> Some installation and autodetection tools are necesarry too -for
> example, if notebook is detected, then the desktop should
> automatically reflect that in order of power management, battery and
> sensor monitoring etc. In fact, the basic power management and sensor
> monitoring is getting traction on ordinary PC's and servers too, so
> there is no real need to separate the ntbk/pc/server platforms. Just
> the battery management is a special case.
Specialized? EVERYTHING in *NIX is specialized to do a few or one thing
exceptionally well. That is its history and legacy.
Auto-detection, we have udev, hal, automount and a slew of other thing.
> Debian is poor in both directions. The versions are old at start and
> ancient at the end of release cycle.
Again, STABLE means STABLE as far as API and ABI. Understand Stable is
not really aimed at "new whizbang" pieces. Never has been, it has been
aimed at "STABLE ABI and API" and well, stable running as well.
> The fast evolving hardware don't make much use of 2+ years old drivers
> (even if 3+ years old hardware is considered).
New exotic or *EXPENSIVE* hardware doesn't make it into the kernel for
years sometimes. Mainly because of the "Windows cover 90%+ of the markey
why bother." attitude many/most hardware vendors have.
> b, Stability
>
> It simply depends on, well, luck on choosing the particulary good
> version of software. With stable upstream versions of software, there
> should not be major stability issues anyhow.
>
> Debian proclaims to offer excellent stability. However, if some
> application does have stability issues, users must wait at least 2
> years for next "stable" version of Debian to see the fix. The
> stability is not automatically guaranteed by oldness of software and
> lack of upgrades in Debian.
Please give us example of these "stability" issues with applications.
Anything you care to REALLY share with us?
> c, Software should work generaly.
>
> As the software is kept in repositories for loong time, it should have
> been tested thoroughly when it gets in to stable. Then it remains at
> the same version for years.
But, security in Debian *IS* addressed in most cases. Sometimes when a
security exploit is in a common software installed on desktop machines,
these backports of the fixes from newer versions for exceptionally
complex software may take a while so as not to bump any API/ABIs in any
way. Barring being able to backport the fix without further compromising
the software, it may even be removed from the next revision of "stable".
> However, the security upgrades repeatedly caused software to stop
> working well in Debian, so the software version's rigidity dosen't
> really help much. It simply dosen't prevent software from breaking.
Security upgrade repeatedly? No. you are thinking of another distro.
Fedora and SuSE and Mandriva just include the latest software in the
release, which changes the ABIs abd API that Desktop Environments are
expecting to use and see. That breaks things. Not they way Debian does
security releases.
Do you even subscribe to Debian Security Announce?
> Current stable upstream versions of any software should not have major
> usability issues anyhow.
Current When? Stabilization periods are for vetting out the usability
bugs and security problems. What kind of Development cycle do you use in
your company? Code it, compile it and push it out the door?
> However, if there are major usability issues in software in Debian,
> should they have been fixed upstream, user must wait for next stable
> anyhow to see the fix.
Usability issue, you keep using that word as a magic statement. Debian
*IS* usable the instant it is released. It may have some errata. Does
Microsoft publish those things EXACTLY at release of a new Version of
Windows? NO. Not at all. Wait. How long was it between Windows XP and
Windows Vista?
> d, Software should work together
>
> As the software is kept in repositories for loong time, it should have
> been tested thoroughly when it gets in to stable. However, if the
> newer version of software offers new features that increase the
> interoperability with other software, user must wait for next stable
> to see it working.
You are confusing issues here. Just because something is in the
repository, does not mean it is USED heavily. And you are forgetting
what "satble" means in Debian. Stable mean it is in MAINTENANCE MODE. No
updates except for security updates or Bug fixes causing broken things.
> e, Security issues
>
> They are, and will be, found in any piece of software.
> Debian does endless work with backporting the patches to the software
> that is old and often unsupported upstream already. Patch is sometimes
> impossible to apply to such an old piece of software.
> Rumors say (accordingly to common sense), that some security bugs are
> never fixed inside release cycle of Debian because of that, even if
> the fix is available in newer upstream version of software.
Yep, some packages are removed from "revisions" of stable to remove real
exploitable problems if the software cannot be fixed. Usually though it
is something that is NOT modular and basically is compiled from HUGE
source and is monolithic. Woody's version of Firefox comes to mind, it
had backports out the wazoo, but those packports made the software
exceptionally quirky and subject to freezing and segfaults.
> Any security patch can affect the usability of software, either by
> backpatching an ancient "stable" version, or by installing the new
> fixed upstream version. I personally would prefer upstream fixed
> version, before the hacked-around-patch that tries to fit the ancient
> piece of software that the patch has not been created for originally.
Okay, so you are saying that "suppose" apache v2.2 have a severe
security exploit that forces the ABI to be bumped. Are you telling me
that you would rather Debian just compile the new version and publish
it? There by BREAKING 99% of the applications that work with apache2.2
and causing severe angst with companies delivering content through
Apache v2,2 that came on Etch?
Why not just take the time and backport the fixes back into the Etch
version, do not cause an ABI incompatibility and make it so that the
thousands of packages compiled to run on the version of apache v2.2 that
came in Etch can still work without any addition work.
> The kernel, Squid and other major server projects already do recognise
> the need for "ultra-stable" trees, and they manage (fix and update)
> them separately from the less-stable development trees.
The Linux kernel no longer has a separate Stable and Development Trees.
All in one. Squid? Not a REALLY major project. It is a caching
web-traffic proxy. Fix and Update and increment the API and ABI
interfaces to force other projects that interface with them to have to
also fix and update and recompile against squid to once again, WORK.
> f, Usability issues, wishes, bug reporting
>
> In Debian, usability bugs are entirely ignored in fact. If they even
> are fixed upstream, user waits the entire release cycle for the fixed
> version. Any bug other than security is almost _impossible_ to see
> fixed. It usually does not make _any_sense_ to report usability bugs
> in Debian.
That is because, that UNLESS the patch/fix for the bugs do not ADD
functionality or bump the interfaces to itself, then and only then does
it get included. MOST upstream patches are just that, they *ADD*
functionality or bump the ABI or change the functionality in such a away
as to make the fix "signed" or encrypted or something.
> -Upstream doesn't accept bug reports regarding ancient versions of the
> software
Yeap, but Debian accepts those bug reports. Fixed in Sid doesn't mean it
will make it into Stable, usually it does not make it into stable,
unless testing is in freeze for migration to stable. Fixed in Sid means
it should hit testing at anytime (barring a freeze).
> -In Debian's bug reporting cycle, the user usually ends up with
> developer's advice to "try the newest package from unstable" anyhow.
> Bug report is then closed with "fixed in unstable". Of course, the
> package will then change dozen times again until it gets into stable
> in next release eventually, so that in the time of release, the bug
> could easily be there again (regressions in upstream and so on..), or
> other bug takes place..
MOST Debian desktop users I know of, are using "testing". This fixes you
problems in great instances of "just" use testing.
> -Installing unstable or testing packages leads usually to broken
> system dependencies, so it is not advisable for anyone who needs to
> actually USE the computer.
Installing TESTING or UNSTABLE package on STABLE does typically RESULT
IN A BROKEN MACHINE. There is a reason for that... the "specialized
versoin" of libraries you complain about. If you don't understand and
don't want to learn about it... well, I am feel sorry for you.
> All in all, for the user, reporting the usability bug is waste of
> time, and if he tries to help fixing it, he may end up with
> reinstallation of the system.
I have installed Debian on my machines exactly ONCE. Actually less the
ONCE per machine. I just scp the installation over and change things for
the new machine. Done. You obviously do not get the Debain System of
things.
> For the upstream, the Debian user is out of the game and out of the
> community.
No it is not, the Debian user needs to use the Debian BTS. reportbug
easily allows users to report bugs on packages. I've used it recently
even, and have had great results with it.
> Yes, by forcing the ancient versions of the software, the Debian users
> are in fact BEING ISOLATED FROM UPSTREAM SOFTWARE'S COMMUNITY:
> -Debian Stable user can't help upstream software's community by
> reporting bugs and feature requests.
Again, that is WHAT DEBIAN'S Bug Tracking System is for.
"aptitude install reportbug"
> -Upstream software's community cannot help Debian's user.
Most despise Debian anyway. Not because of OLD versions, but because
they cannot understand the Debian Way of Development and policy in
regards to this Debian Development.
> -Debian user is facing the bugs that usually have already been fixed
> upstream ages ago.
Stable is Stable. How many times must I go through this.
> This is damaging the ecosystem on both sides.
No, it is not. Why do you think SO MANY DISTRIBUTION ARE BASED ON
DEBIAN?
> For the Debian developers, the usability bugs are just waste of time
> again and again, because dealing with them don't make any real sense
> for anyone.
No they are not, they get fixed in upstream and get applied in Sid.
Stable is Stable, once again.
> g, Need for new features
>
> You are out of luck with Debian. The software in Stable is already
> out-of-date at the day of release, quickly fading to museal
> experience.
backports for Debian stable (others have listed it), look at it, embrace
it. Love it. Don't assume. This though, does NOT make stable == STABLE,
as these new features are not as vetted and reviewed by as many. This
also is not officially supported by Debian though, as it is NOT stable.
> If You need new software, You must compile it Yourself, tackle with
> generic installers, risk the system's consistency by adding testing
> repositories, or when You have enough of that, choose other distro.
Ha, you really are calling the pot, dayglo orange here. Debian Polcy
forbids Stable to have features added. Again Stable == Stable.
> There's no REALLY supported and advised way to easily get recent
> desktop software into Debian and manage it.
Yes, the backports website is not officially supported. I suggest you
use testing if you WANT these new features.
> h, Improvements to Linux desktop
>
> the same as in g,
The Linux Desktop in Debian is not its primary function... won't be
ever. What Debian does it run on 11 architectures, consistently and ANY
person could and would be able to apply the "Debian administration"
knowledge to any of those machine with Debian Linux installed on them.
IA32 and AMD64 are not the only hardware platforms around. Why should
the "universal operating system" be bent on doing the Desktopm when its
aim is to deliver a fully functional OS to those 11 architectures.
> ** What should be changed **
>
> * 1,
> The release cycle should be completely redesigned.
Completely redesigned? No. Tweaked? yes.
> The desktop-oriented packages should be available in as recent version
> as possible. The desktop software must not trespass the whole
> unstable/testing/stable scrutiny. User should simply get the latest
> stable upstream version, no more, no less.
Why? If you MUST have bleeding edge, run Sid (unstable, which means
unstable packaging and APIs and ABIs, not instability like most people
assume).
I have run Sid for years. I run it on nearly 90% of my machines. I have
a few sacrificial lambs that are there for QA to make sure things work
before I commit the others, but I've only seen a few problems over the
years that took longer than a week to fix, but since I keep older "known
working" packages I can revert quite easily.
> The distribution cannot, and should not attemp to, isolate user from
> software bugs. There always ARE and WILL BE bugs, even in the software
> that made it into "stable" Debian, even in "security-only" fixes etc.
> Managing the bug reports for old versions of software and backporting
> the fixes is waste of time.
Do you understand *WHY* these things are backported? You obviously have
not considered the whole "recompiling of all redepends packages" to get
them to work with a "new upstream" package
> The stabilisation of software is UPSTREAM's business. Let the upstream
> do its job. Let's give the upstream more responsibility together with
> support.
No, stabilization IS NOT UPSTREAMS BUSINESS. The Linux Kernel in
particular. Firefox as another, Apache yet another... etc. Also getting
everything to work with one another. You wouldn't like Apache not be
able to talk with postgresql due to a typo on Apache or postgresql
fault. Or what about Evolution not running properly in KDE. KDE doesn't
care about evolution, they have kmail. Come on pull you head out.
> Accepting the upstream stable versions, we would shake off much of
> colosal release work and backporting effort. Let's simply acknowledge
> anyone, that we are supporting the latest upstream versions, with all
> pro's and con's, and help users with reporting problems and getting
> fixes then. Let's not "over-stabilise" desktop software, as this is
> unnatural for it.
Let's not "over-stabilize" ... So you want it to be Windows? Just Code
It, Compile It and push it out the door?
> The thorough stabilisation scrutiny should apply only to server
> applications and the basic platform, with the optimal length of
> release cycle of maximum 18 months. During stabilisation, LSB
> compliant basic platform (libc and other libraries) should get
> established and polished to high merits.
So, now it sound like you are suggesting another "distribution" called
"Desktop".
All, I can say is this: You do not understand Debian and its core values
and policy and volunteering. Debian *IS* after all a Volunteer
organization.
> All desktop software, released anytime within release period, should
> be simply compiled against this stable libraries platform, and
> released immediately as update. Thus, bunch of platform stabilisation
> problems should be shaken off, focusing on the merit -the platform.
Ah, yes, you *DO*: Code it, Compile it and push it out.
> On the other hand, giving the recent version of desktop software to
> the end user will please the users that want them anyhow. Yes, the
> software WILL contain bugs, but if we could allow the users to report
> them with reasonable ease, the software will only profit from that,
> and users too eventually. The whole cycle should allow really good
> interaction between authors and users, so that users will report bugs
> against RECENT version of software, developers will fix them, and
> users will get the fixed stable version. The bug cycle should be
> shorten enough. Therefore, the contact between user and upstream
> software authors should be as close as possible. Let's re-create the
> lost community.
There is NO lost community. The whole reason Debian HAS a Bug Tracking
System is to aid it in making a stable release, doing give back to
upstream, doing innovation that upstream refuses to even consider,
unless they see it working. (Think exim for a minute on that)
> Should there be really bad bug in upstream's stable version, let's
> give the user a tool for simple downgrade.
dpkg does this by default. Ding, done.
> In means of this,
> * 2,
> General bug reporting framework should be established, in steps. There
> is bazillion of separate bug tracking systems, nearly every
> application has its own one. For the end user it means, that he must
> register in dozens of bugtrackers in order to report the bugs he found
> in apps.
Okay, so when you install reportbug, doesn't report EVERYTHING on a
debian system? Yes.
> Moreover, on top of that, every distribution has its own bug tracking
> system. This is not bearable. The user should be able to report a bug
> from central application, without need to register here and there. One
> registration, the distributional one, should be enough. The
> application's developers should work with issues on unified way, not
> searching reports and information in every-distro's mailing lists etc.
Searching and searching and searching... The distro you are using... if
it is worth ANYTHING has a great bug search system. Has a GREAT mailing
lists search tool. Or you have Google. Learn to use Google.
> Debian, being the main community driven distro, should lead this
> effort.
> Negotiations should be held with other distros and main GNU projects.
> Ohers would join eventually.
No, Fedora has a commercial entity behind it, Mandriva does too, Ubuntu
has one as well. They will not join, mainly because Debian is to
"retentive about Free and free". This is forced from the DFSG, Social
Contrat and the Debian Developer Policy and guides.
> Canonical is currently working on similar idea, so let's work
> together.
> First enable users to report a bug REALLY easily, using a
> distributional tool. Then try to interconnect the system with separate
> bug-tracking systems allaround.
You fail to understand there is ALREADY a link tween the two.
> *3,
> New official desktop repository
>
> In order to give the users painless access to the fresh desktop
> applications, new repository should be built and officially
> supported.
So, who owns it or maintains it?
> It means, user should be able to upgrade his preferred applications
> without leaving the official distribution repositories. During the
> release cycle, upgrading the software from those must not affect main
> system libraries or break dependencies. Users want fresh software,
> let's give it to them -in supported, reliable, official form, with
> latest bug and security fixes, fresh and hot, directly from the
> source.
You don;t understand many of the thing that go on during a Distribution
release, do you? You only see what you see.
> Security upgrades should simply go thru this repository by naturally
> upgrading the whole software packages to recent upstream version -no
> longer backporting the patches.
So, Apache falls into this? (an other server type things)
> The repositories should be advised during installation and user should
> easily choose, whether he wants to upgrade the desktop software or
> not.
Oh, like they currently are able to choose a on-standard mirror already>
or a Standard one? Or combos of them all?
> In fact, the corporate users that are sensitive to software changes,
> probably don't even run security updates at desktop, because they
> occasionally break things too. So, nothing changes for them -they'll
> just keep the installed version and don't touch it.
So, once again you are contradicting yourself. There is a reason STABLE
is STABLE. They occasionally break things one OTHER DISTRIBUTION or
MICROSOFT WINDOWS.
> *4,
> Discuss with main FOSS communities
>
> The basic FOSS communities should get "tuned" to some general release
> rules. Stable release of any software should mean that an app is well
> tested and can be installed with minimal risk. In fact, the FOSS
> software is naturally approaching this manner.
>
> Apps should support constant upgrade with painless transition between
> succeeding versions of an app.
Okay, here again, painless upgrade... never happen, unless everything is
compiled EVERTIME. ABIs and APIs change constantly in "new version
upstream" releases. Thing *WILL BREAK* under this ideal. You really
don't have everything put together.
The ideas you have presented here are indeed dubious, but are misguided
as you are coming from a commercial aspect. This fails on many fronts
when talking about Debian. Debian has motives far and away different
from anything you currently show you understand.
> Hope this letter could inspire You to look at the situation around
> Debian as desktop platform fading away, and think about changes that
> would make it vibrant, fresh platform that people would like to use.
> About user's community where problems are reported and fixed, and
> dreams published and realised.
Debian has never TRULY been a "Desktop" platform, though I have been
using it as "Desktop" platform for years. I don't see it as any less of
a Desktop now as I did in 1999. In fact, it is MUCH easier to use as a
Desktop now than in 1999. And I see more people using it after tasting
Ubuntu and blowing out during an upgrade from Warty to something newer.
> Have a nice day
I will. As should you.
--
greg, greg@gregfolkert.net
PGP key: 1024D/B524687C 2003-08-05
Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C
Alternate Fingerprint: 09F9 1102 9D74 E35B D841 56C5 6356 88C0
Attachment:
signature.asc
Description: This is a digitally signed message part