es my decision might have, but I still need my /tmp in tmpfs.
A: Then you should do that. In those rare cases when defaults need to be
changed they should be changed.
That's it. Thanks for reading.
PS: should I had filled this as a bugreport?
--
Serge
--
To UNSUBSCRIBE, email to
ll applications yet.)
One more reason to move those files to /run.
--
Serge
--
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/CAOVenEpD7iBp5icT29Z=nkdhvcbgfedbaujwokyvdq7xq39...@mail.gmail.com
ary files and is not a good
place for IPC/sockets anyway.
If these ideas were already suggested and discussed before, I'm sorry,
I guess I missed them. :)
--
Serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Co
ranteed to be small. Actually I can't think of any
software, creating a lot of small-only files in /tmp.
--
Serge
--
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/caoveneqx1vlbmn4ejdfj29puj5ebjp9dhrmea7gprf8+gzd...@mail.gmail.com
t applications
> we use.
So instead of fixing the defaults you suggest everybody to drop the
programs they use (mc, firefox, mysql)? ;)
--
Serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@li
bian user to tweak
and/or rebuild the kernel? Are you serious? ;)
--
Serge
--
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/caoveneowsedle2g-uapwxpaumteh
ple,
that know what may be broken by it, but really need it, could enable it.
--
Serge
--
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/CAOVenEp+mr3yNi=4obcg2qtztfjuaj_svcus1y-7ij5mnhj...@mail.gmail.com
han it's a bad default, and it should be fixed. :)
--
Serge
--
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/caoveneqkgq7pud1xenervfxw
they must be very small.
On that machine I had 1GB of ram and about 250MB of /tmp in tmpfs. I
configured that manually more than a year ago and dropped that setting
later when realized that its mostly useless and just slows me down having
me to manually untar archives (instead of single Ente
on separate
partitions.
But that's IMHO, and that's a question for a different topic. :)
--
Serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.d
on disk works always.
Why would we select the worst of these two options?
I don't understand, do you suggest to break some applications and make
system less stable for nothing? What's a good part?
--
Serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with
e're
workarouns like TMPDIR. That's true.
What I'm saying is that most apps will work *better* with /tmp being on
real disk, system will use less RAM and be more stable, user won't have
to use any workarounds and *won't lose anything*.
Thanks for reading this HUGE message.
--
Serge
archive.bz2.gz
Description: GNU Zip compressed data
and don't watch youtube videos larger than 250MB... how can
you find that out... well... just don't watch videos longer than 20
minutes..." etc. IMHO, that's what "default" settings are about. :)
--
Serge
--
To UNSUBSCRIBE, email to debian-devel-re
s good? Does it makes something faster?
What? How many seconds faster? Does it reduces disks operations?
In what cases and how much?
If so many people tested RAMTMP and found no good reasons for it,
then maybe let's change it back to "no" by default? That's what testing
is for anyway?
op-mode-tools usually also increase
dirty_*_centisecs allowing to not write cache for minutes. So you get
all the benefits of tmpfs without its problems, like heavy swapping or
size limited by memory. :)
> I doubt most spinning disks will go to sleep in < 30 seconds
Mine spins down in 5 seconds.
a bonus it will clean on boot automatically.
--
Serge
--
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/caoveneqonrqvrzcwwrnojaefhvx2ah+_ythxj46x0wagyas...@mail.gmail.com
eat memory and slow down other running programs when
writing to disk.
--
Serge
--
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/caovenermwbuku08ahyo8f5-ejahzjct6_gy+snyjdqkq7w-...@mail.gmail.com
just natural to
use it.
And when I say, "hey, that's a bad idea", I hurt them (I'm sorry for that).
They start arguing that "it's not that bad as you say, look, not everything
is broken, many programs still work". They can't say why it's better than
us
no applications doing heavy rename() in /tmp then what
are we testing this for? Why are we moving *default* /tmp to tmpfs?
To make these useless tests faster?
Where's the real application becoming better after all?
--
Serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.o
d. It's easy
and obvious. Instead I'm trying to find why it's a good default. Is it?
Why? Is it good just because it's "not that bad"?
> I will stop replying to this thread, because I don't have much to add;
> there are pros and cons to both solutions
t suit everyone?
IMHO: this option should not break anything (and may even fix something)
so it can be enabled by default. But it MUST be possible to disable it for
those rare cases when admin intentionally left /tmp on a small partition.
--
Serge
--
To UNSUBSCRIBE, email to debian-devel-req
2012/5/28 Thomas Goirand wrote:
>> The truth is that tmpfs IS FASTER in some cases. The problem is that
>> *nobody* can notice that on *real* applications.
>
> Serge, I'm on your side of the discussion, but the above is simply
> not truth.
You mean you know some
rams and causes no worries? ;)
> I'm not sure whether that's compatible with historical use of /tmp by
> the X window system.)
I guess it's not. Because when X starts you don't know what user will log
in there.
PS: see also idea about on-demand mount of /tmp to
, sorry. Of course, I may be wrong, there can be such applications.
It's just nobody had suggested them yet.
--
Just trying to make the world better,
Serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm
for it.
> BTW, I wish there were a document summarizing all these discussions.
I'm going to write some summary. Just waiting to hear all the opinions.
--
Serge
--
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/caoveneonuk7xrezmcjr--xfqexyo_tlo1y3wrpqpf737q0w...@mail.gmail.com
other" partition, later rebuild
livecd and replace files on "meta-root" partition with a new build.
This is harder to configure, but allows you to control every disk write
happening in your system. Also this gives you a flexible "undo": if
something goes wrong with new livec
do you think about default RAMTMP=auto idea: in addition to the
RAMTMP=no and RAMTMP=yes implement RAMTMP=auto value: mounting /tmp to
tmpfs only when this increases free space in /tmp? Meaning, if you have
more than 20%VM free space in /tmp on disk, than no tmpfs mounted
(the "Idea: mount
s; goto 4
3.f. else RAMTMP == no
4. if RAMTMP == no and has_less_than_TMP_OVERFLOW_LIMIT_free_space
then RAMTMP=yes
5. if RAMTMP == yes then mount /tmp to tmpfs
Maintainer will probably write a better code.
PS: Have you thought about mount-binding /tmp to /home/tmp for
your read-only root syste
re doing a lot of I/O, tmpfs is unquestionably faster.
You're right. But who does a lot of I/O in _/tmp_?
Your tests show that if you wrote some scripts doing a lot of I/O it may
be nice to make them working on a large tmpfs mounted to i.e. /mnt/tmpfs,
but they don't explain why _/tmp_ must
as not thinking about TMPTIME. Does it mean that there's no way
we can mount /tmp to tmpfs because it breaks TMPTIME?
--
Serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Arc
ctl/vm.txt
--
Linux kernel is usually smart enough,
Serge
--
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/CAOVenEpp9XjC7dw8-kTMZwWnMOSAqbkfp6CV9JTz++XO=3t...@mail.gmail.com
re, and
> getting the changes committed upstream to actually benefit from that is
> easier than using a tmpfs, of course.
No need to. You only need to add -pipe to your *FLAGS. You don't build
software with default autotools flags (-g -O2) anyway, I guess.
--
Serge
--
To UNSU
you could get your soft faster just by specifying
your exact arch (-march=native). Also for example -fomit-frame-pointer
option for x86 can make short functions twice shorter and faster...
[1] http://wiki.debian.org/Hardening
--
Serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.o
e files* there, and become *noticeably* faster with /tmp on tmpfs?
>
> gcc, ocamlopt, mc, lintian
Which of them becomes faster with /tmp on tmpfs? Can you suggest a use
case, that I can test with /tmp on disk and on tmpfs myself and see them
becoming faster?
--
Serge
--
To UNSUBSCRIB
them
>> becoming faster?
>
> All of them. In mc use the feature to look into tar/rpm/deb files.
> And try running apt-get upgrade in parallel for extra fsync()s.
I can't reproduce the fsync() problem, see above. Can you?
(also, mc does not unpack rpm/deb to /tmp
. :)
> There are luckily other arguments too. :)
I start thinking that "if you use /tmp on tmpfs you're doing something wrong"
or rather "if you use /tmp on tmpfs you've missed a better option". :)
--
Serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@li
it will clean on boot automatically.
Q: I'm a smart man, I know what I'm doing, what apps I'm breaking and what
consequences my decision might have, but I still need my /tmp in tmpfs.
A: Then you should do that. In those rare cases when defaults need to be
changed they should be changed.
Thanks for everybody for participating in this discussion, spending
your time for doing tests, sharing your experience and ideas.
I hope I had not missed any of them.
PS: somebody also posted a summary at https://lwn.net/Articles/499410/
--
Serge
--
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/caoveneq9jykfyhw6jixmvu6hr+gtzd4dfqvppxh4fde4faa...@mail.gmail.com
et's play it safe and not default to tmpfs for wheezy
> * do it properly later
There're no real applications benefiting from /tmp on tmpfs now. Nothing
will change later. There maybe fewer failures later, but still zero benefits
to applications on the real world. Either now or later
ely. I could suggest a dozen of different solution, if only there
were a problem to solve.
Of course I could have missed some important examples about /tmp and real
applications. Sorry if I did and I would be glad if you point them out.
--
Serge
--
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/caovenepbcx9pzr8nzttfm_x_p22pj9w0g0p4rhctkyv-tr5...@mail.gmail.com
ies.
Theories can be wrong, that's why I always ask for tests and examples,
they can't be wrong. Theories are there just to explain results of the
tests. Any theory is useful only when applied to a real life. When the
theory does not match real life it replaced with another theory. Th
ith 3.2 kernel?
PS: you can check the output of `latencytop` as well.
--
Serge
--
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/caoveneqplbjlgkvlvf
larger than free RAM. I.e. if you have 1GB RAM
and 600MB tmpfs (default for 2GB swap) you'll get swap reads+writes
even with 500MB file, if your gnome+firefox took 600MB and you have
less than 500MB RAM for cache.
--
Serge
--
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/caoveneo078mwd-qr1m8cnefejyauhtbquhmkdp3ckh-4har...@mail.gmail.com
ot relevant for tmpfs)
> - to allow you to clean up when the filesystem does fill up.
You missed one more reason. When user fills the entire /tmp on disk, it
does not break system services, since root can still use those 5%. User
cannot break the system filling /tmp on disk. But he can do that if he
f
an't think of any cases where such daemon would be better
than a usual /tmp on disk. But if you need it somewhy... check swapd.
PS: I'm curious can swap-files break suspend-to-disk even for users
having a separate swap partition?
--
Serge
--
To UNSUBSCRIBE, email to debian-devel-requ
ll help you? For example if you need it to be fast, you
can forget about fuse, I can suggest you to look at aufs3 patches. Hacking
tmpfs won't be easy, unless you're good at understanding kernel/vfs code.
--
Serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debia
he problem.
There's another firefox-specific hack you can try, but I would suggest
to check a new kernel first.
--
Serge
--
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/caoveneo854tm0d6vzobdrpgejd8vfb8ufp2pxpz_ysey9an...@mail.gmail.com
people daily working with 30GB files, and
> this easily fills the / partition).
Is there anything better for them than /tmp on disk? If it's a desktop with
single disk I would suggested them a single root partition (with /tmp on it).
If it's a server with small root but large /home on RAID
to place large files. Setting TMPDIR=/home/tmp
> is a start, indeed.
Hm. But that's almost the same as mount-bind /tmp to /home/tmp. Actually
mount-bind is even better, because you don't have to explain users when
they should set TMPDIR, just say "Use default (/tmp) and don
FLAGS should be used by `gcc` and CXXFLAGS should to go to `g++`.
Is there a bug somewhere causing CPPFLAGS to be used by g++? Is that a typo
on wiki? Or am I missing something?
--
Serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe".
e build process of C and C++
> software?
Yes, unless you actually call `cpp` directly by your build scripts somewhy.
Gcc uses internal preprocessor by default.
(I just checked `strace -f g++ test.cpp` to make sure)
--
Serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.or
elf. If I'm wrong
(very probably) can you, please, correct me and point to some
documentation/standard/etc. explaining how CPPFLAGS should be used by
the build system?
Is there a standard common for all the build systems? Or some kind of
recommendation? Or it's just a coincidenc
In that case it would be
easier to patch programs, broken by tmpfs, than patch all the programs
becoming faster. But the problem is: we had not found ANY programs
becoming faster because of tmpfs and not being broken by it. :)
At least I have not seen a reproducible benchmark yet. Have you?
P
easier with no workarounds.
Then we'll be able to remove a "cmake workaround" from the wiki page:
http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake
What do you think? Should this get filled as a bugreport?
PS: Bugs must be fixed, not documented, IMO.
PPS: crosspost
nfiguring and long documentation
reading.
PS: IMHO, there's nothing bad in having several similar programs in
repository, as long as someone wants to maintain them. It gives additional
flexibility for users. I.e. if some of them die upstream or dropped by the
maintainer users would be ab
hout it (see above). :)
Yes, "it belongs to CPPFLAGS" is a good argument when you're trying to
convince someone, but it's not really an advantage, it does not make
anything better.
PS: thanks to Russ Allbery for detailed *FLAGS description, it helped me
to understand the origins.
--
Let's make packaging easier,
Serge
--
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/caoveneqqdjae9kbpm6swkthyk3yrxkjkw2rvcscqxvbub8t...@mail.gmail.com
aging a little bit easier.
And no disadvantages on the other hand. :)
If it's not fixed in dpkg, as you said, it can be worked around in
debian/rules. I'm just trying to avoid adding unnecessary workarounds
to debian packages.
--
Serge
--
To UNSUBSCRIBE, email to debian-dev
this is how it's supposed to be by Makefile design.
It's not a "hardcode". It's an option. You can always change it, just run:
make CC=anothercc
(Note: not `CC=anothercc make`) It's a (known?) makefile feature. Those
variables in the beginning of a Makefile are often
usually enough for me. Maybe someone else
will eventually write one...
PPS: writing here in case someone else with a lot of free time may
like the idea and implement it. :)
--
Serge
--
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/caovenerq_u4olj+heka3rz0xvsxrtsbbpod-_mc0k33zff+...@mail.gmail.com
O, saying things like "Linux is not about choice" and
"Debian is not about being universal" just scares maintainers
and users away from debian, and brings nothing good instead.
If people become happy fixing bugs in their own toy ports —
let them work! More happy people is good for
files, read logs and edit scripts) is on / partition.
4. Don't move anything else around — unless it fixes something,
it will just add more bugs and more problems for users.
These steps are rather easy, and make sure that at least historical
approach is fully supported.
--
Serge
eeds it, meaning,
if nobody asked for it, and it does not make anyone happy, there's
no need to spend time on it. Does openrc make anyone happy?
But if it has some advantages over existing systems, it at least deserves
the right to be chosen by those who needs those advantages.
> On
't ever interact with the init system directly, so
> there is no point in being able to have a choice
Bad argument. :) 95% of the users don't even know what Linux is (it's just
a kernel, you know) and they certainly don't interact with it directly.
But it does not mean that we
lds that information. Any tool can just query the
> kernel for information, and decide what to do with what's returned.
Not sure. Will it work for user-space configuration too? I.e. `ifdown`
may have have to stop `dhclient` and `wpa_supplicanf`. Is it possible
to detect such cases automatical
orary").
> There are several other categories of dynamic connections, including:
> 3. VPN tunnels (server end)
> 4. Connections to a VM
>
> Most likely these should not be managed by either ifupdown or NM.
Not currently, right. But if someone could extend some of them to
support thes
ure about that. It could be that on some system the stuff needed
to mount /usr was on /srv partition. And it worked because /srv was put before
/usr in /etc/fstab. In "historical approach" it works, but not in
"initramfs approach".
--
Serge
--
To UNSUBSCRIBE, email to debia
it's obvious that `openrc`
is "a good alternative to the existing init systems", since it's used by
other distributions and it works there. It may not be the best init
system ever (yet?) but it is a good alternative at least.
> A valid argument in favor of OpenRC and against systemd [...]
Hm. Why do you compare "in favor of OpenRC" and "against systemd"? You
don't think that having `openrc` in debian repo is a threat to `systemd`
in debian repo, do you?
--
Serge
--
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/CAOVenEpUzgNzCqwEGc2DjybATYfKpnkcC_qybEnn2pzVHt=+r...@mail.gmail.com
field, it's already done.
Fedora lost more than half of the user base with the Fedora 15
release (GNOME3 and systemd). They now bring GNOME2 back. [1] :)
[1] https://fedoraproject.org/wiki/Features/MATE-Desktop
--
Serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debi
F9 was a KDE4+upstart release, F15 was GNOME3+systemd).
PS: I wish Debian had a similar stats page.
It's now possible with http.debian.org.
--
Serge
<>
Would anybody please create a port for Bash Commander?
It is a traditional GNU bash shell extended with visual two-panel file browser.
Web site is here: http://bashc.sourceforge.net/
___
Regards,
Serge Vakulenko
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubs
But there is one thing to mention: development seems to be stalled for
some time now, I can't complain about bugs though.
Cheers,
Serge
Package: wnpp
Severity: wishlist
Owner: "serge guelton "
* Package name: polylib
Version : 7
Upstream Author : Vincent Loechner
* URL : http://icps.u-strasbg.fr/polylib
* License : LGPL
Programming Lang: C
Description : the polyhedral li
Quoting Marco d'Itri (m...@linux.it):
> On Jul 09, Alessio Treglia wrote:
>
> > I think that it would be valuable for our users to keep the
> > non-default init system working on Jessie for those who do neither
> > intend nor need to switch to systemd.
> I suggest less thinking and more coding th
Quoting Michael Biebl (bi...@debian.org):
> Am 25.07.2014 19:23, schrieb Steve Langasek:
> > systemd-shim 6-4 has now been uploaded to unstable with a dependency on
> > cgmanager, implementing the new post-v205 interfaces.
>
> I just installed systemd-shim 6-4 and cgmanager 0.28-1.
> Unfortunatel
Quoting Michael Biebl (bi...@debian.org):
>
> Am 25.07.2014 23:35, schrieb Serge Hallyn:
> > Quoting Michael Biebl (bi...@debian.org):
> >>
> >> The init script fails with
> >>
> >> # service cgmanager start
> >> [] Starting cgroup ma
Quoting Michael Biebl (bi...@debian.org):
> Hi Serge!
>
> Am 25.07.2014 23:35, schrieb Serge Hallyn:
> > Quoting Michael Biebl (bi...@debian.org):
> >> Am 25.07.2014 19:23, schrieb Steve Langasek:
> >>> systemd-shim 6-4 has now been uploaded to unstable
Quoting Russ Allbery (r...@debian.org):
> Cameron Norman writes:
>
> > Oh this is easy. The init script calls s-s-d and does not check the return
> > code (so always exits 0). I am just going to use set -e in the init
> > script, only a couple tweaks are needed.
>
> Please don't use set -e in in
01.07.2012 2:20 пользователь "Adam D. Barratt"
написал:
> Hi,
>
> As previously announced[1], testing is now frozen.
>
> To keep this mail short, and make our lives easier :-), further details
> about the freeze process and the type of changes which will be eligible
> for unblocking can be found
similar),
lxc-attach does that and fully works with recent kernels.
> not to speak about holding hostile
> root.
3.12 has full user namespace support which gets us about as far as we'll
ever get.
-serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subje
ream' is technically false, as it implies
that the patches as they stood were merged. But openvz developers
played a huge part in what made it upstream.
-serge
--
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/20131024165316.GB2226@ac100
ugh to verify that all the pieces we need are there. I
just haven't had the time to write it, and I need to decide whether/how
to base on / integrate with lmctfy.
[ And if anyone else wants to write this, please be my guest :) I just
want nesting as described above ]
-serge
--
To U
kernels
> (wow that's an awkward sentence)
Not to mention non-xattr-backed filesystems.
Every time I've been in a discussion like this, that ends up being
the reason not to pursue it.
-serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of &q
Quoting Andrey Rahmatullin (w...@wrar.name):
> On Wed, Feb 06, 2013 at 12:30:28PM -0600, Serge Hallyn wrote:
> > > > Do we finally have mechanisms to start processes without root but with
> > > > elevated capabilities?
> > > We also need fallback for non
this ok? Is there
a better way?
thanks,
-serge
--
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/20130314195824.GA21222@sergelap
Quoting Michael Biebl (bi...@debian.org):
> On 14.03.2013 22:15, Ansgar Burchardt wrote:
> > Hi,
> >
> > Serge Hallyn writes:
> >> qemu-system-common installs a udev rules file which sets /dev/kvm group
> >> to 'kvm'. Its postinst then adds a
Quoting Wookey (woo...@wookware.org):
> +++ Serge Hallyn [2013-03-14 14:58 -0500]:
> > Hi,
> >
>
> > To fix this the kvm group should be created during preinst before the
> > udev rules file is unpacked. This requires adding adduser to the
> > Pre-Depends
Quoting Paul Tagliamonte (paul...@debian.org):
> On Tue, Feb 11, 2014 at 03:39:49PM +0100, Florian Lohoff wrote:
> > I am telling you that by all the technical discussions which of
> > the systems is superior over the other you forget about your users.
>
> Our users shouldn't care what init system
Quoting John Paul Adrian Glaubitz (glaub...@physik.fu-berlin.de):
> On 02/11/2014 04:18 PM, Serge Hallyn wrote:
> > FWIW, disagree - I rarely set up a machine (little laptop or server or
> > container) where I don't need to do one thing or another custom at boot.
> > Thr
ut the
> >> complication of multiple separate hierarchies. How do you
> >>suggest this
> >> integration with cgroups be done?
> >>
> >i just want to put services inside cgroups, no socket activation, no
> >dbus, no dbus activation.
> >
>
>
he file does not exist,
so users will need to be told to create those files themselves.
>From there I was able to start an unprivileged lxc container, so
the basics seemed to be correct.
Thanks!
-serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of &q
Quoting Christian PERRIER (bubu...@debian.org):
> Quoting Serge Hallyn (serge.hal...@ubuntu.com):
> > Quoting Christian PERRIER (bubu...@debian.org):
> > > Quoting Christian PERRIER (bubu...@debian.org):
> > > > Hello fellow developers,
> > > >
> >
Quoting Steve Langasek (vor...@debian.org):
> On Fri, May 02, 2014 at 04:38:15AM +0000, Serge Hallyn wrote:
> > Quoting Christian PERRIER (bubu...@debian.org):
> > > Quoting Christian PERRIER (bubu...@debian.org):
> > > > Hello fellow developers,
> > > >
eal
> usage, cgroup's mount point seems case-by-case.
> If libcgroup or libvirt shows some policy, it's good for users.
>
> /cgroup// ...
I'm lazy so I always use /cgroup or actually /cg.
I do the same thing with mounting /sys/kernel/security under /security,
so maybe /sys/cgroup actually makes sense :)
-serge
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
92 matches
Mail list logo
