Aktív fórumtémák

Tárgy Válaszok Legutóbbi beküldés Fórum Szerző
  A Yettel most félelemkeltéssel akar hozzájutni a régi mobiltelefonokhoz 70  2024-04-25T19:20:14+0200 HUP cikkturkáló hajbazer
  Fedora 40 csak Wayland 119  2024-04-25T19:02:15+0200 Red Hat, Fedora, CentOS szkaresz
  ChiWriter 3.12 kerestetik 11  2024-04-25T19:00:53+0200 Iroda szaszi
  "Orbán Viktor: Reszkethetnek az irodisták, a jogászok, a fogalmazók és a programozók" 110  2024-04-25T18:35:26+0200 HUP cikkturkáló zitev
  "Itt a törvényjavaslat, ami lehetővé teszi a pornóoldalak letiltását" 28  2024-04-25T18:12:34+0200 HUP cikkturkáló zitev
  STM32 arm debuggolás 27  2024-04-25T17:59:34+0200 C/C++ tovis
  Hat napos munkahét 154  2024-04-25T17:49:36+0200 HUP cikkturkáló Sanya
  Kulcsszivárgás PuTTY alatt 91  2024-04-25T17:40:34+0200 Security-all bzt
  STM32F051 CMSIS bare metal header files 23  2024-04-25T15:42:31+0200 C/C++ tovis
  Amavis rewrite subject BANNED 2024-04-25T15:02:40+0200 Web, mail, IRC, IM, hálózatok Proci85
  syslog-ng nem logol (D. jessie) 14  2024-04-25T14:43:58+0200 Linux-haladó robit
  Audacity forkhaboru - lett olyan fork, amit ma is maintainelnek? 60  2024-04-25T13:51:34+0200 Multimédia carlcolt
  Outlook eldobja az Office365-ös fiókok felé küldött levelet - 4.7.500 Server busy 2024-04-25T13:46:38+0200 Web, mail, IRC, IM, hálózatok sandroshu
  Android user tippeket tudtok? 73  2024-04-25T11:59:47+0200 Android m.informatikus
  Tömörített (gzip) lemezkép használata loopback eszközként 32  2024-04-25T11:51:21+0200 Linux-haladó nevergone
  e-kréta, tárolt adatok 87  2024-04-25T09:32:27+0200 Iroda uhlaci
  convert crop tobb filet keszit, miert? 2024-04-25T08:57:33+0200 Linux-haladó wyx
  Unaloműző online játékok és azok eredményei #2 537  2024-04-25T07:52:43+0200 Játékok trey
  Egyszerű webgalériát keresek 10  2024-04-25T07:01:37+0200 Web, mail, IRC, IM, hálózatok zslaszlo
  Postfix+Dovecot+ melyik vírus scan? 14  2024-04-24T20:41:24+0200 Web, mail, IRC, IM, hálózatok Proci85

Új szavazás: Telepítenél tűzfalnak UHU-Linux Tűzfal 1.0-át?

Címkék

Véget ért a Legmagasabb iskolai végzettségem címmel futó szavazás. Az eredményeket meg lehet tekinteni itt. Úgy tűnik, hogy többségében diplomás emberek olvassák a HUP-ot (bár ez néha nem látszik a hozzászólások minőségén :-)) De bíztató, hogy a fiatalabb korosztály is érdeklődik az itt felvetett témák irányt. A 7 MTA tagot meg üdvözlöm :-)

A napokban megjelent az UHU-Linux Tűzfal 1.0-ás változata. Arra vagyok kíváncsi, hogy az olvasók telepítenének-e ilyen tűzfalat, vagy sem. Hogy a választási lehetőségek ne okozzanak gondot, csak "igen"-nel és "nem"-mel lehet szavazni. Indoklást a hozzászólásokba várok! Szavazni lehet itt.

Fordítót váltott a NetBSD

Címkék

A NetBSD projekt több népszerű platformon is alapértelmezett fordítóprogramot cserélt. Matthew Green bejelentette, hogy az alpha, i386, sparc és sparc64 portok mostantól fogva a GCC 3.3.1-et használják majd, mint default fordítót.

KDE 3.1.4 FreeBSD-re

Címkék

Szeptember 16-án megjelent a KDE 3.1.4-es verziója, amely elsősorban egy karbantartási kiadás, és amely több biztonsági hibát is javít. A stuff mostantól elérhető FreeBSD-re is. Látogasd meg a FreeBSD KDE oldalt a bővebb információért.

Torvalds és Cox levele a szoftver-szabadalmak ellen

A Linux szülőatyja Linus Torvalds és a jelenlegi 2.2-es kernelszéria karbantartója (még) Alan Cox felszólalt az ellen a törvénymódosítási javaslat ellen, ami megengedné, hogy algoritmusokra és felületekre is be lehessen jegyezni szabadalmat. A dolog súlyosságát jelzi az, hogy ha ezt a törvény tíz évvel ezelőtt fogadták volna el, a szabad szoftverek legnagyobb része ma nem létezne. A két kernelfejlesztő a levelet Pat Cox-nak, az Európai elnökének címezte. Hivatkoznak arra, hogy a megszavazás előtt álló törvényjavaslat átrányosan érintené a kis és közepes méretű vállalatokat, és a piacra újonnan belépőket is.

Igazából a szoftver-szabadalmak a nagyvállalatok érdekeit szolgálnák. Reméljük, hogy lesz eredménye a tiltakozásoknak!

Linus és Alan levele itt.

LKML: slabtop

Címkék

Chris Rivera egy új segédprogramot jelentett be az LKML-en. A program elsősorban a kernelfejlesztőknek lesz majd hasznos. A neve slabtop.

