Re: using perl in preinst script

[Raphael Hertzog]

On Fri, 31 Dec 2010, Carsten Hey wrote:
> * Philipp Kern [2010-12-29 05:38 +]:
> > On 2010-12-28, Carsten Hey  wrote:
> > > ...  One reason for this is that dpkg's perl scripts were rewritten
> > > in C.
> >
> > I know you phrased it differently but wasn't the motivation for this
> > rewrite to be more robust in the base system on upgrades?  I.e. do not
> > rely on Perl and thus avoid adding more contraints on how the base
> > upgrade must be performed to keep dpkg working properly.
> 
> I don't know what the main motivation was, although making upgrades more
> robust seems to be a possible and a good one.
> 
> http://wiki.debian.org/Teams/Dpkg/RoadMap says:
> | Make dpkg.deb contain only sh and C programs (to help embedded
> | distros, to make it possible to remove perl-base from essential)

Both points were important for me. I have dealt with the RC bug related
to perl scripts failing in various preinst during an upgrade of
perl-base/liblocale-gettext-perl and it was really annoying (i.e. we only
had crude work-around and no proper solution). And I also maintain
customer specific embedded systems where I am using udpkg to have some
basic packaging system, I was avoiding dpkg due to the perl dependency.

Dropping perl-base from essential on Debian proper is not a goal, but
making it barely possible for some embedded derivatives is certainly
interesting for us.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101231081950.gd3...@rivendell.home.ouaza.com

Re: Safe File Update (atomic)

[Olaf van der Spek]

On Fri, Dec 31, 2010 at 3:17 AM, Henrique de Moraes Holschuh
 wrote:
> On Thu, 30 Dec 2010, Henrique de Moraes Holschuh wrote:
>> BTW: safely removing a file is also tricky.  AFAIK, one must open it RW,
>> in exclusive mode. stat it by fd and check whether it is what one
>> expects (regular file, ownership).  unlink it by fd.  close the fd.
>
> Eh, as it was pointed to me by private mail, this is obviously a load of
> crap :p  There is no unlink by fd.  Sorry about that.
>
> The attacks here are races by messing with intermediate path components,
> which are either not worth bothering with, or have to be avoided in a
> much more convoluted manner.

Ah, hehe. BTW, care to respond to the mail I send to you?


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinnyxtf2czhkfrmkw_gpp39h5uqu2j8oz1cs...@mail.gmail.com

Re: Bitcoin donation

[Josselin Mouette]

Le jeudi 30 décembre 2010 à 23:01 +0100, Petter Reinholdtsen a écrit : 
> But it might be interesting to support the bitcoin system by accepting
> donations, and give users of bitcoin more to spend their bitcoins
> on. :)

I don’t think it is a good idea to promote and support a system that is
designed from the start to make tax evasion and money laundering easier.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling


signature.asc
Description: This is a digitally signed message part

Re: Safe File Update (atomic)

[Henrique de Moraes Holschuh]

On Fri, 31 Dec 2010, Olaf van der Spek wrote:
> Ah, hehe. BTW, care to respond to the mail I send to you?

There is nothing more I can add to this thread.  You want O_ATOMIC.  It
cannot be implemented for all use cases of the POSIX API, so it will not
be implemented by the kernel.  That's all there is to it, AFAIK.

You could ask for a new (non-POSIX?) API that does not ask of a
POSIX-like filesystem something it cannot provide (i.e. don't ask for
something that requires inode->path reverse mappings).  You could ask
for syscalls to copy inodes, etc.  You could ask for whatever is needed
to do a (open+write+close) that is atomic if the target already exists.
Maybe one of those has a better chance than O_ATOMIC.

It is up to you and the fs developers to find some common ground.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101231115150.gb31...@khazad-dum.debian.net

Re: Safe File Update (atomic)

[Olaf van der Spek]

On Fri, Dec 31, 2010 at 12:51 PM, Henrique de Moraes Holschuh
 wrote:
> On Fri, 31 Dec 2010, Olaf van der Spek wrote:
>> Ah, hehe. BTW, care to respond to the mail I send to you?
>
> There is nothing more I can add to this thread.  You want O_ATOMIC.  It

That's a shame. I thought I provided pretty concrete answers.

> cannot be implemented for all use cases of the POSIX API, so it will not
> be implemented by the kernel.  That's all there is to it, AFAIK.
>
> You could ask for a new (non-POSIX?) API that does not ask of a
> POSIX-like filesystem something it cannot provide (i.e. don't ask for

What's the definition of a POSIX-like FS?

> something that requires inode->path reverse mappings).  You could ask
> for syscalls to copy inodes, etc.  You could ask for whatever is needed

To me, inodes are an implementation detail that shouldn't be exposed.

> to do a (open+write+close) that is atomic if the target already exists.
> Maybe one of those has a better chance than O_ATOMIC.
>
> It is up to you and the fs developers to find some common ground.

