Re: Problem with cprivmsg.txt

On 2010-11-30 at 21:23:38 [+0100], Miroslav Stimac <Miroslav.Stimac <at> gmx.de> 
wrote:
> > That suggests, as François offered, that the second program does
> > something
> > "intelligent". To verify the suspicion you can md5sum two CDs of the same
> > Haiku version burnt with either program and compare with the md5sum of the
> > original image.
> 
> Now I am totally confused.
> I created MD5sums for each file on both CD-Rs (one burnt with Neto and 
> works, one burnt with CDBurnerXP and does not work) and compared them all 
> with PSPad. There are no differences.
> All MD5sums are exactly matching on both CD-Rs.
> 
> Perhaps it is really a compatibility problem with the DVD drive of my 
> notebook and it does not like CDs that are burnt with CDBurnerXP.
> However, both CD-Rs were recorded by using my main PC (tower) and it has an 
> other DVD drive than the notebook. I created the MD5sums by using my main 
> PC, too.

It would help to verify the checksums on the target machine. Ideally under 
both Haiku and some other OS (Linux).

> Is it possible that CDBurnerXP does not burn the CD-Rs in the same way as 
> Nero, although I use the same hardware?

I don't know much about how CDs work. AFAIK a CD isn't accessible as a single 
linearly addressable data storage, but it has a TOC that describes individual 
tracks. Maybe the two programs write different TOC data and Haiku doesn't 
interpret them correctly in one case.

Re: Problem with cprivmsg.txt

On Wed, Dec 1, 2010 at 7:59 AM, Ingo Weinhold <ingo_weinhold@...> wrote:
> On 2010-11-30 at 21:23:38 [+0100], Miroslav Stimac <Miroslav.Stimac <at> gmx.de>
> wrote:
>> > That suggests, as François offered, that the second program does
>> > something
>> > "intelligent". To verify the suspicion you can md5sum two CDs of the same
>> > Haiku version burnt with either program and compare with the md5sum of the
>> > original image.

When I happen to use Windows to burn, I generally use CDBurnerXP.  II
would generally burn the Anyboot image.   I never tried installing
Haiku from it, but it always seemed like the resulting live CD was as
unstable as can be, and I could KDL it pretty fast.  On the same
revision, I never have these problems when I write out to an actual
partition.

It would require more testing on my part to make sure this is true
100% of the time definitively, but I kind of think this is the case.

- joe

lines of source code in Haiku?

Haiku threads vs pthreads

Re: lines of source code in Haiku?

> There's an interesting article on Ars Technica about how big the
> Linux kernel is and how frequently it is patched:
> In the discussion thread there is a reference to lines of code
> for various other operating systems:
X-archive-position: 16987
X-ecartis-version: Ecartis v1.0.0
Sender: haiku-bounce@...
Errors-to: haiku-bounce@...
X-original-sender: kallisti5@...
Precedence: normal
Reply-To: haiku@...
List-help: <mailto:ecartis@...?Subject=help>
List-unsubscribe: <haiku-request@...?Subject=unsubscribe>
List-software: Ecartis version 1.0.0
List-Id: haiku <haiku.freelists.org>
X-List-ID: haiku <haiku.freelists.org>
List-subscribe: <haiku-request@...?Subject=subscribe>
List-owner: <mailto:axeld@...>
List-post: <mailto:haiku@...>
List-archive: <http://www.freelists.org/archives/haiku>
X-list: haiku

> http://en.wikipedia.org/wiki/Source_lines_of_code [2]

