On 23/02/06 09:35, Thomas Dettbarn wrote:
> Hello!
>
> tl;dr: I would like to suggest adding a line about the virtues of UUID to the
> FAQ14. Something along the lines of "Remember to set up the UUID in your
> /etc/fstab afterwards." or something.
It does outline this problem here.
https://www.ope
On Sat, Jan 09, 2021 at 05:08:14PM +0100, Wolf wrote:
> Hello,
>
> I have small suggestion for improving man page for acme-client.conf.5.
> Basically just adding "comma separated" to clarify on the format of the
> list for alternative names. I had to dig into the parser.y to figure
> this out, so
Hello,
On 2021-01-09 22:20:26 +, Stuart Henderson wrote:
> On 2021-01-09, Wolf wrote:
> > I have small suggestion for improving man page for acme-client.conf.5.
> > Basically just adding "comma separated" to clarify on the format of the
> > list for alternative names. I had to dig into the pa
On 2021-01-09, Wolf wrote:
> I have small suggestion for improving man page for acme-client.conf.5.
> Basically just adding "comma separated" to clarify on the format of the
> list for alternative names. I had to dig into the parser.y to figure
> this out, so it would be nice to have it documented
On 10/29/20 3:38 PM, Nick Holland wrote:
On 2020-10-29 08:00, Harald Dunkel wrote:
Hi folks,
do you think it would be possible for the installer to show
an eye-catching warning, if "ifconfig" reports "no carrier"
for the network port to configure?
Just a suggestion, of course
Harri
Why?
Be
it possibly an inline indicator on wired on question
which interface do you want to configure em0, em1 (down),
em2down) [em0] :
but wireless interfaces will always be down before you associate with the AP...
that said if using DHCP it is pretty obvious when a link is down...
and on a static
Nick Holland wrote:
> On 2020-10-29 08:00, Harald Dunkel wrote:
> > Hi folks,
> >
> > do you think it would be possible for the installer to show
> > an eye-catching warning, if "ifconfig" reports "no carrier"
> > for the network port to configure?
> >
> > Just a suggestion, of course
> > Harri
Hi Harald,
If im not mistaken when the installer is running when you configure
dhcp on the interface
t will warn you that it is not receiving any leases. I can see your
concerns about the static ip configuration
at a guess I think the issue is there is no config on the interfaces
so they haven
On 2020-10-29 08:00, Harald Dunkel wrote:
> Hi folks,
>
> do you think it would be possible for the installer to show
> an eye-catching warning, if "ifconfig" reports "no carrier"
> for the network port to configure?
>
> Just a suggestion, of course
> Harri
Why?
What problem are you trying to so
True, but I think it’s cleaner when you’re actually calling the function to not
have to send a hashref. Small thing, of course, but I figure you write a
function once, but call it many times. I’d rather the function call be
cleaner/simpler than the function definition for that reason.
Sent from
> you can do by array
Both of them are borring once you used the signatures but they are still
experimental.
Also: if you don't mind a new dependency: Function::Paramaters is so
much convenient.
regards
marc
hi
you can do by array
sub m4
{
my ( $self,$args ) = @_;
# $args contains
# $args->{'bla'} = blub
# $args->['do'} = whatever
}
as call ( example )
$obj->m4 ({ bla => blub , do => whatever });
holger
Am 02.01.20 um 21:40 schrieb danieljb...@icloud.com:
What if you want named paramet
On 3/1/20 8:31 pm, Marc Chantreux wrote:
>> Any modern mailreader can easily tag messages as thread, so it's trivial to
>> avoid a given thread, as long as people don't fuck around with the
>> In-Reply-To info.
>
> i have to admit this isn't an argument: if most of the people don't read
> it, we s
> Any modern mailreader can easily tag messages as thread, so it's trivial to
> avoid a given thread, as long as people don't fuck around with the
> In-Reply-To info.
i have to admit this isn't an argument: if most of the people don't read
it, we should have the ability to save bandwidth by settin
> Yes well, my point is if you want to make a piece of code
> incomprehensible, I don't think there is a language that will stop you.
indeed. but i now realize the counterpart is not true because everyone
has something different in mind when it comes to readability.
last example was yesterday:
On Thu, Jan 02, 2020 at 11:52:03PM +0100, Marc Chantreux wrote:
> > You have something like 3 lines of perl to play with ;)
>
> is there a todo list somewhere ?
More or less in my head, with lots of subprojects progressing at any given
time.
- I want to retire PackageLocator and have more co
On Fri, Jan 03, 2020 at 09:43:21AM +1000, Stuart Longland wrote:
> On 3/1/20 8:50 am, Marc Chantreux wrote:
> >> Like this thread, or worse?
> > * long doesn't mean endless
> > * sharing points of view is never sterile (yours is inspired by other
> > ones, right?)
>
> I would say it's been highl
On 2/1/20 9:43 pm, Marc Chantreux wrote:
> arf ... i just tried to explain were this "linenoise" bullshit came from
> just in the answer i gave to frank
Yes well, my point is if you want to make a piece of code
incomprehensible, I don't think there is a language that will stop you.
I had a collea
On 2020-01-02 16:52, Marc Chantreux wrote:
You have something like 3 lines of perl to play with ;)
is there a todo list somewhere ?
find /usr/src -name '*.pm' | xargs grep XXX
Shows some promising results.
Edgar
regards
marc
On 2/1/20 8:48 pm, Marc Espie wrote:
>> I've seen some pretty ugly Python code too.
> Not to beat a dead horse, but most of the python configury stuff,
> including scons, is pretty shitty. Lots of really bad pseudo-OO stuf
> (hey let's use that cool feature just because we can)
Yeah, you won't g
On 3/1/20 8:50 am, Marc Chantreux wrote:
>> Like this thread, or worse?
> * long doesn't mean endless
> * sharing points of view is never sterile (yours is inspired by other
> ones, right?)
I would say it's been highly educational.
Granted, this did not get off to a good start with the "let's r
> You have something like 3 lines of perl to play with ;)
is there a todo list somewhere ?
regards
marc
On Thu, Jan 02, 2020 at 02:16:52PM -0500, Daniel Jakots wrote:
> On Thu, 2 Jan 2020 19:49:28 +0100, Marc Chantreux
> > some endless sterile debates
> Like this thread, or worse?
* long doesn't mean endless
* sharing points of view is never sterile (yours is inspired by other
ones, right?)
so
On Thu, Jan 02, 2020 at 04:10:43PM -0500, Paul Wisehart wrote:
> On Thu, Jan 02, 2020 at 09:12:42PM +0100, Marc Espie wrote:
> >
> > Here are my current guidelines for OpenBSD perl tools.
> >
>
> Can you eleborate in greater detail?
>
Not really, just go read the code and ask questions.
You h
On Thu, Jan 02, 2020 at 09:12:42PM +0100, Marc Espie wrote:
>
> Here are my current guidelines for OpenBSD perl tools.
>
Can you eleborate in greater detail?
On Thu, Jan 02, 2020 at 02:40:25PM -0600, danieljb...@icloud.com wrote:
> What if you want named parameters? (i.e. sending a hash as your
> argument)
>
> sub m4
> {
> my $self = shift;
> my %args = @_;
>
> # and then optionally
> my ($arg1, $arg2, $arg3) = @args{qw/arg1 arg2 arg3/
What if you want named parameters? (i.e. sending a hash as your
argument)
sub m4
{
my $self = shift;
my %args = @_;
# and then optionally
my ($arg1, $arg2, $arg3) = @args{qw/arg1 arg2 arg3/};
# or you can just use $args{arg1}, etc...
}
On Thu, Jan 02, 2020 at 09:12:42PM +01
On Thu, Jan 02, 2020 at 03:24:41PM -0500, Chris Bennett wrote:
> mod_perl, from reading the mailing list, looks like it will die off
> before long. Lack of developers and funding and interest given all the
> newer replacements.
Don't even think about using mod_perl these days.
Fast-cgi is the way
I don't speak Python, but from what I've read, it has some serious
encoding problems compared to Perl.
This is a real problem in today's world of multiple encodings.
Apparently the guy writing about this is pretty hated for bringing up
this serious flaw. If the problem is true, he has examples, th
On Thu, Jan 02, 2020 at 07:49:28PM +0100, Marc Chantreux wrote:
> On Thu, Jan 02, 2020 at 10:42:54AM -0600, danieljb...@icloud.com wrote:
> > I don't understand why people say that perl's flexibility is a negative.
>
> because sometimes, flexibility permit some endless sterile debates about
> the
On Thu, 2 Jan 2020 19:49:28 +0100, Marc Chantreux
wrote:
> some endless sterile debates
Like this thread, or worse?
On Thu, Jan 02, 2020 at 10:42:54AM -0600, danieljb...@icloud.com wrote:
> I don't understand why people say that perl's flexibility is a negative.
because sometimes, flexibility permit some endless sterile debates about
the coding style.
marc
> I will always lean towards idiot-proofing the code.
:))
fair enough.
regards
marc
I don't understand why people say that perl's flexibility is a negative.
Bad code is a negative. You can have bad or inconsistent code even in a
language like python that has very rigid syntax.
As long as you know perl well, you should be able to read any
well-written perl code.
To me, both of t
On January 1, 2020 2:14:03 PM GMT+02:00, Frank Beuth
wrote:
>On Wed, Jan 01, 2020 at 10:29:53AM +, e...@isdaq.com wrote:
>>> But I don't want deeper point to get missed -- which is that if eecd
>>> doesn't like the idea of regulating what the programmer can do, then
>the
>>> programmer has to
On Thu, Jan 02, 2020 at 04:22:08PM +0100, Marc Chantreux wrote:
> hello,
>
> > > my %user = qw(
> > > login mc
> > > shell /bin/zsh
> > > );
> > > print $user{login};
>
> > my %user = ( login => 'mc', shell => 'bin/zsh');
> > is way more readable in that case, I thin
hello,
> > my %user = qw(
> > login mc
> > shell /bin/zsh
> > );
> > print $user{login};
> my %user = ( login => 'mc', shell => 'bin/zsh');
> is way more readable in that case, I think,
> and it does showcase what a *smart* quoting system can do.
well ... i prefer t
On Thu, Jan 02, 2020 at 12:40:51PM +0100, Marc Chantreux wrote:
> the quoting system
>
> # qw( for a list of barewords )
> my %user = qw(
> login mc
> shell /bin/zsh
> );
> print $user{login};
I wouldn't write it that way
my %user = ( login => 'mc', shell => 'bi
> Not sure about anyone else, but comparing the Python vs Perl example you
> gave above, I would still say Python is the nicer-looking language.
i was just saying that there is no need for yield in perl. now i can
show you tons of examples to demonstrate perl code is not only
more "unixish" but ea
hello Stuart,
> Heh, I've heard Perl described as executable line noise, and for sure,
> it will let you write code like that.
arf ... i just tried to explain were this "linenoise" bullshit came from
just in the answer i gave to frank
regards
marc
On Thu, Jan 02, 2020 at 07:34:22PM +1000, Stuart Longland wrote:
> On 2/1/20 12:30 am, Marc Chantreux wrote:
> > * the python community was unfair comparing the langages (using ugly
> > perl code and nice python counterparts). instead of taking time to
> > explain all the biases, perl community
On 2/1/20 12:30 am, Marc Chantreux wrote:
> * the python community was unfair comparing the langages (using ugly
> perl code and nice python counterparts). instead of taking time to
> explain all the biases, perl community repetedly asserted that the
> authors of those article were incompeten
On 1/1/20 9:08 pm, Marc Espie wrote:
> On Tue, Dec 31, 2019 at 10:36:15PM +0100, Anders Andersson wrote:
>> Of course its age is showing in some areas but in my experience, those
>> things are actually still worked on, and have been fixed without major
>> incompatibilities (python3 anyone?).
> The
On Wed, Jan 01, 2020 at 03:30:44PM +0100, Marc Chantreux wrote:
why is this ? return is the perl yield. the only difference is that the
"exhausted" situation is on your own. so basically:
def count_from(x):
while True:
yield x
x = x + 1
naturals = count_from(0
> Did you ever look at the suite of modules from John Syracusa (DB::Rose and
> the like) ? fairly clean and nice.
I had this under my radar but no one around be wanted to test anything
else but DBIxC so i never took time to read the code or use it.
regards
marc
On Wed, Jan 01, 2020 at 04:44:48PM +0100, Marc Chantreux wrote:
> > I still thing DBIx::Class is overkill. The DB::Rose stuff was way simpler
> > and I would have preferred for it to win.
>
> Well... i liked the simplicity until i had some cases like having 2
> different DBs with the same model: p
hello,
> > what do you mean by this? prototypes are here for decades and signatures
> > are experimental and i guess it will be core in some releases.
> Stuff like
> $o->method { code }
ooohh right! this is a thing i also missed with perl (fixed in raku).
> > Template toolkit is still by far th
On Wed, Jan 01, 2020 at 03:43:38PM +0100, Marc Chantreux wrote:
> hello,
>
> > The only thing that's really missing in perl is proper thread support.
> > Don't know if that's going to happen.
>
> seems ... complicated ...
Tell me about it. The only existing thread support was so clunky it got
t
hello,
> The only thing that's really missing in perl is proper thread support.
> Don't know if that's going to happen.
just to be sure: are you aware of the MCE module?
https://metacpan.org/pod/distribution/MCE/lib/MCE.pod
regards
marc
BTW. Also tcl has coroutines since a while:
https://www.tcl.tk/man/tcl8.6/TclCmd/coroutine.htm
Rodrigo.
hello,
> Actually all the cool and useful ideas that perl6 had DID trickle down
> into perl5 a few years ago.
even if you load a lot of modules from CPAN (which i tried to do with
https://metacpan.org/pod/Sympatic), this is not even close to be true!
for example, raku has
* PEGs are objects
* m
hello,
> The only thing that's really missing in perl is proper thread support.
> Don't know if that's going to happen.
seems ... complicated ...
> I have a wish-list of things that are not that likely to happen, I would
> like to be able to use prototypes on methods, for instance.
what do you
hello,
as intro: i would like to make clear that i'm not promoting perl (my go
to langage for scripting is now raku by far) but as i was a member of the perl
community more than 20 years, i have some opinions about it.
> felt like a random hack, especially compared to ruby. The only thing I
> rea
On Wed, Jan 01, 2020 at 10:29:53AM +, e...@isdaq.com wrote:
But I don't want deeper point to get missed -- which is that if eecd
doesn't like the idea of regulating what the programmer can do, then the
programmer has to have the skills to safely write unsafe code.
no you're belying the poin
On Tue, Dec 31, 2019 at 11:56:46PM -0700, Bob Beck wrote:
> read fucking code. change fucking things. send some fucking diffs. get
> fucking yelled at. learn from your fucking mistakes. show some fucking
> passion. filter fucking misc@ and all this useless bleating into the
> toilet.
>
> none o
On Tue, Dec 31, 2019 at 09:06:38PM +0100, Christer Solskogen wrote:
> On Tue, Dec 31, 2019 at 5:50 PM Marc Espie wrote:
>
> > We did retire vax, and we no longer have any platform without dynamic
> > libraries.
> >
> >
> OT but: out of sheer curiosity, why didn't VAX support dynamic libraries?
V
On Wed, Jan 01, 2020 at 10:06:47AM +0100, Anders Andersson wrote:
> On Wed, Jan 1, 2020 at 4:51 AM Stuart Longland
> wrote:
>
> > Perl 6 will be a major change though, more disruptive than the Python2→3
> > mess was. So we may be in for some "fun" in the near future.
>
> Gotta stop this before
On Tue, Dec 31, 2019 at 10:01:50PM -0500, Steve Litt wrote:
> On Tue, 31 Dec 2019 15:57:47 -0600
> Eric Zylstra wrote:
>
> > Proposing such a huge project without the ability to do it? I may
> > have been a little disrespectful, but not the first one in the
> > thread. And my point wasn’t to be
On Tue, Dec 31, 2019 at 10:36:15PM +0100, Anders Andersson wrote:
> Of course its age is showing in some areas but in my experience, those
> things are actually still worked on, and have been fixed without major
> incompatibilities (python3 anyone?).
The only thing that's really missing in perl is
> where do I sign up for OpenBSD write-perfect-C-code programmer training
bootcamp?
here we go ladies and gents an unadulterated look at the manchild in the
wild
as he looks for something else to take responsibility for his work. after
decades of being spoonfed it's lost the ability to fend fo
On Tue, Dec 31, 2019 at 11:56:46PM -0700, Bob Beck wrote:
read fucking code. change fucking things. send some fucking diffs. get
fucking yelled at. learn from your fucking mistakes. show some fucking
passion. filter fucking misc@ and all this useless bleating into the
toilet.
none of us have
On Wed, Jan 1, 2020 at 4:51 AM Stuart Longland
wrote:
> Perl 6 will be a major change though, more disruptive than the Python2→3
> mess was. So we may be in for some "fun" in the near future.
Gotta stop this before it derails: perl 6 is not the next version of
perl 5. It's not compatible, it's
read fucking code. change fucking things. send some fucking diffs. get
fucking yelled at. learn from your fucking mistakes. show some fucking
passion. filter fucking misc@ and all this useless bleating into the
toilet.
none of us have time to spoon feed you in some “boot camp”
there are two ty
On Wed, Jan 01, 2020 at 04:00:37AM +, e...@isdaq.com wrote:
rather than the programmer being responsible for
writing unsafe
code we need to regulate what the programmer can do just like we need to
regulate what the community can say, do, see, and think.
where do I sign up for OpenBSD write
> I like where this thread is headed.
>
> To expand on this idea, maybe we should demonstrate how diversity and
> inclusiveness can work in an operating system via language choices.
> Why stop at TCL and LUA? Or even scripting languages in general. Why
> not Go, Rust, Haskell and Scala too?
>
On 1/1/20 6:06 am, Christer Solskogen wrote:
> On Tue, Dec 31, 2019 at 5:50 PM Marc Espie wrote:
>
>> We did retire vax, and we no longer have any platform without dynamic
>> libraries.
>>
>>
> OT but: out of sheer curiosity, why didn't VAX support dynamic libraries?
>
Did vax have an MMU? Tha
On 1/1/20 3:13 am, danieljb...@icloud.com wrote:
> I'm curious to know if there are any languages other than C and perl in
> use in OpenBSD base.
/bin/sh?
*ducks*
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
On 31/12/19 10:57 pm, Daniel Boyd wrote:
> As one of the few remaining people out there who considers perl to be their
> favorite language—starting to wonder if it’s just me and Larry Wall at this
> point—I’d like to say that perl should stay in base on its merits, all the
> perl-based system to
Steve Litt wrote:
> On Tue, 31 Dec 2019 15:57:47 -0600
> Eric Zylstra wrote:
>
> > Proposing such a huge project without the ability to do it? I may
> > have been a little disrespectful, but not the first one in the
> > thread. And my point wasn’t to be disrespectful, but to point out
> > tha
On Tue, 31 Dec 2019 15:57:47 -0600
Eric Zylstra wrote:
> Proposing such a huge project without the ability to do it? I may
> have been a little disrespectful, but not the first one in the
> thread. And my point wasn’t to be disrespectful, but to point out
> that most proposals unaccompanied by
We could always rewrite the entire operating system in Pascal. FreePascal and
GNU Pascal are both GPL, so we’ll need to write a new compiler as well.
Shouldn’t take too long. Who wants to go register openpascal.org?
I’ll get a diff started
program OpenBSD;
begin
{ some code here }
end.
Sent fr
I am still waiting to this diff myself.
On Tuesday, December 31, 2019, Theo de Raadt wrote:
> I guess I'm saying in these trying times it is considered disrespectful
> to dismiss completely labour-unsupported "ideas", obviously once we accept
> the Great Idea the OP will sit down and do all the
I guess I'm saying in these trying times it is considered disrespectful
to dismiss completely labour-unsupported "ideas", obviously once we accept
the Great Idea the OP will sit down and do all the required work to prove
the cast after the fact.
Eric Zylstra wrote:
> Proposing such a huge projec
Proposing such a huge project without the ability to do it? I may have been a
little disrespectful, but not the first one in the thread. And my point wasn’t
to be disrespectful, but to point out that most proposals unaccompanied by code
and that don’t solve obvious problems don’t seem to be re
Isn't it a bit disrespectful to assume someone on misc@ is going to
write such a large diff?
> Maybe the OP could just go ahead and replace all the Perl code with Lua and
> then ask for feedback from the other devs? That is the OpenBSD way, right?
> If it really is a great idea, they’d all be
Maybe the OP could just go ahead and replace all the Perl code with Lua and
then ask for feedback from the other devs? That is the OpenBSD way, right? If
it really is a great idea, they’d all be really excited. In any case, it would
kill this thread.
EZ
Sent from my iPhone
> On Dec 31, 20
On Tue, Dec 31, 2019 at 4:30 PM Marc Chantreux
wrote:
>
> On Tue, Dec 31, 2019 at 06:57:02AM -0600, Daniel Boyd wrote:
> > As one of the few remaining people out there who considers perl to be
> > their favorite language—starting to wonder if it’s just me and Larry
> > Wall at this point—I’d like
On Tue, Dec 31, 2019 at 5:50 PM Marc Espie wrote:
> We did retire vax, and we no longer have any platform without dynamic
> libraries.
>
>
OT but: out of sheer curiosity, why didn't VAX support dynamic libraries?
On 12-31 14:02, Raul Miller wrote:
> On Tue, Dec 31, 2019 at 1:32 PM wrote:
> > I'm curious to know if there are any languages other than C and perl in
> > use in OpenBSD base.
> It's pretty easy to download the sources for base, and then:
> tar zxf src.tar.gz
> find . -type f -name '*.*' | sed 's
I like where this thread is headed.
To expand on this idea, maybe we should demonstrate how diversity and
inclusiveness can work in an operating system via language choices.
Why stop at TCL and LUA? Or even scripting languages in general. Why
not Go, Rust, Haskell and Scala too?
Hear me out. W
On Tue, Dec 31, 2019 at 02:02:47PM -0500, Raul Miller wrote:
> tar zxf src.tar.gz
> find . -type f -name '*.*' | sed 's/^.*\.//' | sort | uniq -c | sort
> -n | tail -40
That was fun, I learned about the -n option :) Thanks!
wise@hup:/usr/src$ find . -type f -name '*.*' | sed 's/^.*\.//' | sort |
On Tue, Dec 31, 2019 at 1:32 PM wrote:
> I'm curious to know if there are any languages other than C and perl in
> use in OpenBSD base.
It's pretty easy to download the sources for base, and then:
tar zxf src.tar.gz
find . -type f -name '*.*' | sed 's/^.*\.//' | sort | uniq -c | sort
-n | tail -
Certainly, there are situations where perl isn't the best choice. And in
those unfortunate situations, other languages may be considered, however
begrudgingly. :)
I'm curious to know if there are any languages other than C and perl in
use in OpenBSD base.
On Tue, Dec 31, 2019 at 05:39:03PM +0100,
On Tue, 31 Dec 2019, Theo de Raadt wrote:
> Roderick wrote:
>> I am curious to know why tcl, my fovourite scripting lanuage, would
>> not be a candidate.
[...]
> Wow, it's a lot like you can't read.
It is more an academic question. I wanted to know more objective
critera than personal preferen
Raul Miller wrote:
> On Tue, Dec 31, 2019 at 11:46 AM Roderick wrote:
> > I am curious to know why tcl, my fovourite scripting lanuage, would
> > not be a candidate.
>
> If OpenLuaBSD would be a welcome fork, I don't see why OpenTCLBSD
> would be any worse.
>
> Doesn't mean anyone wants to wri
On Tue, Dec 31, 2019 at 11:46 AM Roderick wrote:
> I am curious to know why tcl, my fovourite scripting lanuage, would
> not be a candidate.
If OpenLuaBSD would be a welcome fork, I don't see why OpenTCLBSD
would be any worse.
Doesn't mean anyone wants to write it.
--
Raul
Roderick wrote:
>
>
> On Tue, 31 Dec 2019, Marc Espie wrote:
>
> > lua would definitely NOT be appropriate for that. The only half valid
> > candidate would be python.
>
> I am curious to know why tcl, my fovourite scripting lanuage, would
> not be a candidate.
>
> I suspect, tcl is being un
On Tue, Dec 31, 2019 at 10:45:34PM +1000, Stuart Longland wrote:
> On 31/12/19 3:54 pm, Marc Espie wrote:
> > Contrary to what some people might think, the tools in question won't be
> > easier to understand and manage if written in another language.
>
> I'm of the opinion that "if it ain't broken
On Tue, 31 Dec 2019, Marc Espie wrote:
> lua would definitely NOT be appropriate for that. The only half valid
> candidate would be python.
I am curious to know why tcl, my fovourite scripting lanuage, would
not be a candidate.
I suspect, tcl is being underestimated, and the decission for one
On Tue, Dec 31, 2019 at 06:57:02AM -0600, Daniel Boyd wrote:
> As one of the few remaining people out there who considers perl to be their
> favorite language—starting to wonder if it’s just me and Larry Wall at this
> point—I’d like to say that perl should stay in base on its merits, all the
>
On Tue, Dec 31, 2019 at 06:57:02AM -0600, Daniel Boyd wrote:
> As one of the few remaining people out there who considers perl to be
> their favorite language—starting to wonder if it’s just me and Larry
> Wall at this point—I’d like to say that perl should stay in base on
> its merits, all the per
Perl is my favorite language, too. Perl can be gnarly but I love it. I have
zero experience with Lua so I can’t judge it but I’d like Perl to stay in
Base.
On Tuesday, December 31, 2019, Daniel Boyd wrote:
> As one of the few remaining people out there who considers perl to be
> their favorite l
As one of the few remaining people out there who considers perl to be their
favorite language—starting to wonder if it’s just me and Larry Wall at this
point—I’d like to say that perl should stay in base on its merits, all the
perl-based system tools notwithstanding.
I decided learn perl becaus
On 31/12/19 3:54 pm, Marc Espie wrote:
> Contrary to what some people might think, the tools in question won't be
> easier to understand and manage if written in another language.
I'm of the opinion that "if it ain't broken, don't fix it". What is
"broken" about Perl that we're trying to fix with
Marc Espie wrote:
> Removing perl from base would be very painful.
>
> I don't fancy rewriting all the perl tools in something else (specifically,
> most of the ports and package infrastructure)
>
> lua would definitely NOT be appropriate for that. The only half valid
> candidate would be pytho
Removing perl from base would be very painful.
I don't fancy rewriting all the perl tools in something else (specifically,
most of the ports and package infrastructure)
lua would definitely NOT be appropriate for that. The only half valid
candidate would be python.
Contrary to what some people m
On Mon, 30 Dec 2019, Theo de Raadt wrote:
> wrote:
>
> > A smaller base afforded to by Lua will reduce the
> > attack surface and complexity of the OpenBSD project as a whole.
>
> 1) I think that is a baseless and irrelevant claim.
>
> 2) No.
It is not about the claim, he is trying to sell
writes:
> Hi,
>
> I'd like to bring up the following suggestion:
>
> Would it be desirable for the OpenBSD project to replace Perl with Lua
> in the base system? A smaller base afforded to by Lua will reduce the
> attack surface and complexity of the OpenBSD project as a whole.
>
> The source c
On 2019-12-30 18:07, ansim...@tutanota.com wrote:
Hi,
I'd like to bring up the following suggestion:
Would it be desirable for the OpenBSD project to replace Perl with Lua
in the base system? A smaller base afforded to by Lua will reduce the
attack surface and complexity of the OpenBSD projec
Hi Theo,
Noted.
Thanks for the consideration,
ansimita
Dec 31, 2019, 00:15 by dera...@openbsd.org:
> wrote:
>
>> A smaller base afforded to by Lua will reduce the
>> attack surface and complexity of the OpenBSD project as a whole.
>>
>
> 1) I think that is a baseless and irrelevant claim.
>
>
1 - 100 of 178 matches
Mail list logo