The FS devs are happy with all the regressions of the workaround, so
they're unlikely to do anything.

Olaf


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikw9372od-eufevczv8dtxorbagslq3mc...@mail.gmail.com

Bug#608496: ITP: libkibi -- library for byte prefixes

[Benjamin Drung]

Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: libkibi
  Version : 0.1
  Upstream Author : Benjamin Drung 
* URL : https://launchpad.net/libkibi
* License : ISC
  Programming Lang: C
  Description : library for byte prefixes

This library is designed for formatting bytes. The byte prefixes are used
depending on the user preferences.
 
Three different types of byte prefixes can be selected:
* kB, MB, GB with base 1000 (base10)
* KiB, MiB, GiB with base 1024 (base2)
* KB, MB, GB with base 1024 (historic)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101231131726.11708.56346.report...@localhost6.localdomain6

Re: Safe File Update (atomic)

[Enrico Weigelt]

* Olaf van der Spek  schrieb:

> > something that requires inode->path reverse mappings).  You could ask
> > for syscalls to copy inodes, etc.  You could ask for whatever is needed
> 
> To me, inodes are an implementation detail that shouldn't be exposed.

Well, they're an fundamental concept which sometimes *IS* significant
to the applications. It's very different from systems where each
file has exactly one name (eg. DOS/Windows) or where there're just
filesnames that point to opaque stream objects that can be virtually
anything (eg. Plan9).

> > to do a (open+write+close) that is atomic if the target already exists.
> > Maybe one of those has a better chance than O_ATOMIC.
> >
> > It is up to you and the fs developers to find some common ground.
> 
> The FS devs are happy with all the regressions of the workaround, so
> they're unlikely to do anything.