UHU SA-001-3 OpenSSH

Címkék

Csomag : ssh

Sebezhetőség : buffer kezelés

Probléma típusa : lehetséges távoli

Bővebb információ : CAN-2003-0693 CAN-2003-0695 CAN-2003-0682Solar Designer újabb hasonló buffer kezelési hibákra bukkant. Továbbra sem ismert, hogy ezek a hibák kihasználhatóak-e, de ajánlott frissíteni. Az OpenBSD csapat is javított egy dupla-memóriafelszabadítási hibát.

A csomagok letölthetőek a http://www.lsc.hu/security/ oldalról, vagy közvetlenül:

deb - http://www.lsc.hu/security/ssh_3.6.1p2-6.3_i386.deb

md5 - http://www.lsc.hu/security/ssh_3.6.1p2-6.3_i386.md5

DragonFly BSD telepítése

Címkék

Készítettem a DragonFly BSD telepítéséről egy rövid összefoglalót 25 lépésben. Az instrukciók a DragonFly BSD levelezési listán megjelent írások (Justin C. Sherrill), útmutatók alapján készültek.



Az írás csak a lényeges pontokat tartalmazza, _nem_ kimondottan kezdőknek készült. Az írás feltételezi, hogy a használója tisztában van olyan fogalmakkal mint a FreeBSD csomagok kezelése, fordítása, telepítése, cvsup, konfigurációs fileok szerkesztése, kernelfordítás, buildkernel, buildworld, mergemaster, stb.



(Ha nem akkor jó kiindulópont lehet a FreeBSD Handbook vagy az ehhez a témához kapcsolódó korábbi írásaim: FreeBSD - hogyan frissítsük rendszerünket (cvsup), FreeBSD kernelfordítás mini-HOWTO)1.) Telepítsd fel a rendszered a legfrissebb snapshot ISO-ból

(hibák előfordulhatnak közben)


2.) reboot


3.) lépj be "root"-ként


4.) adj jelszót a "root"-nak


5.) az /etc/rc.conf-ba írd be az sshd_enable="YES", és ifconfig_xl0="DHCP" sort

(ha nem DHCP-d van, akkor értelemszerűen)


6.) reboot


7.) töltsd le az ftp://ftp.FreeBSD.org/...cvsup-without-gui-16.1h.tgz csomagot


8.) adduser (magadnak)


9.) mkdir /home/dcvs


10.) töltsd le a http://www.dragonflybsd.org/Main/dragonfly-cvs-supfile filet


11.) mv dragonfly-cvs-supfile /etc


12.) echo "cvs-dfports" >> /etc/dragonfly-cvs-supfile


13.) rm -rf /usr/src /usr/obj


14.) cd /usr


15.) cvsup -g -L 2 /etc/dragonfly-cvs-supfile


(előtte a biztonság kedvéért ellenőrizd le a DragonFly BSD kernel listán, hogy nem volt-e tinderbox hiba az elmúlt 3 órában)


16.) cvs -d /home/dcvs co dfports


17.) cvs -d /home/dcvs co src


18.) cp /usr/share/examples/cvsup/FreeBSD-ports-supfile etc

(szerkeszd meg a FreeBSD ports-supfile-t, és írd be a helyes szervert)


19.) cvsup -g -L 2 /etc/FreeBSD-ports-supfile


20.) make buildworld


21.) make buildkernel


22.) make installkernel


23.) make installworld


24.) mergemaster


25.) reboot

Jonathan Schwartz interjú - a Sun Linux stratégiája

Címkék

Az Eweek interjút készített Jonathan Schwartz-cal a Sun Microsystems szoftverekért felelős alelnökével. Az interjúból kiderül, hogy a Sun szerint a Linux nem igazán játszik szerepet mint, szerver operációs rendszer.

"... hadd mondjam el igazán mi is a mi Linux stratégiánk. Nincs nekünk ilyen... Nem hiszünk abban, hogy a Linux szerepet játszana a szervereken... Ha vásárolni szeretne [Linuxot], akkor el fogunk adni magának, de mi úgy hisszük, hogy a Solaris jobb alternatíva, biztonságosabb, robosztusabb, jobb minőségű, és drámaian olcsóbb a vételi ára."Schwartz beszél a SCO vs. IBM ügyről. Szerinte az IBM azért nem egyezik meg a SCO-val, mert akkor másik 50 IP perrel találná szemben magát. Érdekes interjú. Érdemes elolvasni.

Az interjú itt.

A Groklaw nyílt levele Darl McBride-nak

Címkék

A Groklaw - egy technológiai témájú dolgokkal foglalkozó jogi hír- és kutatási oldal, amely jelenleg napi szinten ad jelentést a SCO ügyről - egy nyílt levelet küldött Darl McBride-nak a SCO vezérigazgatójának. A Groklaw a levelében kifejtette, hogy a SCO széleskörű jogi lépésekre számíthat, ha megpróbál számlát benyújtani a Linux felhasználóknak.

A levélben sorozatosan cáfolja a SCO azon állításait, amelyeket Darl McBride azon nyílt levelében olvashatunk, amelyet az Open Source közösséghez intézett.

A levél sokak szerint jól megfogalmazott, összeszedett, nyilvánvalóan jogász írhatta. Lássuk:* * *

Dear Mr. McBride,

Recently you wrote an "open letter to the open source community" published September 9, 2003 by LinuxWorld. This reply is from a group within the open source / free software community. Because you addressed your letter to our community-at-large, we thought we should answer you ourselves.

Our community isn't organized hierarchically like a corporation, so it has no CEO or overall leader in that sense, except that Linus Torvalds leads Linux kernel development and Richard Stallman leads the GNU Project and the Free Software Foundation (FSF). We have written this
letter together on the website, which is a research and news site currently dedicated to covering developments in the news about your company.

