FreeBSD Foundation benötigt Spenden

DJF

DJF

/(bb|[^b]{2})/
Hallo zusammen,

Als ich heute auf freshports.org war, ist mir dieser Link http://www.freebsdfoundation.org/donating.shtml zusammen mit dem Hinweis "VERY IMPORTANT" aufgefallen.

Obwohl ich FreeBSD schon lange benütze habe ich mich eigentlich noch nie mit der FreeBSD Foundation und was sie macht auseinander gesetzt. Naja, die Foundation muss in den nächsten 9 Tagen knapp über 30'000$ spenden auftreiben um eine non-profit Organisation zu bleiben. Im Newsletter kann man Weiteres nachlesen. Wisst ihr ob so ne Spende sinnvoll wäre? Die Argumente die sie im Newsletter bringen klingen gut, aber andererseits wollen sie auch 30'000$ von uns ;)
 
Selbstverständlich ist eine Spende sinnvoll. Falls jemand noch nicht gespendet haben sollte, dann bitte ich dringend darum, die FreeBSD-Foundation zu unterstützen! Der Betrag spielt keine so große Rolle, Hauptsache die Anzahl der Spender steigt signifikant!

Also: Schluss mit der Laberei, Spenden, sofort! :)
 
Ich spende mal ne Runde Mitleid ^^


Kommentar:
Es tut mir Leid, aber zu dem Zeitpunkt der Verfassung dieses Postings war ich stark angetrunken und saß am PC. Nun, es ist sicherlich nicht Ernst gemeint - ich selber spende ab und zu an BSDForen.de, weil ich weiss, dass saintjoe nichr die durch uns anfallende Kosten auf dauer allein tragen kann.

Dasselbe würde ebenfalls ich ebenfalls für das FreeBSD Projekt tun doch leider bin nicht im Besitz einer Kreditkarte oder eines PayPal-Accounts, mit dem ich einen Betrag an die Foundation überweisen könnte.
Ich bin mir schon im Klaren, dass die OpenSource Projekte, sei es Linux, BSD oder sonstwas, von Spenden leben und ich kann auch nur dort helfen, wo es im Bereich des Machbaren steht. Ich mache mir auch deswegen keine Vorwürfe. Es gibt so viele Organisationen, die (mehr oder weniger) dringend Geld brauchen, daher finde ich jeden weiteren Aufruf etwas weniger sinnvoll...
 
Zuletzt bearbeitet:
nintendo, und wem soll das nützen? Ich denke mal, dies ist ein ernstgemeintes Posting, also sehe ich deinen Beitrag eher mit sehr gemischten Gefühlen.
 
Leider habe ich keine PayPal-kompatible Kreditkarte. Wie sieht das mit der Schneckenpost aus, kommt damit Bares verläßlich über den Teich oder geht da auch mal was "verloren"? Kann man da auch Euros hinschicken oder muß ich mir erst Dollars besorgen?

marzl, wie machst du das denn z.B.?
 
Welche Karten sind nicht kompatibel?
geht ja auch via "Bankauffüllung"
Wie zahle ich Geld von meinem deutschen Bankkonto aus ein?

Um Geld von Ihrem deutschen Bankkonto aus einzuzahlen, müssen Sie Ihr Bankkonto wieder zu Ihrem PayPal-Konto hinzufügen. Um Ihr deutsches Bankkonto zu Ihrem PayPal-Konto hinzuzufügen, gehen Sie zur Registerkarte Profil, und klicken Sie in der Spalte Finanzinformationen auf den Link Bankkonten. Sobald Sie Ihr Bankkonto hinzugefügt haben, können Sie Geld auf Ihr PayPal-Konto einzahlen.


Wie dem auch sei, war meine sinnvollste Weihnachtsinvestition ;-)
 
FreeBSD Foundation Financial Data
=================================

Profit/Loss Jul 2004 - Sep 2004

Ordinary Income/Expense
Income
Grants 1,485.95
Total Income 1,485.95

Expense
Computer Equipment 8,022.00
Event Sponsorship
Conference Fee & Travel Grants 1,668.90
Event Sponsorship - Other 3,622.47
Total Event Sponsorship 5,291.37

PayPal Fees 33.85
Postage and Delivery 39.53
Professional Fees
Accounting 450.00
Legal Fees 72.30
Total Professional Fees 522.30

Total Expense 13,909.05

Net Ordinary Income -12,423.10

Net Income -12,423.10


Balance Sheet as of Dec 21, 2004