Why not designing an new (overlay'ing) filesystem for that ?


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101231135711.gb10...@nibiru.local

Re: Safe File Update (atomic)

[Olaf van der Spek]

On Fri, Dec 31, 2010 at 2:57 PM, Enrico Weigelt  wrote:
>> To me, inodes are an implementation detail that shouldn't be exposed.
>
> Well, they're an fundamental concept which sometimes *IS* significant
> to the applications. It's very different from systems where each
> file has exactly one name (eg. DOS/Windows) or where there're just
> filesnames that point to opaque stream objects that can be virtually
> anything (eg. Plan9).

Sometimes, indeed. This number of times should be as low as possible.

>> > to do a (open+write+close) that is atomic if the target already exists.
>> > Maybe one of those has a better chance than O_ATOMIC.
>> >
>> > It is up to you and the fs developers to find some common ground.
>>
>> The FS devs are happy with all the regressions of the workaround, so
>> they're unlikely to do anything.
>
> Why not designing an new (overlay'ing) filesystem for that ?

Increased complexity, lower performance, little benefit.

Olaf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinq1aucfw2fkjiqwz=y2k4hoor87zbhfq8nb...@mail.gmail.com

Re: Bitcoin donation

[Ben Hutchings]

On Fri, 2010-12-31 at 11:52 +0100, Josselin Mouette wrote:
> Le jeudi 30 décembre 2010 à 23:01 +0100, Petter Reinholdtsen a écrit : 
> > But it might be interesting to support the bitcoin system by accepting
> > donations, and give users of bitcoin more to spend their bitcoins
> > on. :)
> 
> I don’t think it is a good idea to promote and support a system that is
> designed from the start to make tax evasion and money laundering easier.

Any new money transfer system can be accused of that, as the tax
authorities are basically reactive.  Bitcoin's public keys can be
anonymous, but you have to use the same key to spend the money you've
received.  The transaction history is public so it should still be
possible to trace flows of money around the system.  I doubt the
currency exchangers will be anonymising *their* records.

(Though, speaking of money laundering, this has the same 'feature' of
e-gold that transactions are non-repudiable, which will be great for
criminals with botnets if bitcoin ever becomes popular.)

However, so far it does look like an exercise in crypto wanking and not
a useful currency.  There are currently about 1.3 million issued
bitcoins (and the protocol limits the total number to only 21 million).
The market value of a bitcoin is about USD 0.3 and there are no
bitcoin-denominated bank accounts, bonds, etc., so the money supply is a
mere USD 390,000.  Further, out of the traders listed at
, I can't see any being useful to Debian.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: Safe File Update (atomic)

[Enrico Weigelt]

* Olaf van der Spek  schrieb:

> > Well, they're an fundamental concept which sometimes *IS* significant
> > to the applications. It's very different from systems where each
> > file has exactly one name (eg. DOS/Windows) or where there're just
> > filesnames that point to opaque stream objects that can be virtually
> > anything (eg. Plan9).
> 
> Sometimes, indeed. This number of times should be as low as possible.

These cases aren't that rare. Windows, for example, tends to deny
renames on open files, as they're also identified by the filename.
(yes, there're other solutions for this problem, eg. having some
internal-only inode numbering, etc).

It's important to understand, that on *nix, filenames are not representing
the files directly, but just a pointer to them (somewhat comparable
to DNS entries), where other platforms directly use the filename as
primary identification (sometimes even as primary key). This has great
implications on the semantics of the filesystem.

> > Why not designing an new (overlay'ing) filesystem for that ?
> 
> Increased complexity, lower performance, little benefit.

Why that ? Currently applications (try to) implement that all on 
their own, which needs great efforts for multiprocess synchronization.
Having that in a little fileserver eases this sychronization and
moves the complexity to a single point.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101231144455.ga29...@nibiru.local

Re: Safe File Update (atomic)

[brian m. carlson]

On Fri, Dec 31, 2010 at 03:44:56PM +0100, Enrico Weigelt wrote:
> * Olaf van der Spek  schrieb:
> 
> > > Well, they're an fundamental concept which sometimes *IS* significant
> > > to the applications. It's very different from systems where each
> > > file has exactly one name (eg. DOS/Windows) or where there're just
> > > filesnames that point to opaque stream objects that can be virtually
> > > anything (eg. Plan9).
> > 
> > Sometimes, indeed. This number of times should be as low as possible.
> 
> These cases aren't that rare. Windows, for example, tends to deny
> renames on open files, as they're also identified by the filename.
> (yes, there're other solutions for this problem, eg. having some
> internal-only inode numbering, etc).

I would like to point out that this specific issue is why Windows needs
to be rebooted so often compared to Unix systems.  This is one situation
where inodes really shine.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Safe File Update (atomic)

[Olaf van der Spek]

On Fri, Dec 31, 2010 at 3:44 PM, Enrico Weigelt  wrote:
> * Olaf van der Spek  schrieb:
>
>> > Well, they're an fundamental concept which sometimes *IS* significant
>> > to the applications. It's very different from systems where each
>> > file has exactly one name (eg. DOS/Windows) or where there're just
>> > filesnames that point to opaque stream objects that can be virtually
>> > anything (eg. Plan9).
>>
>> Sometimes, indeed. This number of times should be as low as possible.
>
> These cases aren't that rare. Windows, for example, tends to deny

I mean that apps shouldn't have to know about inodes.

> renames on open files, as they're also identified by the filename.

Not true. Renaming a running executable works just fine, for example.

> (yes, there're other solutions for this problem, eg. having some
> internal-only inode numbering, etc).
>
> It's important to understand, that on *nix, filenames are not representing
> the files directly, but just a pointer to them (somewhat comparable
> to DNS entries), where other platforms directly use the filename as
> primary identification (sometimes even as primary key). This has great
> implications on the semantics of the filesystem.
>
>> > Why not designing an new (overlay'ing) filesystem for that ?
>>
>> Increased complexity, lower performance, little benefit.
>
> Why that ? Currently applications (try to) implement that all on
> their own, which needs great efforts for multiprocess synchronization.
> Having that in a little fileserver eases this sychronization and
> moves the complexity to a single point.

I mean compared to implementing it properly in the kernel.

Olaf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimzsvy_g8+r2zooz=skb0tza86kot2qb-eh8...@mail.gmail.com

Re: Safe File Update (atomic)

[Olaf van der Spek]

On Fri, Dec 31, 2010 at 3:58 PM, brian m. carlson
 wrote:
>> These cases aren't that rare. Windows, for example, tends to deny
>> renames on open files, as they're also identified by the filename.
>> (yes, there're other solutions for this problem, eg. having some
>> internal-only inode numbering, etc).
>
> I would like to point out that this specific issue is why Windows needs
> to be rebooted so often compared to Unix systems.  This is one situation
> where inodes really shine.

I didn't say inodes are bad. I said apps shouldn't have to know about them.

Olaf


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlkti=upmdxkkfmx5ly8nfxndmobg55f3yrpuygy...@mail.gmail.com

Re: Safe File Update (atomic)

[Enrico Weigelt]

* Olaf van der Spek  schrieb:

> > renames on open files, as they're also identified by the filename.
> 
> Not true. Renaming a running executable works just fine, for example.

Well, has been quite a while since I last used Windows, but IIRC
renaming an running executable was denied.

> >> > Why not designing an new (overlay'ing) filesystem for that ?
> >>
> >> Increased complexity, lower performance, little benefit.
> >
> > Why that ? Currently applications (try to) implement that all on
> > their own, which needs great efforts for multiprocess synchronization.
> > Having that in a little fileserver eases this sychronization and
> > moves the complexity to a single point.
> 
> I mean compared to implementing it properly in the kernel.

Doing it in the kernel would be fine (maybe DLM could be used here),
but would be a nonportable solution for quite a long time ;-o


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101231160803.gc10...@nibiru.local

Marcelino, Pan y Vino, llega al 2011, ven a disfrutarla

[José Antonio Hernández]

Marcelino, Pan y Vino, ven a vivir el milagro<<1.jpg>>