Quite a number in the group are software engineers, including
contributors to the Linux kernel. Others are proprietors of Linux-based businesses or executives or employees of Linux-related businesses. A few of us are lawyers, one is a paralegal, one a stockbroker, at least one is a physicist, a couple are journalists, one is a retired policeman, another a retired truck driver, others are in or have been in the
military, and some work or have worked in government. We also have experienced UNIX programmers among us who personally witnessed the history of UNIX since its inception, participated in its development, and know the software well. One of us is a non-technical grandmother who installed GNU/Linux herself recently and fell in love with the software.
We are a large, international and varied group of people, which is appropriate because GNU/Linux is developed and used worldwide and the
open source community to which you directed your letter is both global
and diverse.


VIOLATIONS OF THE GPL AND COPYRIGHT LAW

Our first purpose in writing to you is to draw to your attention that there are consequences to violating the GNU General Public License, the GPL.

You have continued to distribute the Linux kernel, despite alleging that it contains infringing source code. Simultaneously, you are attempting to compel purchase of "Linux Intellectual Property" licenses for
binary-only use, the terms of which are incompatible with freedoms granted under the GPL.

According to the GPL, any violation of its license terms automatically and immediately terminates your permission to modify or distribute the software or derivative works. Note the wording of the GPL:

"4. You may not copy, modify, sublicense, or distribute the Program

except as expressly provided under this License. Any attempt otherwise

to copy, modify, sublicense or distribute the Program is void, and will

automatically terminate your rights under this License. However, parties

who have received copies, or rights, from you under this License will

not have their licenses terminated so long as such parties remain in

full compliance.

"5. You are not required to accept this License, since you have not

signed it. However, nothing else grants you permission to modify or

distribute the Program or its derivative works. These actions are

prohibited by law if you do not accept this License. Therefore, by

modifying or distributing the Program (or any work based on the

Program), you indicate your acceptance of this License to do so, and all

its terms and conditions for copying, distributing or modifying the

Program or works based on it."

Releasing software under the GPL is not the same as releasing it into

the public domain. Authors retain their copyrights to software licensed

under the GPL. Even when authors assign their copyrights to someone

else, such as to the Free Software Foundation, the copyrights remain

valid, but with the new owner. Therefore, subsequent to termination of

your permissions under the GPL, you are in the unhappy position of

violating the copyrights of the software authors, if you continue to

distribute their software. Under copyright law, you are not allowed to

distribute at all without their permission -- and they have chosen to

grant that permission only by means of the GPL.

YOUR INVOICES WILL PROVOKE LEGAL ACTIONS

With regard to the invoices you have said you will mail out by October

15, we caution you that we believe that any such action will expose you

to civil lawsuits under both federal and state consumer protection laws,

as well as to possible criminal prosecution and penalties should state

and federal agencies, attorneys general, and district attorneys decide

to get involved, which we fully intend to ask them to do upon receipt of

any invoice from you.


For just one example of state consumer protection laws, we suggest that

you read Article 22-A of New York's General Business Law, Sections 349

and 350. Similar laws are on the books in other states. The Linux kernel

developers also have copyright law to rely upon to protect their

rights. Linux-based businesses may also avail themselves of other

commercial laws, such as trade libel law.

Should we receive invoices from you, we will initiate civil actions

under the anti-fraud and consumer protection statutes wherever we live,

according to our respective circumstances. We also intend to contact our

state attorneys general to request that they seek criminal as well as

civil penalties against you, in addition to injunctive relief. In

addition, we will file complaints with the FTC and other federal and

state agencies, as appropriate. Some individuals have already sent

letters to legislators in their respective states and in Washington,

DC.

We purchased GNU/Linux software in good faith, and we chose it precisely

because it is released under the GPL. We will not accept your attempt to

charge us a second time for a product that we have already bought and

paid for, most of us from vendors other than yourself. Furthermore, we

accept no license other than the GPL for GNU/Linux software. For one

reason, it is the permission to modify our software that we treasure.

Here is how the GPL FAQ explains the value of being able to modify

software: "A crucial aspect of free software is that users are free

to cooperate. It is absolutely essential to permit users who wish to

help each other to share their bug fixes and improvements with other

users." This is one key to the justly renowned stability and

security of GNU/Linux software, and we have no intention of reverting

back to the Dark Ages of binary-only software permissions, having

already made the conscious and informed decision to escape from and

avoid such like the plague.


WE DO BELIEVE IN COPYRIGHT LAW

Despite the false impression you attempt to paint in your letter -- that

we are a lawless community that doesn't respect copyright law -- we wish

to inform you that we do believe in copyright law. It is the legal

foundation upon which the GPL is built, and we rely upon it to protect

our rights. If the Linux kernel developers didn't believe in copyright,

they would have released their software into the public domain instead

of choosing to license it under the GPL.

You are required by law to respect the Linux kernel authors' copyrights,

as well as the license they chose to use, the GPL. It is hypocritical to

complain of alleged violations of your copyrights and licenses while at

the same time disregarding the equivalent legal rights of others.

YOU HAVE SHOWN US NO INFRINGING SOURCE CODE

You have refused to show us, much less prove, any infringing source

code. If you showed source code that proved to be infringing, it would

be immediately removed. Linus Torvalds, Richard Stallman, and the FSF's

attorney, Eben Moglen, have each told you so repeatedly as men of honor.

You refuse to let that happen. Why? It appears to us it is because you

have no infringing source code to show.

Your most recently filed 10Q shows your UNIX business declining, even as

Linux continues to grow in market acceptance. If you are refusing to

