[arch-general] Question about switching to 12 hour time

2020-02-13 Thread matthew dyer via arch-general
Hi all,

As an orca user, I am confused about something.  My arch machine is set to use 
local time which means that if I am using orca and quarry the time orca gives 
me the time correctly in 12 hour time but in looking at emails in thunderbird, 
the time and date are spoken in 24 hour time for example, Its about 6:33 p.m 
here in the eastern u.s which orca would speak correctly but if I  were to use 
orca I would here the message info with the date format spoken as 2020/13/02 
followed by 18:33.  Is there something in a configuration file somewhere or 
something in orca that I need to change?  Just wondering as this is confusing 
me.  BTW, my locale is set to en_US.UTF-8.  Thanks.  Will continue to do some 
digging but thought I would ask here just incase I am missing something 
obvious.  

Matthew


Re: [arch-general] Iptables

2020-02-13 Thread Karol Babioch via arch-general
Hi,

Am 11.02.20 um 16:15 schrieb NTS:
> - The ssh port is fixed as TCP port 12500.  Since 12500 >1024 this
> is a non-priviledged port which is a security risk.  Ports < 1024
> can only be opened (here: state LISTEN) by root, others by everyone.

While technically this is true, I'm not convinced that this matters in
practice in most environments.

> If a user manages to crash your sshd then they can start their own
> service at that port.

This requires local users/attackers with shell access. Not necessarily a
concern in every environment.

Best regards,
Karol Babioch



signature.asc
Description: OpenPGP digital signature


Re: [arch-general] "date" C++ library packaging

2020-02-13 Thread David C. Rankin
On 02/13/2020 02:24 AM, Morten Linderud via arch-general wrote:
> On Thu, Feb 13, 2020 at 12:09:27AM -0800, Brett Cornwall via arch-general 
> wrote:
>> Waybar [1] just had an update where it pulled in a project called "date"
>> [2]. I'm hesitant to package this under the name "date" since GNU coreutils
>> shares a binary with that name. But this isn't a totally obscure library.
>>
>> Should I persuade upstream to change the name? Should I package it under
>> another name? Or should I lay claim to the unused "date" package name and go
>> on with my life?
> 
> "chrono-date" could maybe work as an alternative name?
> 
> I'm unsure why this is in [arch-general] and not [arch-dev-public] :)
> 

And with the note that much of Howard Hinnant's date/time library is being
incorporated into the next C++ standard. Quite a feather in anyone's cap.

-- 
David C. Rankin, J.D.,P.E.



signature.asc
Description: OpenPGP digital signature


Re: [arch-general] "date" C++ library packaging

2020-02-13 Thread Morten Linderud via arch-general
On Thu, Feb 13, 2020 at 12:09:27AM -0800, Brett Cornwall via arch-general wrote:
> Waybar [1] just had an update where it pulled in a project called "date"
> [2]. I'm hesitant to package this under the name "date" since GNU coreutils
> shares a binary with that name. But this isn't a totally obscure library.
> 
> Should I persuade upstream to change the name? Should I package it under
> another name? Or should I lay claim to the unused "date" package name and go
> on with my life?

"chrono-date" could maybe work as an alternative name?

I'm unsure why this is in [arch-general] and not [arch-dev-public] :)

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature


[arch-general] "date" C++ library packaging

2020-02-13 Thread Brett Cornwall via arch-general
Waybar [1] just had an update where it pulled in a project called 
"date" [2]. I'm hesitant to package this under the name "date" since 
GNU coreutils shares a binary with that name. But this isn't a totally 
obscure library.


Should I persuade upstream to change the name? Should I package it under 
another name? Or should I lay claim to the unused "date" package name 
and go on with my life?



[1] https://www.archlinux.org/packages/community/x86_64/waybar/
[2] https://github.com/HowardHinnant/date


signature.asc
Description: PGP signature