> Can someone who knows tell me how many lines of code are in Haiku
> kernel? I will update the wiki entry. I think lines of code in a
> hybrid kernel would be interesting to contrast with the other
> monolithic kernels.

 ~ r39402

 src/add-ons/kernel/     2,304,898  (drivers and kernel add-ons)
 src/system/               940,716  (core kernel, boot loader)
 src/servers/              271,711  (system servers)

 To be honest.. i think this number is more valid
 (as Haiku is *way* more then it's tiny kernel)

 src/                   23,565,413   (23.5 Mil)

 The src/add-ons/kernel number might be off a little as I
 have some uncommitted code in there... but if you round it
 the number should be pretty darn close.

 Thanks!
  -- Alex

cpufrequency acpi driver

Hi,

just fix some smaller issues in the cpufrequency preferences app and got  
the following idea.

Add the moment there is only a EST driver for old intel cpu's. If there is  
anybody interesting in kernel/driver development but wasn't keen enough to  
start because driver development seems to be too complex, this a good  
opportunity to get into it. Writing a acpi cpu frequency driver should be  
relatively simple. The driver must just be able to read all cpu states,  
the current state and be able to switch states. Just look at the acpi  
battery driver to get a starting point.

If you are interested I can give you more informations.

Regards,
	Clemens

Re: lines of source code in Haiku?

On 2010-12-01 at 22:48:23 [+0100], kallisti5 <kallisti5@...> wrote:
> > There's an interesting article on Ars Technica about how big the
> > Linux kernel is and how frequently it is patched:
> > In the discussion thread there is a reference to lines of code
> > for various other operating systems:
> X-archive-position: 16987
> X-ecartis-version: Ecartis v1.0.0
> Sender: haiku-bounce@...
> Errors-to: haiku-bounce@...
> X-original-sender: kallisti5@...
> Precedence: normal
> Reply-To: haiku@...
> List-help: <mailto:ecartis@...?Subject=help>
> List-unsubscribe: <haiku-request@...?Subject=unsubscribe>
> List-software: Ecartis version 1.0.0
> List-Id: haiku <haiku.freelists.org>
> X-List-ID: haiku <haiku.freelists.org>
> List-subscribe: <haiku-request@...?Subject=subscribe>
> List-owner: <mailto:axeld@...>
> List-post: <mailto:haiku@...>
> List-archive: <http://www.freelists.org/archives/haiku>
> X-list: haiku

Any idea what has happened here or rather why (the mail body and mail 
header being partially mixed) and where it happened? Seems only to concern 
mails send by you.

> > http://en.wikipedia.org/wiki/Source_lines_of_code [2]
> 
> > Can someone who knows tell me how many lines of code are in Haiku
> > kernel? I will update the wiki entry. I think lines of code in a
> > hybrid kernel would be interesting to contrast with the other
> > monolithic kernels.
> 
>  ~ r39402
> 
>  src/add-ons/kernel/     2,304,898  (drivers and kernel add-ons)
>  src/system/               940,716  (core kernel, boot loader)
>  src/servers/              271,711  (system servers)
> 
>  To be honest.. i think this number is more valid
>  (as Haiku is *way* more then it's tiny kernel)
> 
>  src/                   23,565,413   (23.5 Mil)

*shrug* This is so irrelevant and really saying nothing. The sources 
contain heaps of imported code, BTW (e.g. glibc, the GNU utils, gdb,...). 
Ohloh also has line number statistics (that say just as little).

CU, Ingo

Re: Haiku threads vs pthreads

On 2010-12-01 at 22:23:20 [+0100], hudsonco1@... wrote:
> I'm reading up on using threads on Haiku. I see that pthreads are available 
> on Haiku. Can anyone tell me
> if there are advantages to using Haiku native threads versus pthreads? I'm 
> interested in stability, performance,
> compatibility, features, etc.

No relevant difference. In fact since a while back (earlier this year?) they 
do virtually the same under the hood (the native threads also creating 
pthread objects internally). Use whatever interface you like better. Use 
pthreads when you need portability.

CU, Ingo

Re: lines of source code in Haiku?

Re: lines of source code in Haiku?

On Wed, Dec 1, 2010 at 5:57 PM,  <hudsonco1@...> wrote:
>>src/add-ons/kernel/     2,304,898  (drivers and kernel add-ons)
>>src/system/               940,716  (core kernel, boot loader)

> Thanks, the wiki entry is updated:
>
> http://en.wikipedia.org/wiki/Source_lines_of_code

On the wiki, the units are in millions, and you put 941k.  Somebody
may read that wrong and think it is 941 billion (941,000 * 1 million)
lines instead of 0.941 million.  Granted, they would probably have to
be kind of dumb to believe that, but I guess I'm just saying that
0.941 is correct given the column units they're using.  Regardless,
like Ingo said, numbers like these are kind of useless in a practical
sense.

- joe