show the source code to prevent its removal because you wish to charge a

perpetual toll, in effect riding on the coattails of the more successful

GNU/Linux software, that is a shameful tactic. You cannot compel Linux

developers to retain your source code, even if any infringing code

existed. An alleged infringement is curable by removing the infringing

source code. If you can identify any infringing source code, please do

so, prove it is infringing, and let us remove it, because we surely do

not want it.

Even more shameful would be to try to destroy, co-opt, or make

proprietary, the labor of thousands of good-hearted volunteers who did

not volunteer to work for you, do not wish to be exploited by you for

your monetary gain, and have already chosen to release their creative

work under the GPL.

If your concern is that evidence will be removed before your claims

against IBM and its counterclaims against you can be heard in court,

that is a baseless concern, because the Linux source code is and always

will be publicly available for review by any court. Secrecy is not an

option under copyright law. If you make allegations of copyright

infringement, you must offer proof.

We do not need or want your legacy UNIX source code. It would be a

violation of the GPL to accept proprietary source code into the Linux

kernel. If there is proprietary source code in the kernel, we want it

removed just as badly as you do, perhaps more so, because we believe in

the GPL. Just because people will not walk through your front door to

buy your software, you have no right to compel them to pay you through

the back door for what they did not voluntarily choose to buy. You must,

therefore, try to find a viable business model without our compelled

participation.

Any claims you may have against IBM are between you and IBM. It is a

contractual dispute to which we are not parties. If you have any valid

contractual claims, they will be settled in a court of law, but your

remedies in that dispute lie with IBM and IBM alone, not with Linux

users. Even if some misappropriation were to be established, you cannot

collect twice for the same transgression. Further, we note that to date

you have filed no copyright claims against either IBM or Red Hat.

SOURCE CODE CAN BE BOTH IDENTICAL AND LEGAL -- THE BSD CONNECTION

Since the beginning of this year, you have claimed that there is

infringing source code taken from your version of UNIX and illegally

donated to Linux. But when two examples were shown at SCOForum, neither

supported your allegations. For six months, we have listened to analysts

say that some source code appeared similar, if not identical. Yet what

both they and you failed to investigate and determine is where that

source code originated, how and by whom it was added to the software at

issue, to whom it now belongs, and who is allowed to use it.

There is BSD source code in Linux which is legally there, and it will,

of course, be identical to or similar to BSD source code in your

software. The BSDi lawsuit revealed that the AT&T source codebase

includes a great deal of BSD source code. Caldera itself also later

released "Ancient UNIX" source code under a BSD-like license.

Consequently SysV contains substantial amounts of

source code that SCO and others have already licensed for use and that

the open source / free software community may legally use.

WE POLICE SOURCE CODE EFFECTIVELY -- DO YOU?

It took only a day or so for the source code shown at SCOForum to begin

to be identified by members of the open source community. If we do not

police source code effectively, as you claim, why were they able to so

quickly identify the code? You, in contrast, had no idea where that

source code came from, or to whom it belonged, or you surely would not

have used it to attempt to prove "infringement" of "your" source code.

The evidence indicates it is your due diligence system that is broken,

not ours.

If the legal departments of corporations represent to Linus Torvalds

that they have ownership rights to source code they donate, what more

can reasonably be expected? Do you have methods in place to prevent GPL

source code from being improperly inserted into your proprietary

software? Would you be willing to allow us to check for such violations?

We particularly wish to check your Linux Kernel Personality (LKP) source

code. We suspect that there may be GPL source code taken from the Linux

kernel and used in LKP without authorization, and we challenge you to

prove this has not happened by showing us your LKP source code,

throughout its complete development history to date.

Any proprietary software company can police its own source code in Linux

by checking the Linux source code. The Linux kernel is open to the

public. If you see any source code that you believe is yours, you have

only to speak up, and it will be immediately removed, upon confirmation

that it is infringing. That is what you should have done. It's a

superior feature in the open source method that all you need to do is

your own due diligence. Any interested party can verify that no

copyright infringements are taking place, simply by looking at the

published source code. This creates strong incentives for honesty and

provides far greater protection for copyright holders than your

proprietary system, where source code can be misappropriated and hidden

and no one can check for it, short of a lawsuit. Perhaps that is why

proprietary software companies are so often locked in legal battles,

something you rarely see in the open source / free software

community.

With regard to broken systems, how could it happen that while working

with the Linux kernel source code for years -- and your company did --

you never noticed any infringing source code? And how do you explain

that you released the allegedly infringing source code in your own

distributions of Linux for years without noticing it was in there?

If Linux did contain infringing UNIX source code that you failed to

notice for years, or noticed but did nothing to prevent, despite the

fact that the Linux source code was freely available at any time for

your review, it raises questions about your internal processes and

procedures for protecting your copyrights rather than demonstrating any

purported "breakdown" in the open source methodology.

INDEMNIFICATION IS A RED HERRING

Anyone considering surreptitiously inserting proprietary software source

code into Linux knows they would be quickly discovered and identified by

name. That is your indemnification and your protection. We believe our

system for policing source code is far more exacting and successful than

your own.

On the subject of indemnification, we note that the software license

which you propose to sell does not offer indemnification from lawsuits

brought by other companies. And we think we should inform you that

warranties are permitted under the GPL: "1. . . .You may charge a fee

for the physical act of transferring a copy, and you may at your option

offer warranty protection in exchange for a fee." We do not feel

we need it; the open source method protects us sufficiently, but it is

certainly negotiable if we wish to pay for it.

Proprietary software companies regularly file lawsuits against each

other for copyright infringement, patent and trademark violations.

Microsoft has been found guilty recently in several cases, but despite

the fact that the GNU Project was begun in 1984 and Linus Torvalds began

