Linux-Development-Sys Digest #300, Volume #6     Mon, 18 Jan 99 14:13:59 EST

Contents:
  Linux For PDAs ("N.C.Rajadurai")
  Re: - deprecated - why? (Johan Kullstam)
  Call for Articles - Crossroads Magazine (Kim Moorman)
  Re: 2.2.0-pre7 won't compile. (Piniek (aka Piotr Ingling))
  Re: 2.2.0-pre7 won't compile. (Chris Rankin)
  How to find lost ext2 partitions (Yann Dupont)
  Re: Update from 2.0.29 to 2.0.36 (Frank Hale)
  Re: disheartened gnome developer ("Duncan Rose")
  Re: disheartened gnome developer ([EMAIL PROTECTED])
  Re: mmap problem (Bryan Hackney)
  fsync /dev/cua*? ("Pavel Tkatchouk")
  Re: - deprecated - why? (Josef Moellers)
  Re: disheartened gnome developer ([EMAIL PROTECTED])

----------------------------------------------------------------------------

From: "N.C.Rajadurai" <[EMAIL PROTECTED]>
Subject: Linux For PDAs
Date: Mon, 18 Jan 1999 23:48:12 +1100
Reply-To: "N.C.Rajadurai" <[EMAIL PROTECTED]>

Hi....
        I am interested in working on a port for linux -> PDAs....???
Perhaps starting with the Cassiopeia.... I have started doing some reading
up... I have been doing some reading up.... I am but a meager student...
Does any one know of work that is in progress.. news grps... misc?

thanks
Niroshan

================================================================================

Niroshan Carrol Rajadurai
Bach. Computer Science/ Bach. Electrical Engineering
The University Of Melbourne





------------------------------

From: Johan Kullstam <[EMAIL PROTECTED]>
Subject: Re: - deprecated - why?
Date: 18 Jan 1999 09:05:49 -0500

Josef Moellers <[EMAIL PROTECTED]> writes:

> Matthew Hannigan wrote:
> > 
> > In article <[EMAIL PROTECTED]>,
> > Tristan Wibberley  <[EMAIL PROTECTED]> wrote:
> > >That's insane! All the options should have '-' prefixed.
> > 
> > Tell that to the authors of tar and BSD ps.
> 
> At least with "tar", there's a reason for not having a dash: The
> "options" are not optional! Same applies to "ar".

not that i ever use a minus with tar (except as a filename meaning
stdout), but most of the options are optional.  i mean, you have to
pick a command like one of c, x, t &c, but things like `v', `f', and
`b' *are* options.

> I agree wrt "ps".

why?  ps takes no filename arguments.  there is no reason to need to
distinguish the file `aux' from ps args a, u and x.  thus the options
are really arguments, there is no confusion with files and ps takes no
minus signs.

-- 
johan kullstam

------------------------------

From: Kim Moorman <[EMAIL PROTECTED]>
Subject: Call for Articles - Crossroads Magazine
Date: Mon, 18 Jan 1999 09:47:39 -0500
Reply-To: [EMAIL PROTECTED]

Crossroads, the Association for Computing Machinery 
                        Student Magazine
                        Linux (Fall 1999)
              DUE DATE:           March 2, 1999 
              SUBMISSION ADDRESS:  [EMAIL PROTECTED]
              INFORMATION:         [EMAIL PROTECTED]
                                   http://www.acm.org/crossroads/

The Crossroads editorial staff invites authors to submit articles
dealing with topics drawn from several areas pertaining to Linux.  
The following partial list of topics is provided to give prospective
authors ideas for articles and is by no means exhaustive; other relevant
topics will be considered.
-History and future of Linux
-Interaction between Linux and other operating systems; Interaction
between Linux and various windowing systems
-Software development issues and projects; Compatibility and portability
issues; Linux system administration
-Linux and the Internet
-Legal issues surrounding Linux and licensing
-Productivity software and Linux
-Linux Multimedia Development (e.g. 3D graphics rendering etc)

