> Some users have suggested we use donation money to get a new computer
> for one of the developers - while I would not object to a shiny new
> computer, I am unsure if this would justify the use of our donations.
If you have a modern system already. You may only actually need a new
motherboard or
On Fri, 7 Dec 2012 12:41:56 -0600
Leonid Isaev wrote:
> > Is this behavior normal or a bug?
>
> I think it is normal.
This discussion may shed some light on the bad reasoning likely behind
what you are experiencing as ipv6 overscoped on the back of one
necessity.
http://marc.info/?l=openbsd-
On Fri, 23 Nov 2012 13:12:57 -0600
Leonid Isaev wrote:
> In any case, even with noexec and fmask=0177, calling
> "bash /media//
On Thu, 22 Nov 2012 21:52:30 +
Fons Adriaensen wrote:
> > The need to constantly review the source to work out exactly what
> > polkit allows is my primary reason to disable it.
>
> What is your way to disable it once and for all ?
Well I wouldn't say once and for all. In a link from a th
On Thu, 22 Nov 2012 17:00:20 +
Paul Marwick wrote:
> - I want to be
> able to modify things like execute permissions on mounted devices
> when I need to. I'm not all that partial to being effectively told I
> can't do that - reminds me much too much of Windows.
The need to constantly review
> There are very good reasons for this change (mainly security),
I think it had very little to do with security, unless you count
device type privacy information from folder names. I use /media/usb? and
they are accessible only by root and whichever user mounted it,
logically findable by order of
> Problem is that it's too quiet now and even suppressing the possible
> error messages. So I don't think this (kernel boot parameter quiet) is
> the right answer to my problem.
Is there no way to redirect the output to a seperate terminal. It took
some rather longer commands than I'd like and sym
On Tue, 20 Nov 2012 00:54:31 +0100
Tom Gundersen wrote:
> Having read through their discussions, it seems that the main two
> things they would like to change is to be able to build udev without
> building systemd (this does of course not change the resulting code,
> but saves time if you have to
On Mon, 5 Nov 2012 13:40:21 +0100
Tom Gundersen wrote:
> Notice that consolekit is no longer supported, and should be removed.
> To get the equivalent functionality you should just boot with systemd.
Or use udevil/spacefm
I use custom udev rules and a script
Forgot a change Tom requested, please reject previous if not too late!
> I'm sure I will
> have to switch to systemd on all my systems eventually, but I don't
> give up that easily ;-)
For those looking for many of the plusses of Arch, you may want to
check out Sabayon. The forums say there are
> So far, I have not heard any mention of this being a bad idea, or a
> security concern.
I much prefer the output of ls but the acl man page says that the acls
update the filesystem permissions and vice versa, so I would expect that
if the getfacl command shows rw for the users you have in the vi
On Sun, 21 Oct 2012 22:32:07 +0200
Thomas Bächler wrote:
> Out of curiosity, what is the motivation for this change?
I wonder too, if you have some server side PHP or cgi, then enforcement
is far better via a persistent redirect, MITM is not prevented in either
case.
From experience of a friend
> Use cheap vps with static ip, it will be much easier. I doubt anyone
> keeps their mail server in home with dynamic ip.
Why should you doubt that, I've read many a blog where that is the case.
A few also block any dsl ip even though there are far better ways of
detecting spamming viruses which
> Aye, but I have the following concerns regarding hosting the server myself:
> - Only have one server - no redundancy or reliability
> - No source of income -> no possibility of VPS AFAIK
> - DKIM, PTR, SPF, rDNS all require money and static IP (more money)
>
Easydns is cheap for spf but charges
> I wondered if anyone has seen any
> problems running this kernel as a direct result of this new feature?
The author ran it for years with almost no problems so it has been
deemed easier to find problems by enabling it generally. If you want to
help, keep it on. If you just need to do your job et
> In particular there's no place for polkit
> or anything similar here.
>
> I'd want things to be configured that way 'once and for all', meaning that
> a) I'm not really looking forward to having to do this for each and every
> device or command, and b) that a routine system update (a frequent en
> However, I try to get rid of the NVIDIA card. I will remove it and check
> if Linux nowadays is able to enable 3D support for the on-board ATI
> Radeon X1250-based graphics.
Just thought I'd give a heads up that a major overhaul of nouveau
apparently including knowledge gained from the last few
> It takes two to tango. Perhaps you need a reminder of the fair and
> balanced critique Heiko initially offered, based on a package in
> [testing], that has not made it to [core]:
>
> https://mailman.archlinux.org/pipermail/arch-general/2012-September/031151.html
Double standards, considering wh
> However, no one
> expected bugs never to happen in testing. It happens in all software,
> from the kernel up.
That's true however pid1 was designed to minimise this, systemd seems
the opposite with no regard to this. Most OS's install multiple kernels
to fall back on, I guess the same is now tr
> ... but i think we all agree openssl is worth keeping around, yes?
> such exceedingly high standards of "quality" and "stability" are
> simply unrealistic.
>
That all depends on your time to implement new functionality
requirements.
> systemd works pretty awesome for everything i've thrown at i
> > On 22 September 2012 16:20, Heiko Baums wrote:
> > > And, btw., instead of threatening and banning people with different
> > > opinions you rather should take their criticisms serious and take
> > > them as an incentive to improve Arch Linux and to make it better
> > > instead of worse.
> >
> And now you have them. Did you have even one totally unbootable system
> with sysvinit and initscripts? I doubt that.
That's true, you could almost always use init=/bin/ksh|/bin/zsh etc. and
have a largely usable system, more so than the in-built busybox but as
the reason is unclear at the momen
> On Fri, Sep 21, 2012 at 2:27 PM, Kevin Chadwick wrote:
> > I read not too long ago that one of the major distros is switching to
> > PAE by default but I forget which distro, maybe Ubuntu.
> >
> > Has arch considered PAE by default.
>
> It has been discussed
I read not too long ago that one of the major distros is switching to
PAE by default but I forget which distro, maybe Ubuntu.
Has arch considered PAE by default.
--
___
'Write programs that do one thing and do it well. Write p
> I never heard that anybody solved this issue, but I read that many
> people have this issue too.
>
> On my computer there are only 3 GB + 768 MB of 4 MB available. The
> graphics has got it's own framebuffer, 256 MB, but IIRC I once have seen
> that the framebuffer is 512 MB. I guess I can see i
> What's a good size number for a /boot partition? Needs to be large
> enough kernel updates don't break the computer if possible or a
> reasonable estimate to that end.
50 Meg per kernel should future proof, though I hope default kernels
never get that large.
--
_
> I can delete the recovery partition, as I've got the "recovery" (AKA
> factory reset) disks from HP under warranty.
Personally if you have a large enough separate drive and enough
patience. I would do a bit level copy which if successful is guaranteed
to put the disk back exactly.
#/bin/dd bs=
> I have had too many problems with those stupid crappy designed sata
> data cables , i have never seen such a pile of puke as the SATA
> connection design and whoever designed and ratified needs to be hung
> drawn and slaughtered.
The same is true of almost all cables with more than a few wires a
> all disc ID's are correct so what has been screwed up this was perfect
> until the update or am i going to be forced to re-install not an
> option i look forward to
A workaround rather than a fix but may help investigate or fix the odd
machine. Have you tried switching out the
UUID=a143910
> Do others have any thoughts on this matter?
Rather than null, why not just send to an empty tty which a user can
optionally switch to.
--
___
'Write programs that do one thing and do it well. Write programs to work
together.
> ...which can used with text web browser or as installed package, with
> one of these packages below:
>
> community/arch-wiki-docs 20120619-1
> Documentation from wiki.archlinux.org
> community/arch-wiki-lite 20120619-1
> The wiki without html. 1/9 as big, easily searched and viewable on
> > Because you you have Check space enabled in pacman.conf
> As well, I would suggest adding x-systemd.device-timeout to your
> fstab, so it doesn't hang forever.
What's the reason for the default being hang forever?
--
___
> > >
> > > i highly doubt you, Lennart, or anyone else for that matter has any
> > > real numbers to support anything being said, so please, spare me.
> > >
> >
> > That would be obvious to anyone with any experience. Show me data that
> > says sshd is used more often behind firewalls. Of cou
> On Sat, Sep 1, 2012 at 8:46 AM, Kevin Chadwick wrote:
> >> On Aug 31, 2012 7:47 PM, "Kevin Chadwick" wrote:
> >> >
> >> > > > I will give one example. Lennart says come on who connects to sshd
> >> more
> >> &g
> On Aug 31, 2012 7:47 PM, "Kevin Chadwick" wrote:
> >
> > > > I will give one example. Lennart says come on who connects to sshd
> more
> > > > than once a month. I can't believe he's never seen a sshd log with
> > > > consta
> > > People are grumbling about this compatibility layer, and I might
> > > change/remove it at some point. The reason I still have not ripped it
> > > out is that I like the fact that your system will "just work" as
> > > before if you add init=/bin/systemd to the kernel command line.
> > > Witho
> > I will give one example. Lennart says come on who connects to sshd more
> > than once a month. I can't believe he's never seen a sshd log with
> > constant pass attempts even though passwords are disabled.
>
> You are misunderstanding the sshd example.
How? Systemds method would seem more p
> > On Fri, 2012-08-31 at 13:51 +0200, Damjan Georgievski wrote:
> > > And this is yet another example how initscripts are broken.
> > > I had a friend whose GDM was not coming up because it
> > > was starting too fast after dbus. As a last resort we rearranged
> > > the DAEMONS and moved gdm as
> People are grumbling about this compatibility layer, and I might
> change/remove it at some point. The reason I still have not ripped it
> out is that I like the fact that your system will "just work" as
> before if you add init=/bin/systemd to the kernel command line.
> Without the compatibility
> It is disrespectful not to honor that initscripts is something
> good, even if there should be something better now.
Don't listen, it isn't better, shell is awesome and so are init
scripts though a top notch consensus would be good. I can point out
multiple errors and wrong assumptions in just t
> > IIUC the OP got issues regarding to networkmanager, while not switching
> > to systemd.
>
> For the people not reading the forums: it seems the problem was with
> the order of daemons in rc.conf, and should be unrelated to systemd.
> For people not using systemd, this change should really no
> > Cmnd_Alias EDITS
> > = /usr/bin/vim, /usr/bin/nano, /usr/bin/cat, /usr/bin/vi Cmnd_Alias
> > ARCHLINUX = /usr/sbin/gparted, /usr/bin/pacman, /usr/bin/pacman-color
> >
> > root ALL = (ALL) ALL
> > USER_NAME ALL = (ALL) ALL, NOPASSWD: WHEELER, NOPASSWD: PROCESSES,
> > NOPASSWD: ARCHLINUX, NOPASS
Cmnd_Alias EDITS
= /usr/bin/vim, /usr/bin/nano, /usr/bin/cat, /usr/bin/vi Cmnd_Alias
ARCHLINUX = /usr/sbin/gparted, /usr/bin/pacman, /usr/bin/pacman-color
root ALL = (ALL) ALL
USER_NAME ALL = (ALL) ALL, NOPASSWD: WHEELER, NOPASSWD: PROCESSES,
NOPASSWD: ARCHLINUX, NOPASSWD: EDITS
The arch wiki
> > Would we have DNSCurve without DNSSEC, will DNSSEC actually ever get
> > fixed having got it out sooner to do so or would it have died and not
> > been replaced. Would we have DNSSEC with ECC already, solving a large
> > chunk of the issues. Perhaps pertinent questions for Linux init?
>
> Ye
> You don't need sudo or su to sign a package with your own key, just
> import your own (public) key into the pacman keyring as normal and
> trust it.
I know
The makepkg -i uses sudo or su if missing
You'll need root to import the key once.
Sudo can enforce signed packages are required.
--
__
> The 2:nd will prompt for your password when it installs the package.
Aah, uses sudo and then su. I was wondering how pacman would gain the
permissions.
# check for sudo if we will need it during makepkg execution
if (( ! ( ASROOT || INFAKEROOT ) && ( DEP_BIN || RMDEPS ||
> On Wed, 2012-08-29 at 15:02 +0200, Joakim Hernberg wrote:
> > On Wed, 29 Aug 2012 12:52:22 +0100
> > Kevin Chadwick wrote:
> > > Don't you need to sign it too? I would
> >
> > ?
>
> Signing a package you build for yourself, knowing that it&
> On Wed, 29 Aug 2012 12:39:49 +0200
> Joakim Hernberg wrote:
>
> > Or just sudo makepkg -cfi
>
> Oh dear, where is my brain today...
>
> $ makepkg -cfi
>
> is the correct way of doing it...
>
> ---
>
>Joakim
Why's that correct?
Don't you need to sign it too? I would
--
_
> I send the PKGBUILD and the package with a second mail. For good reasons
> only the PKGBUILD came through the list. I could send the package
> off-line, but it's more secure to build it yourself using the PKGBUILD.
> Inside of the directory where the PKGBUILD is run
> makepkg
> then as root run
>
> My friends at Red Hat inform me there is little marked improvement with
> SystemD however "It would be jolly nice if we was all the same." so I'm
> slightly mystified at the vehement determination to adopt it?
It would be very nice but in fact whilst unifying some it's current over
spec'd desi
> > Of course the Big Bang theory is morphing with one option being many
> > Big Bang's and that it was a point in history and not the beginning
> > which is perfectly plausible and systemd may morph sufficiently for
> > more users too, in time. I care little though (except any consequences)
> > an
> I'm pretty sure at least Ubuntu will keep patches to make some of such
> apps work without systemd. I can maintain these in community if that
> time comes. But I can care about KDE only, making GNOME work without
> systemd would be a too difficult (I don't use it and they are much
> more likely t
> at some point other packages are
> likely to depend on you booting with systemd (NetworkManager, polkit,
> Gnome, etc.).
Do you mean the packages compiled for Arch with systemd enabled
options like firefoxes with dbus? I don't see these packages removing
more than half their userbase and I don't
> But who knows, I can imagine
> that there are so many old time linux users that would hate installing
> something like systemd even if they use kde as DE. With a bit of luck
> someone willl step up and maintain an alternative to consolekit/polkit
> that doesn't require systemd.
In most cases t
> The cumulated amount of time spent on these endless discussions has
> now almost certainly get past the amount of time necessary to fix
> initscripts.
>
> Fix them instead of feeding trolls.
Except there will be more fallout from systemd's wide adoption than our
own selfish needs but as that is
> Every piece of complex software has bugs; those bugs
> won't be found if the software isn't tested, and since you're not willing
> to participate in that process you've no right to harass those who have.
Not everyone wants complex software, just about any other init
system let's you decide that.
> > So which components (obviously used by the majority of Arch users) do
> > currently have or will soon have hardcoded! dependencies to systemd?
>
> udev.
>
> Upstream, Gnome has considered it.
You know why, because according to heise some of their longterm devs
have left leaving more than h
> Suppose for some reason the majority of scientists believe in the
> theory of the Big Bang. And then I come along and wonder... where is
> the evidence? Well, if the Big Bang theory has merits, there would be
> tons of evidence, and any decent scientist that believes in this
> theory would gladly
> >
> http://osvdb.org/search?search%5Bvuln_title%5D=systemd&search%5Btext_type%5D=alltext
> >
> > Two local root exploits this year. So if your browser has a bug, systemd
> > would have allowed priveledge escalation
>
> Notice that these bugs were in logind (the console kit replacement) and n
> Despite that, no serious (IMHO) bugs or architectural issues have been
> found (there has of course been plenty of irrelevant complaints, but
> those I ignore).
http://osvdb.org/search?search%5Bvuln_title%5D=systemd&search%5Btext_type%5D=alltext
Two local root exploits this year. So if your br
> > I tried to keep my mouth shut but can't resist to reply here because I
> > simply don't understand how you think the world works. Do you want to see
> > proof that every piece of open-source software is ready to be used? That's
> > ridiculous. Open-source software is being developed. People
> trying to be corporate software.
I've been wondering what the best term for 'corporate' or 'enterprise'
software like exchange is where they change your nappies for you but
also offer you razor wire to hang yourself with by giving you IE to
browse the web on the mail server itself and encouragin
> > I do this all the time with buildroot; udev is a choice, and I often
> > have trouble compiling it because it depends on so many things, like
> > specific kernel configurations, and certain toolchain options. The
> > fact of the matter is that udev doesn't do much for me,
> > CONFIG_DEVTMPFS=y
> OK, thanks both. I don't really have time to look into it properly, but now
> I
> know it's definitely something to do with my setup. I'll just let this one
> go
> for now.
I have a fedora system which I use for a task but I installed fedora on
awhile ago just to find out about systemd and
> Kevin, you seem to be fairly advanced user. How about creating a vm with
> Arch and getting an alternative to udev running?
Seems is probably the right word. We are all fools fiddling in the dark
to some degree with different ground covered. Some of us have more
powerful torches and some keep to
> > "We", is me and the people that don't like the systemd+udev beast, and
> > they are a lot.
>
> Huh? I've never seen any complaints about udev before you. Mind you,
> udev is around since 2003.
Actually it's completely different to back in 2003 because of huge
amounts of complaints. Check
> >
> > Please, refrain from just flaming. If you want help, ask for it.
> > Otherwise, just shut up.
> >
> +1
-1
If anyone started the flaming it was those ignoring his main arguments
and pointlessly responding. A recurring theme. He may have responded to
those rediculous arguments in annoyanc
>>> Remember it's not about whether or not you're allowed to use
>>> initscripts/systemd, it's about what will become the default.
>> No, maintaining both boot methods, even if upstream weren't
>> abandoning init scripts (which they are going to) would be
>> a terrible waste of time.
What upstr
> A poll is the best way to solve this
> problem.
A poll would be better done by the mailing list but I can't see anyone
counting and verifying (even then newly seen addresses can't be
verified) and many people don't really care as long as they're system
works the way they want which is why Window
> i am moving to a dorm soon and i plan on using a archlinux box as a
> router. to keep from messing with iptables every 5 seconds, i was
> wondering if there was a good, easy to setup upnp server.
Why not have two nics, one that allows incoming to any ports you may
ever want and one that doesn't
> It is a virtualbox bug.
It probably is but that is no certainty. Virtualbox is or was atleast a
good example of how a user loved and useful software can still be far
from good and safe code correctness.
The project leader of OpenBSD had a bug report and eventually found it
was virtualbox's fau
> > Lennart said systemd will only ever run on Linux and is only designed
> > for a full fledged Fedora but is useful on embedded too. However I
> > don't think he realised what level the Linux embedded world could
> > expand to.
>
> As far as I know, Archlinux does not target non-x86 embedd
> > > Not because
> > > it is good software but because the other adequate software that this
> > > community depends on is going to require it.
> >
> > Let me know so I'm aware what the software you have in mind is if it
> > hasn't been mentioned please.
> >
> > Debian and Ubuntu plus the
> If their are 1000 users, for example.
> This is a split: 100 use Arch init script, 200 use Fedora init script,
> 300 use Debian init script, 400 use Megeia init script
> This is a unify: 980 use Systemd and the same service files, 20% Arch
> users chose to stay with initscripts.
>
> You can see
> https://wiki.archlinux.org/index.php/Systemd#Arch_integration
> "Warning: /usr must be mounted and available at bootup (this is not
> particular to systemd). If your /usr is on a separate partition, you
> will need to make accommodations to mount it from the initramfs and
> unmount it from a piv
> Not because
> it is good software but because the other adequate software that this
> community depends on is going to require it.
Let me know so I'm aware what the software you have in mind is if it
hasn't been mentioned please.
Debian and Ubuntu plus the BSDs make up far more of the user
> But if it takes you where you don't want to go, it can be forked. It has
> happened before with bigger projects.
That's true but no one can do that on a whim and apparently (Redhat
Dev) the code is rediculously hard to follow and review. I believe the
ones who would do that will likely just star
> BTW, I don't want to discourage anyone from reading Lennart's blog.
How pulse is perfect for pro audio because of it's latency. I was
going to ping that to Ralf but thought his blood pressure was
already high enough ;-)
--
___
> Of course, you are free to adopt as late as possible,
We are free to adopt never just with a lower chance of any support. It
may be difficult to keep a thousand packages in check, it should not be
difficult to keep the few each person uses in check and there will
always be other distros without
> On Wednesday 15 Aug 2012 18:54:24 Kevin Chadwick wrote:
> > > Forking processes does not copy binaries.
> >
> > Pulled out of silence for the very very last time.
> >
> > It copies the parent which is much larger is what I meant. A real
> > probl
> On Wed, Aug 15, 2012 at 10:02:57PM +0200, fredbezies wrote:
> > Last threads on systemd was useless.
>
> I disagree. In the last thread, I had to really dig for outside information
> to understand both sides of the argument. My research and tinkering has lead
> me to the following valuable c
> Congratulations to the trolls on the
> effect they've had.
Except I would see some of your posts as trolling and I'm sure you
would see some of mine as trolling too.
I have tried not to but have re-iterated some things when I have felt
that blatant inaccuracies have come along and I am sorry fo
> I will do you one better I will be unsubscribing to all arch mailing
> lists and taking my leave.
I may have been annoying to some in my own hopefully non offensive
capacity but I've seen a couple of people with good arguments have them
taken apart or twisted on mute points and then pointlessly
> A few years ago, I would emphatically have agreed with you. Now,
> getting those patches to provide services that are now taken for
> granted with MTAs to play nice with each other is a serious
> undertaking. If Dan (or someone else) was actually maintaining the
> project and producing a coherent
> So, if you *already* know that there are problems, why not wait?
> What's wrong with waiting another year, and see if you don't see so
> many problems then? What's the hurry to break people's systems?
Fedora still has grub2-beta which breaks multi-boot installs (a
documented problem!). I'll just
> Forking processes does not copy binaries.
>
Pulled out of silence for the very very last time.
It copies the parent which is much larger is what I meant. A real
problem for embedded where memory fragmentation matters to the point
that Google had code written just to handle it. The smaller the
> though they may very well just keep chugging on,
> pretending all is well.
Very last post on systemd as you've said this before and I chose not to
respond.
No, they will throw a decriptive or general error and do what the script
author intended which could be sub routines, traps which could be
> Am 15.08.2012 11:21, schrieb Kevin Chadwick:
> >> I'd love to see the overall advantages and disadvantages of each of
> >> those fleshed out on a page where I can read them
> >
> > Here's one part
> >
> > A good design would make the ini
> I already found another feature in
> systemd that people always wanted for initscripts, but was too hard to
> implement,
After posting so much pointless and wrong text aside from systemd can
do some things a little quicker which we all know. Why haven't you told
us this feature which would be wo
> Have you looked at qmail lately?
What do you mean. Qmail is one of the best mailers out there. You do
need patches and in fact some huge patches bring it up to speed in one
go?
--
___
'Write programs that do one thing and do
> SO! truth is the commercial fedoras/redhats and ubuntus out there are
> all a vibrant part of this process,
True
> and they WILL supply/shoulder the
> bulk of development.
Wrong, there have been more commits from independents in the Linux tree
in the last decade atleast.
--
> If there's a developer anywhere that agrees with you, and I expect there will
> be at some point, udev will be forked, or something else will be developed to
> rival systemd. Right now, that's not even necessary.
Little need but may well be.
http://blog.stuart.shelton.me/archives/891
--
___
> I tried systemd a while ago in a brand new machine with Arch Linux and
> the boot was *much slower*
It can be slower on embedded too, the reason is suspected to be maxing
out a cheap processor. We are talking about instant on here which is
only an issue if systemd becomes a requirement which it
> > So I think Arch Linux will probably hit issues, and you think it's FUD
> > to say "hey Arch Linux, I think you might hit issues"?
> >
> You have “issues”. Your thread title, your baseless extrapolation of your own
> experience to all of Arch are classic FUD.[0]
If you look in a dictionary o
> I'd love to see the overall advantages and disadvantages of each of
> those fleshed out on a page where I can read them
Here's one part
A good design would make the init process which is always running and
everyone must run.
1./ Be a small simple binary
2./ Have no dependencies
3./ Be easy t
We should all be getting tired of this now. Please read the multiple
threads before posting things that have already been posted. Actually
don't as we will never hear from you again ;-)
Who said we are going to be forced to use systemd again. I believe the
systemd design spec also said he hopes to
> I see that linus torvalds will have competition pretty soon on who gets
> to be the overlord. Or maybe they can coexist, one in kernel land and
> the other in userspace land ;)
linus used to run binaries from his earliest days just to make sure
that they still worked and constantly iterates that
> > I've been wondering lately whether there is a good reason why even udev
> > violates the "one thing and do it well" principle set forth by the
> > co worker of the designer of C and Unix as it not only dynamically
> > creates devices like mdev does but also hotplugging like hotplugd on
> > Open
> Not that the pro audio world doesn't have its own share
> of nonsense, but it's different nonsense.
Yeah but that stuff is usually just irritating but the audiophile
example is a little funny without explanation.
--
___
'Writ
> I would be surprised if a systemd-based system requires more resources
> than a sysvinit-based one, but that is of course something one would
> have to measure for each particular use-case.
>
How about an init script that creates proc and sys, two devices via
mknod and runs one server or a shel
1 - 100 of 324 matches
Mail list logo