the Linux kernel in 1991, there has never been a claim of copyright

infringement that we know of in all those years, let alone a finding of

guilt. The record shows which method has done a better job of policing

source code, which reveals that your call for indemnification is, to put

it bluntly, FUD.

WE RESPECT THE LAW

With regard to your talk of having experienced a DDoS attack and your

request that we aggessively police the community, your request is like

us asking you to police Microsoft to ensure it never again breaks

antitrust law or never again violates anyone's patents, trademarks, or

copyrights.

Just because you are both proprietary software companies, it doesn't

follow that you can control what Microsoft does or should be criticized

as if you condoned their actions just because you are in the same

proprietary camp. Whether it is individuals or companies that break a

law, it is wrong, but it reflects only on the individual perpetrator. We

expect you to make that distinction for us, as we do for you.

There is a legal process for such matters. Not everyone accepts as

established fact that there was an attack. The doubt is based on the

fact that your employees were quoted as saying that reports of an attack

were untrue and that you took your servers down for maintenance yourself

and then had trouble getting them back up again. We observed that the

"attack" kept business hours, Utah time, for much of that week. If the

information your employees provided was false and there was in fact a

network denial of service attack on your servers, we naturally abhor

such behavior. Your implication that we would feel otherwise is deeply

insulting and offensive.

We would think, however, that a capable information technology company

that sells web services software would have the technical know-how to

handle a DDoS attack, if that is really what happened. Most such

companies do handle them without being brought to their knees for a

week. We are glad that you say you have since learned technical steps

you can take to protect yourself in the future.

WHO MAKES UP THE OPEN SOURCE COMMUNITY TODAY?

Kindly bring up-to-date your concept of the people and organizations

that make up the open source community. Your letter attempted to

portray us as a counter-cultural fringe element. On the contrary, the

truth is that our community is very much in the mainstream already and

includes many of the largest and most successful businesses today,

including IBM, Red Hat, Merrill Lynch, Lucent Technologies, Unilever,

Verisign, Dell, Amazon, Google, Dreamworks, Los Alamos National

Laboratory, Oak Ridge National Laboratory, the US Department of Defense,

the US military, and many other federal, state, and local governments

and governmental agencies, including, by the way, the town of St.

George, Utah.

You can read a list of companies and governmental agencies that use

GNU/Linux at Linux International's "Linux Success Stories" webpage (

http://www.li.org/success/ ). The Linux

Documentation Project also has such a webpage, called "Powered by

Linux!" ( http://sunsite.nus.edu.sg/pub/LDP/powered.html ) as does the

Linux in Business website ( http://m-tech.ab.ca/linux-biz/ ) website.

The Linux Counter calculates there are currently 18 million users of

GNU/Linux software.

With so many businesses, educational institutions, governmental

organizations, and individual users switching to our software, we must

be doing something right.

LINUX ALREADY HAS A BUSINESS MODEL

Your inability to make your Linux business a success, while unfortunate

for you, parallels your company's failure to make your UNIX business a

success. Perhaps the problem isn't Linux, the GPL, or the open source

business model.

Economist Amy Wohl ( http://amywohl.weblogger.com/ ) that "The Open

Source

Community Has a Business Model" and one that is successful. Ms. Wohl is

an analyst who has been covering IT for nearly 30 years and who

currently comments on the commercialization of new and emerging

technology. Here are her comments, which we include with her kind

permission:

"As an economist, let me assure you that Open Source has a business

model. It simply isn't one that a traditional company like SCO, which

expects to be paid for source code, can figure out. There are still lots

of companies that can charge for source code, but only when the source

code they are offering is valued by customers because it is unique or

convenient or offers other recognized value. Other companies (IBM is a

good example) charge for their Linux-compatible middleware source code,

but honor the Open Source community by supporting it with technical and

financial assistance and by strongly supporting the open standards that

permit customers to choose to use Open Source code when they prefer it

and purchased source code when they find it, for whatever reason, more

valuable. Then, as many posters have noted, IBM extends its business

model into the future by providing services to help customers plan,

design, implement, and customize whatever combinations of hardware, open

source, and proprietary code the customer prefers.

"That is the new business model and it seems to be a very successful

one."

DUAL LICENSING IS AN OPTION

We suggest that you ask your attorneys to explain the Lesser

General Public License (LGPL) to you (

http://www.gnu.org/licenses/lgpl.html ). If they are not familiar with

the LGPL, contact the Free Software Foundation, and they can help you

to resolve your misunderstanding and confusion about the GPL and how it

works and can explain to you how the LGPL can help your business to

thrive, should you insist on continuing with the old proprietary

software business model ( http://www.gnu.org/licenses/why-not-lgpl.html

). Companies such as MySQL distribute software simultaneously under both

open source and proprietary licenses, a practice that is acceptable, if

not

ideal, under the GPL.

It is not a violation of the GPL to sell software released under that

license ( http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMoney

). As the GPL FAQ points out, "The right to sell copies is part of the

definition of free software." The "free" in free software refers to

freedom, not that you can get it gratis. Many of us have paid for our

free software, simply because it's more convenient than downloading it

or as a way to thank the wonderful folks who developed and shared it

with the world. If you're looking for a successful business model, you

might consider the tried and true model of satisfied customers.

We have prepared a research document with links to evidence supporting

our position and other resources that you may find helpful, including

information about the GPL and the LGPL and how they work. The Inquirer

is making our research document available online (

http://www.theinquirer.net/?article=11649 ) . We hope it will help you

understand our position better and

prove a useful resource to you and others interested in this

controversy. We also believe it demonstrates that we have right on our

side and that we will win.

Thank you for writing to us. We appreciate the opportunity to answer

your letter. We trust you will give our response due consideration.

Thank you for your time.

Sincerely,

Members of The Open Source / Free Software Community at Groklaw

Copyright © Groklaw, 2003 Verbatim copying of this letter is

permitted in any medium, provided this notice is preserved.

Távoli root exploit az lsh-hoz

Címkék

A múlt héten bukkant fel az OpenSSH-ban egy puffer kezelési hiba, amelynek az eredménye egy két napos patch-fest lett.

Akkor különböző levelezési listákon többen is ajánlották, hogy érdemes cserélni OpenSSH-ról lsh-ra. Az lsh a GNU projekt OpenSSH helyettesítője, egy szabadon felhasználható ssh2 protokol implementáció. Úgy tűnik, hogy akik lecserélték az OpenSSH-t, rossz lóra tettek.Az lsh csapat egy ún. heap túlcsorulási hibát fedezett fel a lsh-ban, amelyet a rosszindulatú támadó kihasználva távolról "root" fiókhoz juthat az áldozat rendszerén. Sajnos ez nem csak elméleti hiba, készült az lsh 1.4.x-hez 'proof of concept' exploit is. Az lsh felhasználóknak azonnali frissítés javasolt!

A PATCH ITT.

FreeBSD Newbies FAK

Címkék

Nem, nem káromkodom :-) A FreeBSD FAK jelentése: FreeBSD Newbies First Aid Kit, azaz FreeBSD Kezdők Elsősegély Csomagja.

Az utóbbi időben egyre többen fordulnak a szabadon felhasználható, nyílt forrású BSD rendszerek felé hazánkban is. Ez talán kicsit köszönhető a HUP-nak is. Számos levelet kapok személy szerint olyan kérdésekkel, mint például: "honnan lehet letölteni?", "honnan induljak el?", "hol vannak a dokumentációk?", "hol vannak a levelezési listák?", stb.Valószínű, hogy a FreeBSD fejlesztők is számos ilyen jellegű levelet kaphattak, hiszen megalkották a Kezdők GYIK-ját.

A kezdőknek szóló dokumentum megtalálható a people.freebsd.org/~sue/newbies/fak.html URL-en.

Az ütemező fejlődésének mértéke

Címkék

Mark Wong egy csokor Linux ütemező benchmark eredményt postázott az LKML-re. A tesztek Rusty Russell Hackbench mérőprogramjával készültek.A tesztprogram 100 processzt indít, amelyek egy adott socket-en figyelnek. Ezekre a "hallgatózó" socketekre másik 100 processz ír, és közben a tesztprogram méri a felhasznált időt. Ezt a folyamatot többször megismétli a teszt úgy, hogy közben növeli a processz csoportok számát. Ezzel is értékelve az ütemező skálázhatóságát.

Az eredmények a 2.5.28 fejlesztői kerneltől indulnak, és egészen a mostani 2.6.0-test5 kernelnél fejeződnek be.

Andrew Morton (a jelenlegi 2.6-os kernel karbantartó) válaszolt Mark levelére, amelyben azt kérte, hogy valaki magyarázza el a teszteredmény számsorait, mert nem teljesen érti. Feltette a kérdést, hogy "Most akkor királyak vagyunk, vagy megszívtuk?". Erre Mark azt írta vissza, hogy "az általános trend azt mutatja, hogy minden javul, szóval úgy gondolom, hogy királyak vagyunk".

Teszteredmények:

Hackbench STP Results History for 2.5/2.6 (Linus BK fa)

Hackbench STP Results History for 2.5 mm/2.6 mm (-mm fa)

A thread itt és itt kezdődik.

Debian biztonsági figyelmeztetések

Címkék

Mozgalmas hét volt ez a biztonsági hibák terén, több kritikus figyelmeztetés is világot látott:

[2003. szept. 18.] DSA-387 gopher - puffer túlcsorulás

[2003. szept. 18.] DSA-386 libmailtools-perl - bemenet érvényesítési hiba

[2003. szept. 18.] DSA-385 hztty - puffer túlcsordulás

[2003. szept. 17.] DSA-384 sendmail - puffer túlcsordulás

[2003. szept. 17.] DSA-383 ssh-krb5 - lehetséges távoli sebezhetőség

PF kezdőknek

Címkék

A Newbie's Guide to Setting up PF on OpenBSD 3.x

Amióta (OBSD 3.0) lecserélték az ipf-et az OpenBSD-ben a pf-re (packet filter) azóta egy erőteljes tűzfalmegoldással rendelkezik az OpenBSD. A pf dokumentációja és a hozzá kapcsolódó FAQ nagyon jó, de talán sokkal több infót tartalmaz, mint amit egy kezdő egyszerre meg tud emészteni. Ezért Eric Bullen egy lépésről lépésre haladó végigjárást készített a kezdőknek, amelyben részletesen kitárgyalja a pf konfigurálásának fontosabb pontjait. A dokumentumot megtalálod itt.

UHU-Linux 1.1-beta1 (TMK)

Címkék

Megjelent az UHU-Linux 1.1 első publikus béta (tesztelésre szánt) kiadása.

Az alap rendszer iso fájlként az ftp://ftp.uhulinux.hu/uhu/1.1-beta1/ címről tölthető le, 80 perces CD-re írható ki. További csomagok az ftp://ftp.uhulinux.hu/uhu/dev/packages/ címen szerezhetők be. A tükörszerverek listája megtalálható a http://download.uhulinux.hu/MIRRORS címen.

A rendszer naprakész szoftverkomponensekből épül fel. Alapját a 2.4.22-es kernel adja, amelyet számtalan plusz szolgáltatással bővítettünk. Sokat fejlesztettünk a csatolható eszközök (például Pen drive-ok) felismerésén. Csomagjainkat a gcc 3.3.1-es verziójával fordítottuk, glibc

2.3.2-t használva.

A grafikus környezetek terén jelentős lépés GNOME 2.4, valamint a KDE-t is frissítettük 3.1.4-re. Újdonság az XFce 4.0-rc4, valamint számtalan egyéb ablakozó rendszer is megtalálható. Az alkalmazásfrissítések közül talán a Mozilla 1.4, Abiword 2.0, Gnumeric 1.2 érdemelnek külön említést.

Megkezdtük az alkalmazások egységes, konzisztens menürendszerbe szervezését, és a végleges 1.1 kiadásra el fogunk készülni ezzel. Az általunk megtervezett, mindig csak a telepített programokat tartalmazó menü a Gnome és KDE grafikus környezetek alatt éppúgy megjelenik, mint Blackbox, Enlightenment, FVWM, IceWM, Sawfish, Window Maker és XFce alatt.

A Gnome, KDE és XFce környezet, valamint az ezekbe illeszkedő GTK1, GTK2 és QT alapú alkalmazások egységes új kinézetet kaptak. A korábbi sárga-zöld Bumblebee-nél jóval elegánsabb Bluecurve nevű témát a Red Hat disztribúcióból kölcsönöztük.

A rendszerindítás, futásiszint-váltás, leállítás során futó szkriptek terén komoly átdolgozás történt. Ennek részeként például megszűnt a régi /etc/runlevel.conf fájl, helyét az /etc/runlevel.d könyvtár vette át, teljesen más szintaxist használva.

Az XFree86 csomag könyvtárstruktúrája is jelentős átszervezésen esett át.

A telepítőt, valamint az UHU Vezérlőközpontot újraírtuk GTK2 alapon, továbbá rengeteg hibajavítás és fejlesztés történt bennük. Ennek során például jelentősen átdolgoztuk a csomagválasztási lépést.

A csomagkezelőben (dpkg+apt) végzett változtatásoknak köszönhetően ezentúl gördülékeny lesz az előzetes (pre, beta stb.) csomagverziók kezelése. A frissítések pedig roppant hatékonyan letölthetők rsync protokoll használatával.

A béta kiadást tesztelésre szánjuk. Mindenféle hibajelentést szívesen fogadunk a dev@uhulinux.hu fejlesztői listánkra, viszont nem tudjuk garantálni, hogy bármiféle kérdésben segíteni fogunk, így aki stabil rendszert kíván használni, annak nem ajánljuk a béta kiadást, mindenképpen várja meg a végleges 1.1-et. Az 1.1-beta1 kiadásban súlyos hibáról nem tudunk, viszont bőven vannak még apró hibák vagy javítanivalók. Az egyik ilyen hiányosság az, hogy 1.0-ról egyelőre nem lehetséges frissíteni. Az ismert hibákról és hiányosságokról a telepítés végén, valamint a telepített rendszeren az UHU dokumentáció menüpont segítségével olvashatunk.

Jelen kiadás kódneve "TMK", mely mögött a "Tervszerű Megelőző Karbantartás" [1] és a "Tokiói Magyar Klub" [2] állnak.

[1] http://www.freeweb.hu/niva4ever/gep/01aug/17szabo.htm

[2] http://www.yudit.org/club/

FreeBSD stabilitás

Címkék

A finishez ért a FreeBSD 4.9 kiadási procedúra. Mi sem bizonyítja ezt jobban, mint Scott Long levele, amelyet a FreeBSD current@ levelezési listára küldött tegnap. A levélben Scott arra kérte a felhasználókat, hogy nyilvánítsák ki a véleményüket azzal kapcsolatban, hogy szerintük mennyire stabil a 4.9.Úgy gondolják, hogy a PAE által okozott instabilitást leküzdötték augusztus 31-én, ennek ellenére ha valaki stabilitási, korrupciós, stb. hibát észlel a rendszer futása közben, az most jelezze. A tesztelés erősen kívánatos!

Scott levele:

Date: Thu, 18 Sep 2003 23:21:20 -0600

From: Scott Long

To: Freebsd Current

Subject: 4.9 stability update

All,

We'd like to get a new poll on the stability and readiness of 4.9. The

belief is that the last of the PAE-induced instability was resolved on

August 31. Is anyone still experiencing unusual crashes, corruption,

etc, on a system that is running with up-to-date sources? Now is the

time to speak up and get the problems resolved so that we can make the

deadline by next weekend. Any new testing would be highly appreciated,

especially in reduced-memory configurations and of course >4GB PAE

configurations.

Thanks!

The Release Engineering Team

Új Quantian kiadás (0.3.9.1)

Címkék

Új Quantian kiadás érhető el 0.3.9.1-es verziószámmal. A Quantian Dirk Eddelbuettel (Debian-fejlesztő) Tudományos Linux terjesztése. A terjesztés KNOPPIX alapú, elsősorban a tudományos számításokat, kutatásokat szeretné támogatni. Ennek megfelelően, ilyen jellegű tevékenységet támogató csomagokból épül fel a rendszer.



Bejelentés:A new Quantian release (tentatively named 0.3.9.1 to show its status as a
test for a 0.4 release planned for the end of September) has been uploaded
a few days ago.



This note is being sent in the hope that some of you may be able to aid in
testing and debugging, or simply by offering helpful suggestions as many of
you have in the past. What is new:



o Updated Knoppix / clusterKnoppix iso images from early Sep 2003 with as
usual improved hardware detection and additional drivers, as well as
updated packages in their set.



o Updated Quantian packages, mostly from testing -- but R, Octave, GSL,
QuantLib from unstable.



o Not many new packages have added in 0.3.9.1; however R packages for coda,
mcmcpack, design, hmisc, car and Rcmd are now in; the 0.3.9.2 release
that is currently being prepared will have the ipe, felt and lush
packages requested by some of you.



o I will probably remove grass in 0.3.9.2 as a) the package is rather
big at 88mb, b) a little outdated in the Debian archive and the newer
unofficial I had been made aware of is no longer to be found and c) even
at 88mb still lacks example data which I'd have to add to make grass
more useful as installed.