Articles should include a basic description of the kinds of problems
being worked on, the state of the art of research, the state of the art
of commercial applications, open problems, or future research/commercial
development trends. Interviews with researchers; reviews of related
books, software, videos, or conferences; and opinion columns on related
issues are also welcome.  We especially encourage both undergraduate and
graduate students to submit articles.  However, articles written or
coauthored by professionals will also be considered.

Crossroads articles should be written for a broad audience.  They should
be easily understandable by someone who has had only the most basic
computer science instruction, and yet still be interesting to the
advanced computer enthusiast.  Articles longer than 6000 words will
generally not be considered for publication.  Feature articles should be
between 1500 and 6000 words; reviews should be between 800 and 2000
words; and opinion columns should be between 800 and 3000 words.
Articles should be written in a magazine style rather than a research
paper style.  In consideration of our diverse readership, authors should
try to use language that is inclusive of people regardless of their
gender, race, religion, nationality, or field of study.  Additional
writing guidelines and submission information are available online at
the Crossroads web site 
http://www.acm.org/crossroads/doc/information/writing.html.

Crossroads is published both online and in print.  We have a print
circulation of about 15,000.  All back issues are available for free on
our website.  Authors that have an article printed in Crossroads can 
receive complementary copies of the issue they were published in.

All submissions should be formatted in HTML or plain text format and
emailed to [EMAIL PROTECTED]  Please include your submission in the
body of your message: DO NOT include it as an attachment.  If you have
any images or graphics, put them somewhere on your own website and use a
full URL reference to them inside the article (example use img src=
http://www.myhome.edu/me/pic1.gif).
Submissions are due March 2, 1999.  They will be reviewed shortly
thereafter and authors of accepted submissions will be notified within
two to three weeks of the deadline.  For detailed submission guidelines,
see http://www.acm.org/crossroads/doc/information/writing.html

Prospective authors are invited to send email to the editors of
Crossroads at [EMAIL PROTECTED] indicating their intention to submit an
article.  In this way we can keep everyone informed of any changes in
deadlines or formats and make sure we have a good variety of articles. 
General questions should also be sent to the Crossroads editors.

------------------------------

From: [EMAIL PROTECTED] (Piniek (aka Piotr Ingling))
Subject: Re: 2.2.0-pre7 won't compile.
Date: Mon, 18 Jan 1999 15:38:53 GMT
Reply-To: [EMAIL PROTECTED]

Dnia Mon, 18 Jan 1999 05:10:20 GMT, Mark Swanson <[EMAIL PROTECTED]>
napisał(a):

[...]
>No one else seems to be complaining about this so..
>(.config file for anyone who wishes)

[...]
>core.o(.text+0x17bb): undefined reference to `csum_partial'
>core.o(.text+0x17fd): undefined reference to `csum_partial'
>core.o(.text+0x187c): undefined reference to `csum_partial_copy_generic'

And so on...

Go to linux/arch/i386/lib and delete file checksum.c and you should be able to
compile.

                         Piotr Ingling

                e-mail: [EMAIL PROTECTED]

------------------------------

From: Chris Rankin <[EMAIL PROTECTED]>
Subject: Re: 2.2.0-pre7 won't compile.
Date: Mon, 18 Jan 1999 10:54:23 -0500

Mark Swanson wrote:
> No one else seems to be complaining about this so..
> (.config file for anyone who wishes)

make dep; make clean; make bzImage ...?

Chris.

------------------------------

From: [EMAIL PROTECTED] (Yann Dupont)
Subject: How to find lost ext2 partitions
Date: 18 Jan 1999 14:44:21 GMT

Thanks to all the persons which responded. 

I was finally able to find the partitions again with the combination of
fixdisktable (located my partitions ) but seg faults (*),
the advice and program from David D. Gitchell,

and finally, with the program gpart wich was able to rewrite a good
partition table.

The main problem was that the geometry reported by the disk didn't 
correspond to the geometry of the disk when the partition were created :
Thoses disks were quite old, and never reformated (thanks linux
stability) sine 3 years, and in fact the geometry wasn't good 
(they were probably  formatted by another SCSI adaptor, I don't remember)

(*) I suppose that's why fixdisktable seg faults...

Anyway thanks a lot everybody !

Yann.
--
\|/ ____ \|/ Fac. des sciences de Nantes-Linux-Python-IPv6-ATM-BONOM....
"@'/ ,. \@"  Tel :(+33) [0]251125865(AM)[0]251125857(PM)[0]251127866(Fax)
/_| \__/ |_\ [EMAIL PROTECTED]
   \__U_/    http://www.unantes.univ-nantes.fr/~dupont

------------------------------

From: Frank Hale <[EMAIL PROTECTED]>
Subject: Re: Update from 2.0.29 to 2.0.36
Date: 15 Jan 1999 22:05:03 GMT

Marc SCHAEFER wrote:
> 
> Fotis D. Zagoras <[EMAIL PROTECTED]> wrote:
> > The problem is with the first 2 lines. This messages  are produced
> > by  klogd deamon (I suppose) and maybe have some relation with
> > the System.map file. Any suggestion to resolve this problem.
> 
> cp /usr/src/linux-2.0.36/System.map /

I have the same problems and in RH the System.map goes in /boot . If I
had a quarter for everytime someone asks me "did you copy the
/usr/src/linux/System.map to the /boot directory?" Man I tell you I
would be freak'n rich. And the answer is yes and the errors are still
there. I have all the updates and the errors are still there and noone
knows the answer as why. If you do a search on dejanews about 80% of the
answers are cp /usr/src/linux/System.map /boot/System.map-x.x.x 

-- 
From:      Frank Hale
Email:     [EMAIL PROTECTED]
ICQ:       7205161
Homepage:  http://members.xoom.com/frankhale/
Jade:      http://jade.netpedia.net/

Windows VirusScan 1.0 - "Windows found: Remove it? (Y/N)"

------------------------------

From: "Duncan Rose" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 13 Jan 1999 11:22:55 GMT



[EMAIL PROTECTED] wrote in article <77g52c$88q$[EMAIL PROTECTED]>...
> In article <[EMAIL PROTECTED]>,
>   [EMAIL PROTECTED] wrote:
> > On Mon, 11 Jan 1999 17:13:58 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
> > posted:
> > >>  You'll have to be more specific.
> > >>
> > >>  All I've found so far in the Redhat control-panel are like thus:
> > >>
> > >> Red Hat Linux netcfg 2.18
> > >> Copyright (C) 1996, 1997 Red Hat Software
> > >> Redistributable under the terms of the GNU General Public License
> > >
> > >Gee, so the control panel is owned by Red Hat, and they could
rerelease them
> > >tomorrow under a proprietary license. Just like I said they could (and
said
> > >they wont do it) when you called me a liar.
> > >
> > >I suppose you wont apologize, of course.
> 
> > You miss the consideration that the third line of that comment shows
> > a *really big stick* that strongly discourages Red Hat Software from
> > doing a proprietary release.
> <Snip reasons why Red Hat wont do it>
> 
> No, I didn´t miss anything.
> That is why I said they would not do it. All I said is that they *can*
> do it. Going back to what I actually said a few posts ago:
> 
> Red Hat does own software, unlike Jedi said, and they could rerelease
> that software in a proprietary manner if they wanted (but they won´t),
and
> Troll Tech is the only company I know that has taken measures to
guarantee
> it wont do such a thing (Even if some believe those measures wont be
> effective).
> 

I don't think you are right. According to the GPL, under which terms the RH
software you're talking about is distributed, if the existing (freely
available)
source is used to build the new version, the new version must be GPLed
too (in my understanding -- correct me if I'm wrong).

The only way I can see RH releasing a proprietary version is if they
TOTALLY
rewrite the app, using NONE of their existing (GPLed) source. They
certainly
could not release the existing app under a different license. (Maybe
technically
they could, but it would be pointless as already mentioned by the poster).

If they do anything else they're in violation of the GPL, which, let's face
it, is
not likely to be a barrier if they wanted to do such a thing (as far as I
know the
GPL has never been tested in court, so we still don't know where developers
would stand if they broke the sentiment/letter of the GPL).

Do I have an incorrect understanding of the GPL here?

        -Duncan


> I suppose everyone agrees those things are correct, so as long as replies
> go in the lines of "netcfg is not a library" or "Red Hat will not do
> that" or "Qt is not GPL"... sure, I agree with you all :-)
> 
> --
> Roberto Alsina (KDE developer, MFCH)&#137;
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own  
 
> 

------------------------------

From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Mon, 18 Jan 1999 15:23:11 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] wrote:
> On Fri, 15 Jan 1999 17:15:18 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
> >In article <[EMAIL PROTECTED]>,
> >  [EMAIL PROTECTED] wrote:
> >> >And how is that related to whatever I said? I was just noting that
> >> >there is really very little interest on coding in C instead of C++.
> >> >
> >>
> >> Oh. Really? How does the fact that no one wants to use a C "extension" to
> >> a C++ toolkit indicate that there is very little interest on coding in C
> >> instead of C++.
> >
> >Correct me if I am wrong, but I thought "instead" meant "in replacement of".
> >A C binding for that C++ toolkit does give a way to code in C instead of C++
> >doesn't it?
>
> Yes it gives you a way but not the best way. Are you talking about
> "inerest in C" in the context of just Qt programmers or in the context of
> all toolkit programmers.

I was thinking mostly of people who are not using either yet.
Those who have chosen are unlikely to change one way or the other.

> In the context of all toolkit programmers there's
> plenty of interest in c, but I wouldn't expect to find such interest in
> the Qt community.

I announced it on linux-announce, not in the "just Qt hackers" list :-)

> >> Did it ever occur to you that people who want to program
> >> in C are busy coding away in native C toolkits, i.e GTK+??
> >
> >Yup, it has. Then I discarded it as just something that may or may not be
true
> >and of which I have no clue about, unlike what I did mention.
>
> Well I can say many people are coding away in Gtk. (Which I should be
> doing right now, instead of wasting my time in this thread.)

If I ment to just throw claims I have no proof about, I would just say
"they are coding in C because the bindings suck more". Which I won't say
because I don't know them well :-)

> <sorry - I can't resist>
> >Whatever floats your boat.
> Whatever bloats your code.
> </sorry - I can't resist>

You should have :-P

--
Roberto Alsina (KDE developer, MFCH)

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

------------------------------

From: Bryan Hackney <[EMAIL PROTECTED]>
Subject: Re: mmap problem
Date: Mon, 18 Jan 1999 12:33:36 -0600
Reply-To: [EMAIL PROTECTED]

James Youngman wrote:
> 
> Marcin Szyllo <[EMAIL PROTECTED]> writes:
> 
> > I'm battling to understand why mmap (as in the attached example) does not
> > allow me to mmap a block device - a partition... Why NOT?
> 
> [...]
> 
> > mmap: Operation not supported by device
> 
> Yep.  That is indeed the reason.
> 

...


Let me try. I had this same question a few weeks ago.

Mmap() is mapping process virtual memory to physical memory.
At least that is typical. I'm sure you can get fancy and extend
mmap() to all kinds of situations, but the driver might get real
fun.

Anyway, after an mmap(), the kernel calls your nopage() function
on page faults to do the mapping. After the page has been mapped,
there are no more page faults, so your access of the mmaped
memory doesn't generate any more events that the driver or the
kernel can care about.

This doesn't explain why you can mmap a file and not a partition.
I need to dig into that driver someday.


BH

-- 
Bryan Hackney / BHC / bhackneyatexpress-news.net
*
* Failure teaches only what not to do next time.
*
* Would you trust your mission-critical computing to a company
* that sells stuffed toys?

------------------------------

From: "Pavel Tkatchouk" <[EMAIL PROTECTED]>
Subject: fsync /dev/cua*?
Date: Mon, 18 Jan 1999 09:46:07 -0800

Looks like it didn't make to the group from the first shot,
second try (sorry if you see it 2nd time):

I need to print from Java through serial port. So I use
native methods to set serial port parameters (I know
about relevant 1.1.* API, but for a number of reasons
I have to use 1.0.2).

Before printing byte CTS is checked.

Problem:
Slow CPU(486)/fast printer (thermo) combination works fine.
On fast CPU(586)/slow printer(dot matrix) some data (around
4K mark) disappears.

Guess:
On printing to /dev/cua* data actually goes not directly to UART's
but to some buffer (file system, serial driver's?)  and so when
printer's buffer is full, CTS is low, I stop output data but
buffer doesn't know about that and keeps sending
data to UART where they're discarded if flow control is off. If flow
control is on after about the same 4k output blocks.

Questions:
1. What would I do to make sure every byte is actually sent from
UART to printer and not get lost?
2. What is the actual data flow - write(/dev/cua*,s)->Java buffer->file
system
buffer->serial driver's buffer->UART's output buffer->printer's buffer?


Thank you for your time,

Pavel




------------------------------

From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: - deprecated - why?
Date: Mon, 18 Jan 1999 16:11:15 +0100

Johan Kullstam wrote:

[ ... ]

> not that i ever use a minus with tar (except as a filename meaning
> stdout), but most of the options are optional.  i mean, you have to
> pick a command like one of c, x, t &c, but things like `v', `f', and
> `b' *are* options.

I hope I didn't start a useless never-ending-debate but ...

In my (rather old) manual, "tar" does not have "options", it has a "key"
which is not optional. (I have just looked into the linux "info tar" and
it does say "options" there.) The "key" consists of a function letter
(which is mandatory) and zero or more function modifiers. No optional
option, hence no dash.

> > I agree wrt "ps".
> 
> why?  ps takes no filename arguments.  there is no reason to need to
> distinguish the file `aux' from ps args a, u and x.  thus the options
> are really arguments, there is no confusion with files and ps takes no
> minus signs.

I agree, "ps" does not take filename arguments, but it does take pid
arguments. Agreed, there can not be any confusion, because options are
letters and pids are numbers. However, "ps" alone works, so there are
optional options, hence a dash.

BTW I couldn't care less. I am used to not specifying a dash with tar
everywhere and specifying one with ps on my SVR4 based WS at work and
none on my FreeBSD box at home.

-- 
Josef Moellers          [EMAIL PROTECTED]
        UNIX - Live free or die!
PS Dieser Artikel enthaelt einzig und allein meine persoenlichen
Ansichten!
PS This article contains my own, personal opinion only!

------------------------------

From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Mon, 18 Jan 1999 15:31:57 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] wrote:
> On Fri, 15 Jan 1999 17:20:47 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
> >In article <77ma2l$usm$[EMAIL PROTECTED]>,
> >  [EMAIL PROTECTED] wrote:
> >[Snip some reasonable reasons to not use Qt from C]
> >
> >1) Don't all these arguments apply equally well to any language binding?
>
> No they don't. I stated why in a previous post. See Steve's post in this
> thread some more concrete explainations why.