ASSETS
Current Assets
Checking/Savings 194,605.36

Total Current Assets 194,605.36

TOTAL ASSETS 194,605.36

LIABILITIES & EQUITY
Equity
Retained Earnings 182,803.98
Net Income 11,801.38
Total Equity 194,605.36

TOTAL LIABILITIES & EQUITY 194,605.36
 
ich richt mir n paypalkonto ein, is sehr nützlich, vor allem wenn man was bei auslandsebayanern bestellt
 
In diesem Zusammenhang, hier die mail von PHK an announce@ (er hatte vor einiger Zeit nach Spendern gesucht das er fulltime für FreeBSD arbeiten kann):
Final report on funded FreeBSD development project [1]
------------------------------------------------------

As promised, here follows the status report on how my six months
of user-community funded FreeBSD development went.

The goal of this effort was to get as far in the "buf-junta" plans
(http://people.freebsd.org/~phk/plan.html) as possible, and as I
have outlined below, a significant dent was made in that list
over the last six months.

I would like to thank 187 persons and companies for, though their
donations small and large, making this work possible. The future
of FreeBSD is very much in the hands of the developers, and by
helping this particular developer get his hands free for half a
year certainly moved a lot of stuff from the future into the present.

If you, my donors, are not happy with what you got out of your
donations, the fault is entirely mine. (and I would like you to tell
me about it as fast as possible.) Please do not fault the FreeBSD
project as such or the FreeBSD Foundation for that matter, if this
was not a success, it is all my personal fault.

If on the other hand you think you got your moneys worth and you
would be willing to help support FreeBSD development financially
also in the future, then, and only then, will I declare my project
to have been a complete success.

Feedback either way is most welcome!


The future
----------

A lot of people have asked me "what about the future ?"

I promised them to make up my mind and let them know in this
report: I have decided to not do another fundraising drive at
this time.

There are a number of reasons for this.

The primary reason is that I do not want to be stuck in an ivory
tower doing only the FreeBSD work I can see from my lab in the
basement. I need to get out amongst people and get inspiration
and input from real-world usage of FreeBSD. To that end I hope
to land a couple of contracts currently under discussion and
occupy half of my time this way.

The other reason is that I hope the FreeBSD Foundation will be
the place where this kind of fundraising happens.

Channeling the funds through the FreeBSD Foundation means that
this will not grow into a personality cult around my person and
that money can be spent where it is most needed rather than on
where I happen to fancy spending it.

The minor reason is that the paperwork associated with fundraising
is not a favourite hobby of mine and I'm still not done resolving
various sticky details [4]


But since there are still a lot of work to be done in this area
of the kernel and since that is what I think I am best at, I
have sent a proposal to the FreeBSD Foundation for funding me
part time for a period to continue working on this stuff.
I was somewhat late in sending my proposal to the Foundation,
and have not yet received an answer from them, so the outcome
of this is not yet known. If it falls through, I will find a
couple of contracts for now, and then reconsider the situation
later in the 2005.


If you want to support FreeBSD development financially, the way
to do it right now is to donate money to the FreeBSD Foundation.
If you do so, some of the money may or may not end up funding
my work, either way, it will be money well spent.


High-lights from my personal score-card:
----------------------------------------

June ... October -- TTY code/driver cleanup

In order to not clash with the RELENG_5 release work, I
attacked the tty code/drivers in order to try to drive Giant
out of the pty driver.

I found that a massive amount of code which should have
lived in the generic tty code was copy&pasted into almost
every and all tty device drivers.

In the end I did not manage to do any of the actual locking
work, but I did get a lot of preparation for it done: I
eliminated the 3100 lines of copy&paste'd code so that there
will be many fewer places where locking will have to be
handled (and bringing a lot of consistency to our tty drivers
as a side effect).

I also managed to get struct tty properly reference counted,
but some sticky issues about unloading tty drivers with
dangling sessions still need to be handled.

June ... November -- Device and Fifo vnode bypass

In terms of architecture, this is one of the most significant
changes I have made in the last six months.

Despite being a relatively small change in terms of number
of lines of code changed, this project was spread out over
a long time in order to be sure to catch all the little
details in the corners. One of my test machines have been
more or less dedicated to to this subproject for 5 months.

The end result is that access to devices and fifos ('named
pipes"), from programs now does not go through the vnode
layer for the "traffic" calls, read, write & ioctl. (For
device drivers we may still need Giant if the driver is
marked as needing this.)

August -- Rewrite Floppy driver.

The internal state engine was rewritten and the driver made
INTR_FAST, Giant safe and GEOM aware.

September ... October -- DEVFS/SPECFS consolidation

Devices are now only supported in the devfs filesystem, and
supporting code was removed from ufs, ext2fs, cd9660 and a
few minor filesystems.

In practice this have had very little impact when seen from
outside the kernel, but the simplifications in the kernel
are extensive and very significant.

The end result is that specfs is retired and only devfs
handles devices now.

A significant part of this work has been to properly reference
count access into device drivers in order to make it safe(r)
to unload device drivers. There are still many hurdles here
before it is 100% safe to unload a driver, but at least now
the cdevsw interface should not be one of them.

October ... [ongoing] -- struct buf/vnode -> buf/bufobj/vnode

This is also one of the architecturally very significant
changes which had its fingers all over filesystems and buffer
cache code.

The work is not carried all the way through, but has progressed
sufficiently far to reap the first major benefits (see below).

It is hard to fairly summarize this stuff without it turning
into a long architectural monologue, but the gist of it is
that the aspect of vnods which serve as the attachment point
for stuff in the buffer cache has been given an indenpendent
data structure (bufobj) which in the future will not be tied
to vnodes only.

The untangling has reached and stopped right in front of the
syncer code, and will continue from there as time permits.

October -- Move copyonwrite and prewrite into FFS where they belong.

These two functions are private to snapshots and softupdates,
and with a private strategy implementation in FFS they can be
isolated there entirely.

This simplifies the buffer cache code a bit.

October -- Proper waiting for pending geom events

A process which caused events to be created in geom will now
wait for them to be completed before returning to userland.
This removed an insufficient lot of explicit waits.

October ... --- Put local filesystems directly on GEOM

Another piece of significant architecture [2]

Instead of taking a tour through the vnode layer, DEVFS and
geom_dev, go directly to the new Geom class geom_vfs to access
disk devices for local filesystems.

Amongst many other benefits, this gives us correct read/write
tracking on devices, and it is now possible to mount the same
filesystem r/o many places.

Together with the device vnode bypass, this entirely takes
I/O traffic from devices out of the vnode layer (and more
significantly: vnode locking).

November ... December -- FILEDESC locking

In order to make the locking of file descriptors work better
with devices and fifos bypassing vnodes, the locking was
reworked and struct filedesc got a reference count more for
protecting the memory allocation.

November ... December -- omount(2) -> nmount(2) kernel transition.

All filesystems converted to implement the nmount(2) API
now. Calls to the old omount(2) API are converted in a
special compatibility function in the filesystems.

Userland conversion to nmount(2) should happen in the spring
so that RELENG_6 will be entirely nmount(2) but still support
omount(2) calls. Support for omount(2) will be dropped in
RELENG_7.

December -- Make VOP_* implementations typesafe.

By using sparse struct initialization, it was possible to avoid
a lot of the magic pointer gymnastics in creation of the VOP
method vectors for filesystems. The result is typesafe and
faster VOP_ method calling.

December -- Root filesystem mount rework

Since all filesystems now accept nmount(2) calls, the magic
code mounting the root filesystem was cleaned up, removing
the need for magic per-filesystem code to handle the root
file system.

This eliminated the main source of "bogo-vnodes" in the
system, leaving only the syncer-vnodes now.

June ... December -- Bugs introduced, code broken.

Throughout a number of mistakes, minunderstandings, keyboard
misfires and just plain stupidity on my part have introduced
bugs and broken code.

This will be fixed as soon and as fast as I can.

Pointless statistics:
---------------------

In the mock sprit of sports pages everywhere, and general journalistic
"that was the year that was" reporting approaching the end of a
year:

Total donations: 33336 USD
Average donation (sans outliers): 72 USD
Total number of commits to CVS: 577
Cost per commit: 58 USD
Average time between commits to CVS: 7h36m
Number of submits to p4: 996 (minium ?)
Average time between submits to p4: 4h25m
Netto lines of code added,
not counting retired device drivers: -7291
Pointy hats awarded: 3
Cost per codeline: -.22 USD
Disks crashed: 3
Super strong fridge magnets retrieved: 6
Shoulder injuries: 1
Electricity used by computers 5275 kWh
Successful attempts to communicate
non-criminal status to Paypal: 0
Futile attempts to communicate
non-criminal status to Paypal: 10
Random acts of kindness received: 3
Random acts of kindness not delivered
due to botch by amazon.com: 3 [3]


Merry X-mas & happy new-year,

Poul-Henning

[1] For those of you who don't know what I'm talking about in this
email, a quick visit to http://people.freebsd.org/~phk/funding.html
would be a good idea.

[2] I rather fear I sound as boring as the tourist guides on
the ruins of Akropolis, my apologies.

[3] Amazon.com had a wrong shipping address on my "wish-list", so
at least three packages of gifts from kind people have travelled
all the way from Amazon to my old address and back again. I'm told
people will get a full refund from Amazon once the package makes
it back to them. My apologies for this mess. Much appreciated
anyway.

[4] Paypal is very well and nice, but trying to get through their
CMS system to explain to them that just because you are located in
the EU and received money doesn't make you a member of the mafia
is still not an art I have managed. If you happen to know an email
address of a senior executive let me know.
Zum Vergrößern anklicken....
 
Ich werde herzlich gerne spenden, damit ich endlich auch mal einen Beitrag zu diesem klasse Betriebssystem leisten kann.

Habe unter ein wenig Bauchschmerzen schon ein PAYPAL -Konto eingerichtet und werde denen mal $50 schicken.

cheers
 
Das hat mir gerade noch gefehlt zur Weihnachtszeit

Jo, na klar, dann spenden wir mal alle, damit auch in Zukunft sich die Industrie ihre Software kostenlos im Internet runterladen kann !!!

Mal im Ernst Leute, es gibt sicher Organisationen, die verwenden das Geld für sinnvollere Zwecke.
 
@thorsten1
Bitte? Also wenn man nichts spendet, keiner ist verpflichtet, dann ist das ok. Man kann, muss aber nicht, sich anderweitig einbringen.
Was aber ist daran verfänglich das Project zu unterstützen welches Dir ein OS gibt mit dem Du zufrieden bist?
 
Ich denke, auf solche Kommentare, die was von der "bösen Industrie" faseln, sollte man besser nicht weiter eingehen. Der Poster sollte vielleicht mal sein Verständnis von Freier Software überdenken, bevor er sowas vom Stapel läßt.
 
>Jo, na klar, dann spenden wir mal alle, damit auch in Zukunft sich die Industrie
>ihre Software kostenlos im Internet runterladen kann !!!
Die BSD-Lizenz erlaubt dies, ist auch einer der Absichten dieser Lizenz.

>Mal im Ernst Leute, es gibt sicher Organisationen, die verwenden das Geld für
>sinnvollere Zwecke.
Zum Beispiel für den Weltfrieden:
http://www.kadampa.org/german/centers/temples_for_world_peace.php

Ich aber spende lieber an die FreeBSD-Stiftung und OpenBSD.org,
das Resultat ist für mich unmittelbarer sicht- und spürbar.

Btw, hat bsdforen.de einen PayPal-Account?
Dann könnt ich nämlich endlich meine Drohung wahrmachen und diesem Forum spenden.
 
Seltsam.

Paypal sagt, dass die Überweisungen noch offen seien, aber ich habe eine E-Mail von der FreeBSD-Foundation(wirklich?) erhalten, dass sie meine Adresse benötigt, um mir schriftlich den Empfang der Spende zu quittieren.

Hoffentlich ist das kein Phishing.

cheers
 
bsd5543 schrieb:
Seltsam.

Paypal sagt, dass die Überweisungen noch offen seien, aber ich habe eine E-Mail von der FreeBSD-Foundation(wirklich?) erhalten, dass sie meine Adresse benötigt, um mir schriftlich den Empfang der Spende zu quittieren.

Hoffentlich ist das kein Phishing.

cheers
Zum Vergrößern anklicken....

siehe http://www.freebsdfoundation.org/donating.shtml:

If you make a credit card donation, you will be asked for a shipping address. Please supply your mailing address in that field. The Foundation is required by law to send letters of acknowledgment for donations, and we need your mailing address to comply with the law.

Gruß, Miguel
 
Nachtrag:

News Flash! - December 26, 2004 - FreeBSD Foundation exceeds 2004 small donation fund-raising goal!
Thanks to the generous contributions of over 800 donors, a combination of both first-time donors and existing supportors, the FreeBSD Foundation has met and exceeded its fund-raising goal necessary to qualify for the 1/3 "public support" goal required to maintain its 501(c)3 status with the IRS. Your continued donations will help to support a broad variety of FreeBSD activities, including critical development, developer collaboration, testing, and involvement in standards processes. Additional donations are still welcome -- please consider making a donation today!

http://www.freebsdfoundation.org/
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben