Ted Ts'o tytso at mit.edu writes:
actually. The right answer has been known for decades, and it's is
very simple; write a temp file, copy over the xattr's and ACL's if you
care (in many cases, such as an application's private state files, it
won't care, so it can skip this step --- it's only
Reinhard Tartler siretart at tauware.de writes:
Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler siretart at tauware.de
* Package name: mplayer2
Version : 2.0beta1
Upstream Author : Uoti Urpala uoti.urpala at pp1.inet.fi
* URL : http://www.mplayer2.org
Peter Samuelson peter at p12n.org writes:
Description : next generation movie player for Unix-like systems
MPlayer plays most MPEG, VOB, AVI, Ogg/OGM, VIVO, ASF/WMA/WMV,
QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA files,
supported by many native,
Henrique de Moraes Holschuh hmh at debian.org writes:
On Tue, 26 Apr 2011, Adam Borowski wrote:
Telling someone the bug is in a version I pulled from the VCS but didn't
bother noting down which version it was is not very useful.
Now you're being silly.
All you need is the proper date
Henrique de Moraes Holschuh hmh at debian.org writes:
On Tue, 26 Apr 2011, Uoti Urpala wrote:
Using date and time as a version is not current best practice. You'll still
need the upstream version part too to sort correctly relative to released
versions.
I was refering to the full commit
Henrique de Moraes Holschuh hmh at debian.org writes:
I do think you misunderstood my point in the hash issue. My point is not
that a full hash will not collide. The point is that the full hash as seen
in a tree received from the upstream DVCS should not see colisions, because
the collision
Steve Langasek vorlon at debian.org writes:
I'm sure that systemd does much better than a traditional sysvinit boot with
/bin/bash and no dependency-based booting. But then, so does Debian's
current boot system, and so does upstart; and neither of the latter two
involve grandiose claims of a
Russ Allbery rra at debian.org writes:
Uoti Urpala uoti.urpala at pp1.inet.fi writes:
Upstart is still used in Ubuntu but doesn't seem to have much future
elsewhere. There's quite a lot of interest in systemd for Debian too,
whereas I've seen few people express interest in Upstart
Steve Langasek vorlon at debian.org writes:
Tradeoff? What tradeoff?
The tradeoff of hard-coding policy into C code in exchange for faster boot.
What's actually hard-coded so hard that it would have negative effects? What do
you actually *lose* here? The systemd model prefers to avoid shell
Wouter Verhelst wouter at debian.org writes:
On Mon, Jul 18, 2011 at 11:05:56PM +, Uoti Urpala wrote:
I think the important question is whether portability to other kernels is or
should be a project's goal, and how much else you're willing to lose for
the sake of that goal.
Debian
Wouter Verhelst wouter at debian.org writes:
Debian/kFreeBSD is here to stay, it's not going away. With that as a
given,
systemd is suddenly a lot less interesting.
Once you stop taking things as a given there are a lot more opportunities
for
improvement.
kFreeBSD is hardly
Gergely Nagy algernon at balabit.hu writes:
Uoti Urpala uoti.urpala at pp1.inet.fi writes:
Whatever its features, if we have to jump through a large heap of hoops
to get it to work at all, or to make life for maintainers of daemon
packages not a complete nightmare, it's not likely
Peter Samuelson peter at p12n.org writes:
[Uoti Urpala]
IMO letting kFreeBSD block a technology like systemd (or even letting
it have a significant impact on the discussion about whether it's
desirable to introduce the technology for the main Linux case) would
only be justifiable
Wouter Verhelst wouter at debian.org writes:
kFreeBSD is hardly the only reason why systemd is a bad idea for Debian.
It's the only argument I've seen you mention. And I don't remember seeing
convincing arguments against it from anyone else in the thread either.
Pfff. You're the one
Adam D. Barratt adam at adam-barratt.org.uk writes:
On Tue, 2011-07-19 at 19:48 +, Uoti Urpala wrote:
There was a discussion about whether future Debian would be
based on kFreeBSD, and kFreeBSD failed that on its own merits, not due to any
consideration of systemd (or actually there wasn't
Wouter Verhelst wouter at debian.org writes:
Debian is the 'Universal' operating system, and many of our developers
(including myself) pride themselves on that. We port to many
architectures, we port to multiple kernels. It's one of the defining
features of Debian: you can run it /anywhere/
Adam D. Barratt adam at adam-barratt.org.uk writes:
Proof by assertion isn't an argument. If you think kfreebsd sucks then
you're entitled to that opinion, but please don't seek to frame it as
some sort of consensus direction on the part of the project because
it's obvious.
What I consider
Iustin Pop iustin at debian.org writes:
In my experience, programs written with portability in mind are much
more resilient to breakage, and thus over time they survive bit-rot much
better. Whenever I see a program that is explicitly non-portable, I tend
to discount it in favour of portable
Bernhard R. Link brlink at debian.org writes:
* Uoti Urpala uoti.urpala at pp1.inet.fi [110719 23:31]:
Wouter Verhelst wouter at debian.org writes:
Debian is the 'Universal' operating system, and many of our developers
(including myself) pride themselves on that. We port to many
brian m. carlson sandals at crustytoothpaste.net writes:
On Wed, Jul 20, 2011 at 04:36:35PM +, Uoti Urpala wrote:
I think you're committing exactly the fallacy I described in the part you
snipped. You think that excluding people who want a particular kernel is
significant when it's a big
Russell Coker russell at coker.com.au writes:
Uoti, if you spend your time patching systemd for freebsd instead of arguing
you will do more to get systemd supported.
Even assuming that Debian would fail to support systemd without such a port, I'd
rather spend my programming time working on
Bernhard R. Link brlink at debian.org writes:
* Uoti Urpala uoti.urp...@pp1.inet.fi [110720 18:37]:
Supporting things like kFreeBSD is a lot of effort to benefit few people. If
it's what a volunteer wants to work on then that is his right. But to insist
that others should work on it is wrong
Ian Jackson ijackson at chiark.greenend.org.uk writes:
Debian has a long history of trying to make it possible to use Debian
for as many purposes as we can, even when that means that the system
has to be more complicated, or even when it means Debian has to be
less perfectly suited to some
Ian Jackson ijackson at chiark.greenend.org.uk writes:
But I don't think it is a good idea to adopt a complicated workaround
(which is essentially what the cgroups approach is), to get proper
daemon supervision, when we can simply fix the root cause.
This is a bit like saying that there's no
Ian Jackson ijackson at chiark.greenend.org.uk writes:
Russ Allbery writes (Re: Minified files and source code requirement):
I'd like to poke a little bit at the assumption that these two things are
the same and that Debian necessarily uses the GPL term as our definition
of source.
I
Russ Allbery rra at debian.org writes:
But right now with configuration in /etc if you have changed *any*
configuration setting, you then get prompted for *all* configuration
changes in the package, which I think is Enrico's point. And I agree, I
kind of like that behavior. Configuration
Kurt Roeckx kurt at roeckx.be writes:
So my understanding is that you want to build libraries with -fPIE
instead of -fPIC, and that that creates a different ABI?
What affects the ABI is compiling the library in a way that does not support
copy relocations. This can be done with visibility
Kurt Roeckx kurt at roeckx.be writes:
What affects the ABI is compiling the library in a way that does not support
copy relocations. This can be done with visibility attributes or linker
It was always my understanding that protected wasn't useful,
because it's even more expensive.
Sounds
Kurt Roeckx kurt at roeckx.be writes:
On Tue, Feb 14, 2012 at 08:17:09PM +, Uoti Urpala wrote:
Kurt Roeckx kurt at roeckx.be writes:
It was always my understanding that protected wasn't useful,
because it's even more expensive.
Sounds like your understanding was wrong. Protected
Kurt Roeckx kurt at roeckx.be writes:
As far as I understand things, this is supposed to work, and might
It cannot work in the usual setup. Relocations are not supported for
the main binary even on platforms that support them for shared
libraries.
I'm pretty sure that
Steve Langasek wrote:
The meme that systemd is better than upstart because it doesn't depend on
a shell is poppycock. No one has done any benchmarking to support the claim
that /bin/sh is a bottleneck for upstart (particularly not on Debian or
This misrepresents the systemd position. Not
Roger Leigh wrote:
I certainly don't think it's fair for fairly niche platforms to hold
back Linux indefinitely. There is a high cost on maintainers to
support these platforms, and it would be an ideal situation if
systemd or upstart were sufficiently portable to run on them, even
if they
Guillem Jover wrote:
On the other kernels lack of features I'll just point to the
“Functionality Equivalence” section in the Porting Guidelines draft I've
been preparing at http://www.hadrons.org/~guillem/debian/ports/porting.
Most of the features listed as required for systemd are either
Roger Leigh wrote:
On Fri, Feb 24, 2012 at 04:20:47PM +0200, Uoti Urpala wrote:
Portability is not necessarily a positive attribute. When you're talking
about standard functionality available on all platforms, it's cleaner to
write it using standard interfaces that work everywhere
Russ Allbery wrote:
While this is true, note that the main objection to CLAs is that it limits
the potential field of contributors. One of the other things that *also*
substantially limits the field of contributors is an upstream who is
confrontational and difficult to work with. I'm not
Cyril Brulebois wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi (26/02/2012):
Is there reason to believe this would be a particular problem with
systemd? Most of the controversy I've seen surrounding Poettering has
been due to people resisting the kind of change he has championed. I
don't
On Sun, 2012-02-26 at 17:36 +0100, Goswin von Brederlow wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
I think it's quite arrogant of BSD users to expect others to work to
support their systems. The BSD userbase is small enough that most
projects have alternative things to work
Bernhard R. Link wrote:
While there might be some problems originating from some architecture,
but most problems you will see and people claim to be problems specific
to fringe architectures are actual bugs in the program you just do not
*yet* see on your usual pet architectures. And some more
Steve Langasek wrote:
If no one's measured it, then converting scripts to C programs to
avoid the added exec() calls is premature optimization. If the only
You keep repeating the same FUD. Again, avoiding shell is not just an
optimization, much less a premature one. Also, if I understand the
Goswin von Brederlow wrote:
Steve Langasek vor...@debian.org writes:
/etc/default/* files. The options here are all fairly poor:
Option 2 is also bad. There is a reason why we have /etc/default instead
of setting the options in the init.d scripts directly. Most importantly
the init.d
Steve Langasek wrote:
There are also complications to using cgroups, in that suddenly any service
that needs to be able to spawn long-running processes that outlive the
service has to start caring about cgroups - both so that they survive the
service being shut down from the outside, and so
Steve Langasek wrote:
The current state of upstart in Debian is a reflection of the upstart
maintainers' respect for Debian and desire to not destabilize the
distribution by triggering an avalanche of package conversions that could
quickly take us past the point of no return for bit rot of our
Martin Wuertele wrote:
* Uoti Urpala uoti.urp...@pp1.inet.fi [2012-03-23 19:44]:
IMO your [Steve Langasek's] upstart advocacy and anti-systemd FUD
crosses the line between having your own opinions and having your
own facts.
There was neither FUD nor advocacy in Steves mail and no hostile
Russ Allbery wrote:
Samuel Thibault sthiba...@debian.org writes:
It is apparently trying to be a *Linux* standard, being adopted by all
distributions.
That's not at all clear to me. It seems more to be trying to be a good
init system used by Fedora, and beyond that it's left to people to
Russ Allbery wrote:
Josselin Mouette j...@debian.org writes:
I’ve not seen many people interested specifically in upstart in this
discussion, apart from Canonical employees.
For the record, I'm interested specifically in upstart because I think
that alignment with Ubuntu is a major win
Russ Allbery wrote:
+pie causes a fairly ordinary regular binary (gnubg) to die with a bus
error immediately upon execution. If someone could figure out why and
whether it's a general class of problems or something peculiar to that
code, I'd be feeling more optimistic about enabling PIE more
Russ Allbery wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Russ Allbery wrote:
+pie causes a fairly ordinary regular binary (gnubg) to die with a bus
error immediately upon execution. If someone could figure out why and
whether it's a general class of problems or something
Roger Leigh wrote:
One of the definining characteristics of the Linux ecosystem, including
Debian, has been that the system has been made up of a set of loosely-
coupled compoments with well-defined interfaces. This is in stark
contrast to, e.g. Windows, MacOS and other proprietary systems,
Marco d'Itri wrote:
I am on friendly terms with many Red Hat people, but it is a fact that
they take design decisions which are aligned with the needs of RHEL
and these needs are often far from what is good for other distributions.
- configuration files in /etc/ overriding configuration
Dmitry Nezhevenko wrote:
On Mon, Apr 30, 2012 at 01:49:57AM +0300, Uoti Urpala wrote:
Marco d'Itri wrote:
- configuration files in /etc/ overriding configuration files in /lib/,
to work around the inferior configuration files handling of RPM
I'm not convinced that the traditional
Dmitry Nezhevenko wrote:
On Mon, Apr 30, 2012 at 02:44:42PM +0300, Uoti Urpala wrote:
Wrong. Any program behavior change may require changing custom
configuration, but such changes need not be accompanied by changes in
the default configuration file. Currently dpkg lacks any mechanism
George Danchev wrote:
It is entirely possible to manage configuration files from dpkg's
maintainerscripts (postinst on 'configure' stage, and resp. postrm) as
you find fit,
or by means of ucf, and possibly in combination with debconf.
One can ship a bunch of configuration files in
Tollef Fog Heen wrote:
]] Philipp Kern
You will not, however, get a conffile update prompt when the system
file changes (e.g. to update your own local copy to incorporate the
fix).
This is something I'm pondering if we should handle in either a systemd
trigger or a tool that packages
Roger Leigh wrote:
Can't we just do things the Debian way, and just provide them directly
as conffiles in /etc? It's nice that systemd provides its mechanism
to symlink/include the units provided elsewhere, but is this either
necessary or desirable on a Debian system?
Not having the files in
Gergely Nagy wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Not having the files in /etc by default does have technical advantages.
It's easier to see what is local non-default configuration. Original
default file is always available in a known location (and very easy to
revert
Steve McIntyre wrote:
Josh Triplett wrote:
Marco d'Itri wrote:
The more I think about it, the more I suspect that the correct solution
would be to just symlink /lib/udev/rules.d/ to /etc/udev/rules.d/ and so
on.
Please don't. As a user, I find it highly preferable for packages to
Steve McIntyre wrote:
Uoti Urpala wrote:
Who's the one choosing his preferred configuration format based on the
limitations of his preferred packaging system here? Hint: it's not Red
Hat.
*yawn*
When you've got something constructive to add to Debian development,
let us know. Until
George Danchev wrote:
On Thursday 10 May 2012 00:22:11 Uoti Urpala wrote:
Steve McIntyre wrote:
No, really - please *do* do this. The fact that a lot of the software
coming out of RedHat development seems to be designed solely for their
use, including working around the missing/broken
Marco d'Itri wrote:
On May 10, Bjørn Mork bj...@mork.no wrote:
Agree. Copying a large set of default policies into /etc just because
they *can* be overridden is not user friendly. And it does not make the
defaults any more configuration either. It just hides important local
changes
Don Armstrong wrote:
On Thu, 10 May 2012, Uoti Urpala wrote:
You're pretty much just saying that dpkg and helpers like ucf have
implemented better functionality than rpm. I don't see how that's
relevant to the discussion.
The reason why it is relevant is because
I don't see how
George Danchev wrote:
On Thursday 10 May 2012 19:53:18 Uoti Urpala wrote:
The reason why most old applications do not follow that approach (at
least not yet) is pretty obvious: their authors never considered it.
etc-overrides-lib semantics have only become a seriously considered
Don Armstrong wrote:
On Thu, 10 May 2012, Uoti Urpala wrote:
I don't see how the following would make this comparison with rpm
relevant.
This is debian-devel, and we're talking about configuration file
handling in Debian, which makes ucf and dpkg relevant.
Yes, ucf and dpkg are relevant
George Danchev wrote:
On Thursday 10 May 2012 21:46:41 Uoti Urpala wrote:
I don't see how the following would make this comparison with rpm relevant.
It was a comparison of the packaging system facilities to handle upgrades of
the configuration files of the applications. This was initially
Don Armstrong wrote:
On Thu, 10 May 2012, Ben Hutchings wrote:
In the etc-overrides-lib model, program defaults and local
configuration are effectively being merged every time the program
starts.
This seems to assume that the program would always read both. systemd
unit files don't work
Philip Hands wrote:
The traditional Debian approach to /etc is largely self documenting, to
the extent that one can generally walk into a site cold and (having
established that they have decent backups) cheerfully do an upgrade on
their Debian servers without anything breaking (I do this
Josselin Mouette wrote:
Files which are written on a regular filesystem stay on memory. This is
called the buffer cache. Whenever they are not used and/or the system
needs to reclaim memory, they are trashed.
Files which are written on a tmpfs stay on memory. Whenever they are not
used and/or
Serge wrote:
you eat cache memory. Meaning, you store /tmp files in cache even when
they're not used, so kernel cannot use that memory to store some useful
files. This increases I/O and makes the system slower.
The tmpfs files will be written to swap if they aren't accessed much and
the kernel
Goswin von Brederlow wrote:
Le vendredi 25 mai 2012 à 16:01 +0300, Uoti Urpala a écrit :
There is one significant difference though. When you read data back to
memory from swap, the kernel does not remember that it already exists on
disk; when the data is evicted from memory again
Steve Langasek wrote:
On Thu, May 31, 2012 at 06:15:47PM +0200, Bernd Zeimetz wrote:
Especially do I fail to understand why a member of the TC, who took part
in such discussions before
(https://lists.debian.org/debian-devel/2006/05/msg00457.html to name an
example), and encouraged people
Goswin von Brederlow wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
I haven't read the relevant kernel code, but that doesn't match the
behavior I see. Reading a large file from tmpfs and then allocating
memory results in large swap writes every time, even if the newly
allocated
that doesn't help your credibility.
Do you dismiss the theory (confirmed by Uoti Urpala test script) that
tmpfs+swap INCREASE number of writes and are hence bad for SSD?
I think what the script shows is that there can be significant problems
using tmpfs to hold large amounts of data, even if you have
Serge wrote:
2012/6/10 Uoti Urpala wrote:
You've posted blatantly false claims. If you post claims like 1+1
equals 2 because the moon is made of cheese, then you're a moron, even
if 1+1 does equal 2.
(I like this example :)) It could be, it's impossible to know everything
in the world
Guillem Jover wrote:
By definition a binNMU cannot produce a source package anyway, so I
fail to see the point in this artifical need to distinguish “source”
and “binary” changelogs through different files, AFAIR I already
Why artificial? Isn't it a completely natural and consistent view to
Wouter Verhelst wrote:
I don't think compiling C code has been CPU bound since before I was
born (and I was born in the late 70s, so that's quite a while). C++ is a
different matter, but still.
Bullshit. GCC uses a lot of CPU unless you compile without optimization,
and is surprisingly slow
Joey Hess wrote:
Hideki Yamane wrote:
I tested as well, and sometimes decompression with xz is so slw,
it takes 6-8 times than default gz.
I was just watching your DebConf presentation Lets shrink Debian
package archive and I think there you said decompression with xz was
between
brian m. carlson wrote:
On Sat, Jul 21, 2012 at 09:25:50PM +0300, Uoti Urpala wrote:
So at least in this case the biggest performance problem by far is the
inappropriate use of fsync() or other disk synchronization primitives,
and CPU use for unpacking is pretty much irrelevant.
My
Simon Paillard wrote:
On Sat, Jul 21, 2012 at 09:25:50PM +0300, Uoti Urpala wrote:
So at least in this case the biggest performance problem by far is the
inappropriate use of fsync() or other disk synchronization primitives,
and CPU use for unpacking is pretty much irrelevant.
Though
Marc Haber wrote:
Amen. I find it derogatory towards the people spending months of their
private time to make exotic ports work to call their work toy ports.
There are people who use their time doing things like hopping across a
continent on one foot. That is a lot of work, but it's not
Steve Langasek wrote:
On Thu, Oct 25, 2012 at 05:17:10PM +0800, Thomas Goirand wrote:
On 10/25/2012 02:48 AM, Steve Langasek wrote:
On Thu, Oct 25, 2012 at 01:57:12AM +0800, Thomas Goirand wrote:
I remember when I started a thread about 6 months ago,
willing to take over maintainership of
Steve Langasek wrote:
Pretty sure you have this backwards. The decision to implement upstart and
use it in Ubuntu was a technical [corrected] one. The decision to NIH a
dependency-based init system and then try to strongarm everyone into using
it by breaking compatibility was the political
Russ Allbery wrote:
John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes:
Yes, I do accept vocals against systemd, but only if these are actually
valid arguments. Because I want software development to be driven on
technical merits and not on sympathies against or for certain
Russ Allbery wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Russ Allbery wrote:
Free software is a social activity. The past history of qmail should
be informative here (or, for that matter, both gcc and glibc, which had
to go through disruptive forks to sort out long-term issues
Andrej N. Gritsenko wrote:
John Paul Adrian Glaubitz has written on Friday, 30 November, at 1:04:
Absolutely true. And this is actually why I don't understand so many
people get so emotional when it comes to software like systemd or
Pulse-Audio.
Well, without any emotions. In last 2
Russ Allbery wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Would you expect anyone who thinks such activity is not useful to help
with it? This would seem to lead to the absurd conclusion that
expressing a negative view/evaluation of anything would always be just
noise, regardless
Chow Loong Jin wrote:
On 30/11/2012 10:16, Uoti Urpala wrote:
However, current PulseAudio is still quite buggy. But I wouldn't place
Is it, really? I haven't noticed any major issues with Pulseaudio in the past
couple of years running Ubuntu. That and sound has worked out of the box
Petter Reinholdtsen wrote:
When /usr/ is a LVM partition, this block LVM from being
shut down, and leave /usr/ in a dirty state and LVM not properly shut
down before poweroff.
Why would this be harder to support than having / itself on LVM? Or are
you saying the latter need not be supported?
Russ Allbery wrote:
Adam Borowski kilob...@angband.pl writes:
There are two ways to design a system:
* a monolithic well-integrated system, granting features and efficiency at
the cost of portability and hackability
* the traditional Unix way, with a stress on replaceable tools that
Philipp Kern wrote:
On Sun, Mar 31, 2013 at 12:33:46PM -0500, Dirk Eddelbuettel wrote:
I cannot influence the R release cycle which happens within our freeze. As
have a few previous R releases, and none of those created any trouble.
Thanks for trading the R release cycle with Debian's and
Neil Williams wrote:
On Mon, 01 Apr 2013 00:48:08 +0300
Uoti Urpala uoti.urp...@pp1.inet.fi wrote:
Philipp Kern wrote:
Thanks for trading the R release cycle with Debian's and for delaying the
IMO it's important to remember that it's fundamentally the release team
that is at fault
Scott Kitterman wrote:
If I'm reading you correctly, you seem to believe that creating the release
is
somehow the release team's job. It's not. The job belongs to all of us.
No, that's not what I'm saying. But I think the release team is
primarily responsible for the policies that harm the
Samuel Thibault wrote:
Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit :
Distributions that make latest
software available are necessary for free software development.
Again, that's one of the things experimental is for.
It is not. You can't reasonably install things from
Neil McGovern wrote:
On Mon, Apr 01, 2013 at 02:38:51PM +0300, Uoti Urpala wrote:
It is unreasonable to tell the users and upstreams that Debian is
going to keep users on a known inferior version by default for a long
time, just in case more testing is needed to discover problems
Helmut Grohne wrote:
Barring any mistakes this appears like a possible solution to the
problem. Did you spot anything obviously wrong? Any example where you
don't see how to work it out?
It seems correct at first glance, but not enough to solve all the issues
mentioned. Currently existing
Helmut Grohne wrote:
On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote:
3) P runs a script using system interpreter X, and depends on the
interpreter environment supporting functionality provided by Q.
Q needs to work for the arch matching installed version of X.
P (all
Helmut Grohne wrote:
You point out a limitation that I'd consider to be a feature. My
proposal requires that every package has a single set of running
architectures that has to apply to all code contained.
Should that set of running architectures be just architecture?
I think that after
Bill Allombert wrote:
On Sat, Apr 27, 2013 at 08:55:28AM +0200, Ondřej Surý wrote:
P.S.: You still haven't answered my questions in the previous email. I
don't think they are unreasonable.
Let start with the beginning:
I became the maintainer of libjpeg62 in November 2001, the package
Josselin Mouette wrote:
Hi10p is a useless hack that makes videos unreadable with hardware
acceleration. I wouldn’t recommend using it in the general case. The
The useless hack part is false. 10-bit H264 is a clear improvement in
video compression for some types of videos. Existing hardware
Lucas Nussbaum wrote:
I went through the various init systems threads again during the last
few days. My understanding of the consensus so far is the following:
- Both systemd and upstart bring many useful features, and are a
clear improvement over sysvinit.
Yes, both are an improvement
Salvo Tomaselli wrote:
I have tried systemd, and I like the approach it has, and in a few years I
believe it has potential. But... using it to restart my computer i need to do
an hard reset (and think of how happy would I be if my computer had been a
server in a rack on the other side of
Mathieu Parent wrote:
2013/5/30 Marco d'Itri m...@linux.it:
and the invent a new a configuration files scheme because it better
suits RPM and Red Hat policies deal.
Do you have an example?
I think he's referring to the etc-overrides-lib semantics that systemd
uses for configuration files.
1 - 100 of 137 matches
Mail list logo