Will look it up and reply there.

>
> >2) Wouldn't those who would be discouraged by the poor Qt C binding first
> >   have to download it? I mean, I will even say that it is not really a
> >   good one, but as I said, people wouldn't even download it to see if
> >   it sucks. At least I would do it like that.
> >
>
> I don't think many expected it to be good.

Well, it's not too shabby. It is easier for me to use it than Gtk, but I am
far from impartial.

> Furthermore, I think most
> people who are interested in open source C GUI programing are already
> involved in Gtk.

If the programming talent well is dried up at this stage, we are all in
way deep trouble. I don't think it has, though.

At least, consider that there are thousands of new programmers each year,
of which a couple hundreds may turn to open source programming.
I may guess most of them are not C programmers these days, though, considering
what is being taught at schools these days.

> In other words, even if you wrote a C binding to Qt
> that was a good as native C programming in Gtk, and had a license that I
> equally liked, I would still stay with Gtk because I already know it.
>
> Some day though, I'll probably use the python,  perl, or some other
> binding as well. I'll stay with GTK because I already know the widgets.

Good for you. I have my doubts about how general this point of view is,
of course.

--
Roberto Alsina (KDE programmer, MFCH)

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list (and comp.os.linux.development.system) via:

    Internet: [EMAIL PROTECTED]

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Development-System Digest
******************************

Reply via email to