o In that spirit, I would welcome feedback on what else could be removed
(in order to make space for Quantian apps) before the remaining Knoppix
functionality is considered too rudimentary. I essentially removed
openoffice, all i18n related packages, wine, gimp, all (most?) games, all
window managers but KDE and fluxbox, all non-free programs (but one
exception, ggobi), mysql server, php4, nessus, lvm10, nvtv, palm-pilot
related software, gnomemeeting.



o BUT still retain all of
- KDE Office plus the Gnome Office programs gnumeric and abiword, lyx.
- A lot of networking functionality related to PPP, ISDN etc
- A lot of sysadmin and networking tools
- A lot of other stuff
I would like to get a feel for where users think we can still make room
for quantitative software. Or maybe that the current mix is good?
I have put the detailed 'dpkg -l' list on the web at



http://dirk.eddelbuettel.com/quantian/quantian_0.3.9.2_packages.txt
for persual.



o As for suggestions for new packages: Keep'em coming! In general, what
works best is something that is already in Debian and packaged ok.
Barring that, an existing .deb helps a lot, but it must be reasonably
well done and of course be Free Software that can be redistributed.
I will not be in a position to add packages to Debian myself as I
have already a fair number to look after.



Thanks in advance for any and all comments,





Dirk

Dropline GNOME

