date:20070225

Re: I love goodbye-microsoft.com

2007-02-25 Thread Tim Cutts



On 24 Feb 2007, at 12:44 pm, [EMAIL PROTECTED] wrote:


Strangely, I feel a tiny pang of guilt. I now have an apple box
for the first time in decades.  One of the main deciding factors  
was to

buy unixy goodness :-)


That was my main reason for buying an Apple four or so years ago.


but also to get some exposure to OSX. I tried for
a while to live in OSX, but in the end I installed Debian on it. It's
not that I couldn't build everything I wanted, it's just that not  
having
everything just work is like going back in time ten years. It's not  
that

there isn't ports or fink, but there isn't debian, short of a full
install, and the alternatives don't measure up.  It's not that I
couldn't take debian to osx (in my fevered imagination), it's that I'm
too lazy to even try.


Well, that's sort of what fink is.

I have to sheepishly admit that I use OS X every day on my Apple  
machines.  I don't have Debian installed on any of them - I do my DD  
work on server machines.  The main reason for that is that I still  
think that for GUI things Apple have the edge over any of the Linux  
alternatives.  The UI is simple, functional, and well integrated.   
Debian is fabulous in so many ways, but I still don't think any Linux  
distribution really cuts it on the desktop (although I do administer  
a network of 300 Debian desktop machines at work, so I don't think  
it's *that* bad).


I've also been very pleased to not the fairly vibrant OSS community  
that has grown up around OS X.  There is a *lot* of really quite good  
free software work going on for OS X (Fink, Camino, Adium,  
SSHKeychain being the principal ones I use every single day).  Yes,  
there's a lot of Windows-style shareware too, but I think the free  
stuff is reaching critical mass, when it becomes difficult for the  
shareware authors to justify their position, when that developer over  
there --- is offering something open and free.


Having said that, when I can justify it to my good lady wife, I'm  
looking forward to buying an Intel Mac and being able to run OS X and  
Linux simultaneously - I tried doing DD work under Virtual PC for a  
while, but it was a non-starter.  Just way too slow.  Just the  
configure script on one of my packages (am-utils, which admittedly  
has the configure script from hell) took more than an hour to run  
under Virtual PC on my 1 GHz PowerBook.


Tim


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Roundcube

2007-02-25 Thread José Luis Tallón

gregor herrmann wrote:
 On Sat, 24 Feb 2007 23:27:26 -0200, Fernando M.M. wrote:

   
 Althought i have already seen some old discussion about packing the
 webmail Roundcube (1) i have not found the package using the
 package search (2).
 
 [..]
   
 Is someone working on it?
 

 Seems so:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333756
 http://lists.debian.org/debian-webapps/2007/02/msg0.html
 http://lists.debian.org/debian-mentors/2007/02/msg00098.html
   
I, for one, have kept and maintain my own Roundcube packages since Feb 2005.
However, being beta software, and considering that it needs a quite
robust dbconfig-common infrastructure to auto-configure it if packaging
properly, I prefered to wait a bit.

The fact that Neil posted an ITP also kept me away from posting my packages.



Let's see what happens in the next few days. I can also 'dive in' and
provide some patches :-)


Regards,

J.L.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

On maintainers not responding to bugs

2007-02-25 Thread Nikita V. Youshchenko

Hello.

What do people look on the following idea: not allow packages to migrate 
from sid to testing if they have unanswered bug reports with severity = 
normal?

I guess it may be difficult to analyse automatically what is 'unanswered'  
(because there could be follow-ups by submitter and other people, or 
reassigns, or whatever), but perhaps some working heuristic can be worked 
out...


pgpx16Iycirev.pgp
Description: PGP signature

Re: On maintainers not responding to bugs

2007-02-25 Thread Steinar H. Gunderson

On Sun, Feb 25, 2007 at 11:26:45PM +0300, Nikita V. Youshchenko wrote:
 What do people look on the following idea: not allow packages to migrate 
 from sid to testing if they have unanswered bug reports with severity = 
 normal?

Honestly, this would kill almost any larger package.

The problem is that way too often, maintainers don't really care about
packages migrating to testing. If they did, we wouldn't have 398 RC bugs on
packages that are not in testing...

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Looking for a temporary account on Alpha

2007-02-25 Thread Frank B. Brokken

Dear Steve Langasek, you wrote:

The intention here is to use size_t in situations where the value is known
to be non-negative.

I don't see any reason why you should use size_t for that instead of
unsigned int. size_t is intended for use in describing the size of objects
in memory, not just for anything you know should be non-negative.

Hm, well, your observation is interesting, but I'm not convinced:

https://www.securecoding.cert.org/confluence/display/seccode/INT01-A.+Use+size_t+for+all+integer+values+representing+the+size+of+an+object

From this:

Any variable that is used to represent the size of an object including,
but not limited to, integer values used as sizes, indices, loop counters,
and lengths should be declared as size_t

One could start a word game here and point out that it doesn't explicitly
state that size_t should be used for non-negative values, but the above
sentence does explicitly mention `not limited to'. Since the examples given
are definitely not limited to `sizes of objects in memory', but rather have
non-negativeness in common, I still consider my position to be correct.

Another interesting one:

Rationale for International Standard?Programming Languages?C
Revision 5.10. April 2003.:

From that (quotes by me):

6.5.3.4 ... The type of sizeof, whatever it is, is published (in the
library header stddef.h) as size_t, since
`it is useful for the programmer to be able to refer to this type.'
This requirement implicitly
`restricts size_t to be a synonym for an existing unsigned integer
type.'
... Thus size_t is also a
`convenient type for array sizes',
and is so used in several library functions.

So, it's considered a `convenient type' for array sizes; which doesn't state
that it is restricted to that. It does, however, explicitly state that it's a
synonym of an unsigned integer type.

Finally, I have this one, providing the `philosophical rationale' for using
size_t (at least to me it does):

http://www.cprogramming.com/tutorial/typedef.html

Typedefs and Abstraction

Typedefs provide a level of abstraction away from the actual types being
used, allowing you, the programmer, to focus more on the concept of just
what a variable should mean. This makes it easier to write clean code,
but
it also makes it far easier to modify your code. For instance, if if you
decided you really needed to support sizes that were too big to store in
an unsigned int, you could make a change in one place in your code--the
typedef itself--to make size_t equivalent to, for instance, an unsigned
long. Almost none of your code would need to change!

But in the end I'm confronted with an error in my program, which I now feel I
can solve thanks to the observation that a size_t * can't always be considered
an unsigned int *.

The subtlety is, I think, that although the above revision 5.10 states that
size_t is synonym to an unsigned integer type, it doesn't state that it's a
synonym of an `unsigned int'. Could very wel be an `unsigned long int'. Thus I
stumbled over a big endian :-)

Thanks for the discussion!

--
Frank B. Brokken
Computing Center, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl:11371/
Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D B19F DAC4 BE50 38C6 6170

85 matches

Mail list logo