https://www.eff.org/https-everywhere
https is getting everywhere. If you don't have ca's you cannot process them
properly.
I think https working is going to be important even for almost all embedded
cases. Most iot deployments
include something like calling the mothership, which ought to be https
On Fri, Apr 10, 2020 at 1:12 PM Russ Allbery wrote:
> Dmitry Smirnov writes:
>
> > Let's remember that Kubernetes was never in "stable" to begin with.
>
> > This is not to say that it couldn't be useful in "testing", "unstable"
> > or even "experimental". Many packages that may be considered not
doesn´t this whole discussion just mean that k8 should just not be in
Debian?
It should be a third party package, perhaps with a third party repo, and
just not be in Debian at all.
If any means of packaging for a Debian release results in a package that is
essentially unsupported by upstream... wh
Most Sarrracenia stuff is tied to AMQP, but next-gen messages are called
v03 (version 3) they use a JSON payload
for all the information, and that makes it somewhat protocol independent.
There is also a 500 line MQTT demo
that implements a file replication network, using the same JSON messages,
and
MQTT is the best thing going for interop purposes.
On Tue, Mar 24, 2020 at 1:20 PM Jeremy Stanley wrote:
> On 2020-03-24 13:09:35 -0400 (-0400), Peter Silva wrote:
> [...]
> > We could talk about the merits of various protocols (I see fedmsg
> > uses ZeroMQ) but that is a deep
hi, totally different take on this...
We could talk about the merits of various protocols (I see fedmsg uses
ZeroMQ) but that is a
deep rabbit hole... to me, fedmsg looks like it is making a ZeroMQ version
of a broker (which is a bit ironic given the original point of that
protocol) trying to buil
try ssh into a windows machine.
the termcaps are all manner of fun.
On Thu, Mar 19, 2020 at 7:23 AM Adam Borowski wrote:
> On Thu, Mar 19, 2020 at 11:34:10AM +0500, Lev Lamberov wrote:
> > Ср 18 мар 2020 @ 18:52 Adam Borowski :
> >
> > > Alas, our ed is basically:
> > > #!/bin/sh
> > > while rea
fwiw... anyone who knows vi already knows ed, it's just the line mode
commands.
you save the : and that's it.
uh... fwiw, I had a mainframe typish system I had to admin 30 years ago...
being a mainframe, had no working TERMCAP, and the editor was ed. yeah, a
bit painful, the only command that you
so maybe we just add nano-tiny as an option to vim-tiny.
because we understand vim is not newbie friendly, but for all the old
hands, nano is not friendly to us.
234K is a small price to pay.
On Mon, Mar 16, 2020 at 7:27 PM Guus Sliepen wrote:
> On Mon, Mar 16, 2020 at 01:02:47PM +, Wookey w
fwiw, looking at the repo on github. There are tags. They're just dates,
Ideally one would get an idea of what the tags are from upstream, but you
could just git clone using a tag. Also github allows you to easily get a
tarball given a tag:
wget https://github.com/hboetes/mg/tarball/20180927
translation of spanish email: disappointed wifi didn´t work out of the box
with Debian thinking wifi drivers are missing.
answer:
I don't think the drivers are the problem for wifi in Debian. Most, if not
all wireless chipsets have open source drivers which are included. The
problem is that
On Sun, Apr 7, 2019 at 11:10 PM Ben Finney wrote:
> Peter Silva writes:
>
> > […] the launchpad.net model, which supports backporting seamlesslly
> > and allows to support the same version on all distro versions, works
> > better for us. This is something a debian ve
On Sun, Apr 7, 2019 at 8:41 PM Roberto C. Sánchez
wrote:
> On Sun, Apr 07, 2019 at 05:50:37PM -0400, Peter Silva wrote:
> >
> >Hiring debian devs to get the packages into debian proper could make
> >sense. One thing that dampens our enthusiasm for that at the mome
On Sun, Apr 7, 2019 at 1:27 PM Roberto C. Sánchez
wrote:
> On Sun, Apr 07, 2019 at 10:13:58AM -0400, Peter Silva wrote:
> >fwiw, our organization doesn't have any debian devs. We have a few
> >packages that we develop and deploy
> >for our internal needs,
>
>
> > * RockPro64, used as a desktop (I'm typing these words on it):
> > armsoc. GNOME no workie.
>
> Hows the 3D performance on this?
>
>
https://www.cnx-software.com/2018/08/27/rockpro64-rk3399-board-linux-review-ubuntu-18-04/
71fps or es2gears?
but that was a year ago... likely better now
fwiw, our organization doesn't have any debian devs. We have a few
packages that we develop and deploy
for our internal needs, and make available to the internet with public
repositories. they are (perhaps not perfectly) debian compliant packages,
but we aren't blessed debian devs (and frankly c
iso_en ? That sounds smart...
English for most of the world that aren't necessarily native English
speakers? https://en.wikipedia.org/wiki/International_English
Use ISO dates and stuff, and pick a random spelling. As a Canadian, I'm
pretty sure about colour, but unclear about whether we should st
another option:
-- it is best practice for daemons/services not to run as root. They
should have an application specific user.
-- some tools can be run in a systemish way by a specific user, but
also by other users in a less official way (think web server on a high
port instead of port 80.)
--
PNQteam naturally leads to Pinocchio ... which isn't in Toy Story,
but you can't have everything.
On Thu, Aug 17, 2017 at 6:05 PM, Geert Stappers wrote:
> On Thu, Aug 17, 2017 at 11:22:03PM +0200, Joerg Jaspert wrote:
>> On 14767 March 1977, Jonathan Carter wrote:
>> >> it has been quite a whil
Isn't there kind of a universal issue that tar and compression happen
sort of in the wrong order? Wouldn't it make more sense to make files
that were .gz.tar (ie. compress the files individually, then have an
index into them via tar.) Then tar works perfectly well for
extracting individual files
ian Seiler wrote:
> On 08/13/2017 07:11 PM, Peter Silva wrote:
>>> apt by default automatically deletes packages files after a successful
>>> install,
>>
>> I don't think it does that.
>
> The "apt" command line tool doesn't, but traditi
May 28 11:28
xserver-xorg-video-nvidia_375.66-1_amd64.deb
-rw-r--r-- 1 root root 3101944 Jul 16 17:14
xserver-xorg-video-nvidia_375.66-2~deb9u1_amd64.deb
blacklab%
On Sun, Aug 13, 2017 at 12:43 PM, Julian Andres Klode wrote:
> On Sun, Aug 13, 2017 at 10:53:16AM -0400, Peter Silva wrote:
>>
You are assuming the savings are substantial. That's not clear. When
files are compressed, if you then start doing binary diffs, well it
isn't clear that they will consistently be much smaller than plain new
files. it also isn't clear what the impact on repo disk usage would
be.
The most straig
23 matches
Mail list logo