Re: [gentoo-user] Quickest/easiest Gentoo install?

2020-07-07 Thread Michele Alzetta
On an old laptop I tried all the various quick graphical options of
installing a Gentoo derivative distro, with the idea that it would then be
simple to gentooize it.
I tried various distros derived from Gentoo, even quite obscure ones. This
didn't work so well.

I ended up doing a manual install following the Gentoo handbook.


Re: [OBORONA-SPAM] Re: [OBORONA-SPAM] Re: [gentoo-user] Is Gentoo dead?

2020-04-24 Thread Michele Alzetta
I mean, basically portage is just a set of functions, so a functional
programming language might just be the best way to go

Il giorno ven 24 apr 2020 alle ore 19:54 Michele Alzetta <
michele.alze...@gmail.com> ha scritto:

> ... seems like you're describing haskell ...
> ... now, portage written in haskell would be really something
>
> Il giorno ven 24 apr 2020 alle ore 14:36 Caveman Al Toraboran <
> toraboracave...@protonmail.com> ha scritto:
>
>> On Wednesday, April 22, 2020 8:32 PM, Michael Jones 
>> wrote:
>>
>> > >   No-no. C++ is a nightmare. A few people want to use it.
>> >
>> > C++ is an extremely widespread language with millions of lines of code
>> written daily world wide.
>>
>> i think that might be misleading as it seems to
>> imply that being a c++ dev is mutually exclusive
>> against being a c dev (is it? the languages agree on
>> many syntaxes/features).
>>
>> i think the right way of thinking is as follows:
>>
>> 1. identify programming features needed to code
>>a reliable pms.  i think most likely all we
>>need is [recursive] function calls and
>>if/else/loops.  the rest probably has to do
>>with algorithms (independent of the language).
>>
>> 2. pick language that has features (1) and has the
>>largest users base.  if the set of features in
>>(1) is small enough (such as ones i suggested),
>>then the c++ developers should be counted as c
>>developers (because that part is common between
>>c++ and c).
>>
>> 3. apply occam's razor.  if two languages are
>>equally satisfying points (1) and (2), then
>>choose the simplest one.  but if my thought is
>>correct (that we only need the subset of
>>features in c++ that's already in c), then c is
>>guaranteed to have a greater effective number
>>of developers in step (2).  hence, we will not
>>even need to apply occam's razor to remove c++
>>(unless points (1) and (2) result in a tie,
>>which i don't think it does in this case).
>>
>> > Lots of people want to use it. Just not people who want to write a PMS
>> compliant package manager.
>>
>> probably same kind of people that are headed to
>> blow their legs (and ours) in the process.
>>
>>
>>


Re: [OBORONA-SPAM] Re: [OBORONA-SPAM] Re: [gentoo-user] Is Gentoo dead?

2020-04-24 Thread Michele Alzetta
... seems like you're describing haskell ...
... now, portage written in haskell would be really something

Il giorno ven 24 apr 2020 alle ore 14:36 Caveman Al Toraboran <
toraboracave...@protonmail.com> ha scritto:

> On Wednesday, April 22, 2020 8:32 PM, Michael Jones 
> wrote:
>
> > >   No-no. C++ is a nightmare. A few people want to use it.
> >
> > C++ is an extremely widespread language with millions of lines of code
> written daily world wide.
>
> i think that might be misleading as it seems to
> imply that being a c++ dev is mutually exclusive
> against being a c dev (is it? the languages agree on
> many syntaxes/features).
>
> i think the right way of thinking is as follows:
>
> 1. identify programming features needed to code
>a reliable pms.  i think most likely all we
>need is [recursive] function calls and
>if/else/loops.  the rest probably has to do
>with algorithms (independent of the language).
>
> 2. pick language that has features (1) and has the
>largest users base.  if the set of features in
>(1) is small enough (such as ones i suggested),
>then the c++ developers should be counted as c
>developers (because that part is common between
>c++ and c).
>
> 3. apply occam's razor.  if two languages are
>equally satisfying points (1) and (2), then
>choose the simplest one.  but if my thought is
>correct (that we only need the subset of
>features in c++ that's already in c), then c is
>guaranteed to have a greater effective number
>of developers in step (2).  hence, we will not
>even need to apply occam's razor to remove c++
>(unless points (1) and (2) result in a tie,
>which i don't think it does in this case).
>
> > Lots of people want to use it. Just not people who want to write a PMS
> compliant package manager.
>
> probably same kind of people that are headed to
> blow their legs (and ours) in the process.
>
>
>


Re: [gentoo-user] update remote system in background

2020-04-24 Thread Michele Alzetta
Yes, but when it first came out it defaulted to killing processes. This was
on a university server, so I imagine ac stable distro. As I told you, I
know someone who was bitten hard by this.

Il ven 24 apr 2020, 14:07 Rich Freeman  ha scritto:

> On Fri, Apr 24, 2020 at 6:31 AM Neil Bothwick  wrote:
> >
> > On Fri, 24 Apr 2020 10:41:24 +0200, Michele Alzetta wrote:
> >
> > > ... I just hope the remote system isn't running systemd, if so, you
> > > have to do some additional tweaking before screen or tmux work. I know
> > > someone who was bitten hard by this. Apparently systemd by default
> > > closes all running processes of a user on logout.
> >
> > I've never seen this and I regularly update systemd computers using tmux.
>
> It is a configurable option.  I can't imagine that many distros enable
> it by default since it is likely to be shocking to anybody who
> actually knows how to use screen, and pointless for anybody who does
> not.  :)
>
> To enable it set KillUserProcesses=yes in /etc/systemd/logind.conf
>
> If you do use it there are ways to make exceptions for particular
> processes.
>
> I can certainly see how it is a useful feature to have available in
> specific contexts, but obviously most people will want to have it
> turned off.
>
> --
> Rich
>
>


Re: [gentoo-user] update remote system in background

2020-04-24 Thread Michele Alzetta
... I just hope the remote system isn't running systemd, if so, you have to
do some additional tweaking before screen or tmux work. I know someone who
was bitten hard by this. Apparently systemd by default closes all running
processes of a user on logout.

Il giorno ven 24 apr 2020 alle ore 09:47 Raffaele BELARDI <
raffaele.bela...@st.com> ha scritto:

> Hello,
>
>
>
> I am able to ssh into a remote system that I would like to update. I’d
> like to run emerge without keeping the local system connected for the whole
> duration of the update (probably several days). Is it possible to:
>
>
>
> - ssh remote_machine
>
> - emerge -uDvN world
>
> - background and detach in some way the emerge process
>
> - logout from ssh
>
> - several days later, ssh into the remote_machine, reattach the emerge and
> check the output or continue the emerge
>
>
>
> Thanks,
>
>
>
> raffaele
>
>
>
> PS I’ll do it _*after*_ openssh update.
>
>
>


Re: [gentoo-user] update remote system in background

2020-04-24 Thread Michele Alzetta
... or tmux ...

https://github.com/tmux/tmux/wiki

Il giorno ven 24 apr 2020 alle ore 09:50 Vladimir Romanov <
bluebo...@gmail.com> ha scritto:

> Yes, you can use "screen" program (Docs:
>
> https://net2.com/how-to-use-the-screen-command-on-linux-to-keep-your-remote-task-running-when-the-connection-drops/
> )
>
> пт, 24 апр. 2020 г. в 12:47, Raffaele BELARDI :
> >
> > Hello,
> >
> >
> >
> > I am able to ssh into a remote system that I would like to update. I’d
> like to run emerge without keeping the local system connected for the whole
> duration of the update (probably several days). Is it possible to:
> >
> >
> >
> > - ssh remote_machine
> >
> > - emerge -uDvN world
> >
> > - background and detach in some way the emerge process
> >
> > - logout from ssh
> >
> > - several days later, ssh into the remote_machine, reattach the emerge
> and check the output or continue the emerge
> >
> >
> >
> > Thanks,
> >
> >
> >
> > raffaele
> >
> >
> >
> > PS I’ll do it _after_ openssh update.
> >
> >
>
>


Re: [gentoo-user] Re: escape from i3lock

2019-07-12 Thread Michele Alzetta
I think it can only be started from a VT. But what's the problem? I have an
xsession going, plus tmux, plus perhaps something else going in one or more
VT
All I have to do is call vlock -a from a virtual terminal.
Now to access any terminal VT or xsession - you have to unlock this VT
first.
But I can still access my box remotely through SSH


Il Ven 12 Lug 2019, 18:01 Ian Zimmerman  ha scritto:

> On 2019-07-11 21:28, Nuno Silva wrote:
>
> > vlock -n -a
>
> Does vlock work from an XWindow session?  Or would I have to use it on
> top of whatever I do to lock the XWindow session - xscreensaver/i3lock
> etc?
>
> (I browsed to the vlock README page on github but it doesn't answer this
> question.)
>
> --
> Please don't Cc: me privately on mailing lists and Usenet,
> if you also post the followup to the list or newsgroup.
> To reply privately _only_ on Usenet and on broken lists
> which rewrite From, fetch the TXT record for no-use.mooo.com.
>
>


Re: [gentoo-user] Re: escape from i3lock

2019-07-12 Thread Michele Alzetta
I've been using

vlock -a

for years ... it works.

Il giorno ven 12 lug 2019 alle ore 03:18 Laurence Perkins <
lperk...@openeye.net> ha scritto:

>
> > So the solution is to just use "xscreensaver" by jwz. Which can be
> > configured to just blank the screen etc. as wanted by the op. See
> > also
> > the FAQ: https://www.jwz.org/xscreensaver/faq.html
> >
> > HTH,
> > -dnh
> >
>
> Except I use xscreensaver myself and it in no way prevents VT switch,
> which is what the OP was hoping to find a way to do if and only if the
> screen is locked.  Programs that grab input still don't get to block
> combos that are processed by the X server before they even get to the
> program's input queue any more than grabbing input will block the alt-
> sysrq kernel-level interrupt keys.
>
> Disabling VT switch by the X server and then setting up some other way
> to trigger a switch that will be blocked by whatever screen locking
> program the OP wishes to use is the best solution I can think of.  chvt
> would be the program to call.  Whether he wants it to be a keyboard
> shortcut handled by his DE or some other trigger method is a matter of
> taste.
>
> LMP
>


Re: [gentoo-user] OT:Choosing a filesystem

2010-04-01 Thread Michele Alzetta
I have been using reiserfs ( 3, not 4 ) for several years and have found it
to recover without any problems from dirty shutdowns, at most I've had to
use reiserfstools to fix the filesystem. I had no such luck with ext3,
although as a journalled filesystem in theory it should do the same. I have
never tried other journalled filesystems, so I can't give you my opinion.

HTH

-- 
Michele


Re: [gentoo-user] Only two people in the gentoo world is having this problem?

2010-03-10 Thread Michele Alzetta
Find out what package /usr/lib64/liblzmadec.so belongs to and re-emerge that
package.
If you have ccache activated, delete the whole cache before doing this.
If the problem is still present, at this point try
revdep-rebuild -i

HTH


Re: [gentoo-user] NIC problems after MS Windows update

2007-09-11 Thread Michele Alzetta
HI all,

I have the self-same problem with this card on a dual boot windows98 /
gentoo system.
In fact, I have TWO 8139 cards installed and the problem is present with both.
Windows actually disactivates only the one it uses, and not the other.

On another mailing list I found someone suggesting that activating the
wake on lan option in the windows network card options solves the
problem, and in fact it does.

Anyway, seems it is not only an XP update problem, it seems to be a
more general windows thing.
-- 
[EMAIL PROTECTED] mailing list