Címkék

A Dropline GNOME egy GNOME terjesztés Slackware felhasználóknak.A Dropline kimondottan a Slackware-hoz van finomhangolva, tetszetős (és tradícionális) Slackware csomagformátumban (.tgz) érhető el. Az egész GNOME környezet i686-optimalizált csomagokból áll.

A Dropline telepítése installer-en keresztül történik. A jelenlegi Dropline felhasználók frissíthetik rendszerüket a Dropline installer-en keresztül. Az új felhasználónak pedig le kell tölteni az install-ert a letöltési oldalról.

Nézd meg a screenshot gyűjteményt itt.

Bootoljunk gyorsabban!

Címkék

Egy érdekes cikk jelent meg az IBM DeveloperWorks oldalain arról, hogy hogyan tudjuk csökkenteni a Linux rendszerünk bootolási idejét.

A Windows XP felhasználók gyakran emlegetik, hogy az operációs rendszerük 15-30 másodperc alatt elindul, viszont egy átlagos Linux munkaállomásnak (függően a boot időben elinduló szervizek számától) ennél jóval több időre van szüksége. Azok közül akik erre hivatkoznak kevesen tudják, hogy azért indul a Windows XP ennyire gyorsan, mert a Microsoft megváltoztatta az XP boot koncepcióját.

A régi rendszereknél (Win95, 98, Me, NT, 2k) boot időben a rendszer felderítette, hogy milyen eszközök vannak ráakasztva a gépre, azokat megszólította (hey, itt vagy? -> várta az ACK-ot, ezt jól meg lehet figyelni egy CD-ROM esetében, amire "ránéz" a win95-win9x mikor bootol), aztán ha az eszköz "visszaszólt", hogy "Yes" vagyok, akkor ment tovább a bootfolyamat. Ez elég hosszú ideig tartott.Az XP-nél telepítéskor volt egy hardver detektálás. Az ott felismert eszközökről a rendszer a későbbiekben feltetelezi, hogy a gépben vannak, NEM szólítja meg őket boot időben. Cserébe, amikor elindul az OS fél percig nem lehet hozzányúlni, mert semmi mást nem csinál, mint darálja a drivereket (erőteljes HDD tevékenység), és próbálja megkeresni az új stuffokat. Ezen kívül az XP szervizek is akkor indulnak el, amikor a felhasználó már látja az asztalt.

Hogy miért van ez így? Azért, mert a Microsoftnál rájöttek, hogy ennek pszichológiai jelentősege van. Az user ebből annyit érzékel, hogy "jééé, 32 másodperc volt a boot idő", de azt már kevésbé veszi észre, hogy utána még egy jó ideig nem lehet a rendszert használni.

Az hogy ez hogyan alakul a Linux rendszerek esetében, arról Árpi készített egy mérést májusban.

A developerworks-ön megjelent cikk azt taglalja, hogy hogyan lehet a boot időt csökkenteni. A cikk lényege, hogy a boot-idejű szervizeket párhuzamosan indítja el, ha van arra mód. Ezzel a módszerrel akár felére lehet csökkenteni a boot időt. Természetesen ez erősen függ a rendszertől is.

A cikk itt.

GNOME 2.4.0 beolvasztva a FreeBSD ports-ba

Címkék

Bár úgy volt, hogy a GNOME 2.4 csak a FreeBSD 4.9-RELEASE idején kerül be a hivatalos ports fába, de most mégis beolvasztásra került. Joe Marcus Clarke szerint az igények miatt, de ami fontosabb az az, hogy a FreeBSD 4.9-RELEASE-t minimum két héttel eltolták. Így a GNOME 2.4 már most elérhető a ports gyűjteményből.

Joe azt javasolja a portupgrade-del frissítőknek, hogy az alábbiak szerint járjanak el:

portupgrade -rf -m BATCH=yes atk

portupgrade -R -m BATCH=yes gnome2

Joe levele itt.