Probably my previous message was misunderstood, so I try to rephrase it.
Current Debian Stable is Debian Jessie. The latest Linux kernel for Debian
Jessie is 3.16. The said version of Linux kernel on the said version of Debian
includes btrfs module. But documentation for this version of kernel s
On Sat, 09 Jul 2016, german...@ya.ru wrote:
> >If you are very conservative on these matters, your two choices are ext4 and
> >XFS.
>
> I don't want XFS because it has weak journaling compared with "data=journal"
> mode of ext3/4.
The data=journal mode of ext4 is less stable than the default
da
On 4 July 2016 at 18:38, Ben Hutchings wrote:
> On Mon, 2016-07-04 at 16:01 -0400, Nicholas D Steeves wrote:
> [...]
> [...]
>> So for radeon hardware enablement, there is 1) the proprietary driver
>
> fglrx is dead upstream and removed from unstable. (It's still in
> jessie-backports, but shoul
Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Control: block 829461 by -1
Package name: golang-github-rogpeppe-fastuuid
Version: 0.0~git20150106
Upstream Author: Roger Peppe
Licens
>Believe the upstream. While in the nearest kernel, there is no sentence about
>"under heavy
development". Installer is just installer.
It doesn't matter if the latest stable Linux kernel has stable and mostly
bug-free btrfs. The problem is, that the latest stable Linux kernel for the
latest De
On 5 July 2016 at 08:40, Samuel Henrique wrote:
>
> 2016-07-05 7:43 GMT-03:00 Jose R R :
>>
>> We're getting to the point where there's a fairly pressing need for
>> arm64 - the more useful hardware is starting to get a wider distribution
>> and we don't really have anything for people who want to
Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Control: block 829461 by -1
Package name: golang-github-dghubble-sling
Version: 1.0
Upstream Author: Dalton Hubble
License: Expat
>If you are very conservative on these matters, your two choices are ext4 and
>XFS.
I don't want XFS because it has weak journaling compared with "data=journal"
mode of ext3/4.
I tried to use ext4 on Debian Stable due to metadata checksums, but then
discovered that e2fsck doesn't support this
>Please don't use btrfs. Especially not without understanding fully
what one is getting oneself into. It is checksuming, copy of write
filesystem, however it has degrading over time performance and
stability/recovery issues.
But if btrfs is so unstable, then what the hell it's doing in Debian Sta
Marco d'Itri wrote:
> On Jul 08, Russ Allbery wrote:
> > And of those two choices, I would lean heavily towards ext4. I have seen
> > repeated file system corruptions, kernel panics, and file systems that get
> > extremely slow after heavy usage for multiple months under XFS, and have
> > not see
Hello,
On 8 July 2016 at 16:55, wrote:
> I value stability of a FS over other considerations like shiny new features
> and performance. I know that Debian Stable includes only that versions of
> software that were considered rock-solid and mostly bug-free. But on the
> other hand I read docum
On Jul 08, Russ Allbery wrote:
> And of those two choices, I would lean heavily towards ext4. I have seen
> repeated file system corruptions, kernel panics, and file systems that get
> extremely slow after heavy usage for multiple months under XFS, and have
> not seen any of those problems with
Package: wnpp
Severity: wishlist
Owner: Michael Fladischer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: python-django-navtag
Version : 2.1.1
Upstream Author : Chris Beaven
* URL : http://github.com/SmileyChris/django-navtag
* License : BSD-
Henrique de Moraes Holschuh writes:
> On Fri, 08 Jul 2016, german...@ya.ru wrote:
>> I value stability of a FS over other considerations like shiny new
>> features and performance. I know that Debian Stable includes only that
> Then, your case is pretty clear: stay away from brtfs. If you are v
On Fri, 08 Jul 2016, german...@ya.ru wrote:
> I value stability of a FS over other considerations like shiny new
> features and performance. I know that Debian Stable includes only that
Then, your case is pretty clear: stay away from brtfs. If you are very
conservative on these matters, your two
On Fri, Jul 08, 2016 at 02:54:20PM +0200, Enrico Zini wrote:
> What if you received a message signed with key 9F6C6333?
>
> That is, what do you do (please list the practical steps) to validate a
> signature that is a few steps away from your key in the WoT?
trust in the real world depends on more
german...@ya.ru wrote:
>I value stability of a FS over other considerations like shiny new features
>and performance. I know that
>Debian Stable includes only that versions of software that were considered
>rock-solid and mostly
>bug-free. But on the other hand I read documentation for version of
Package: wnpp
Severity: wishlist
Owner: Marcos
* Package name: ncrack
Version : 0.5
Upstream Author : Insecure.Com LLC
* URL : http://nmap.org/ncrack/
* License : GPLv2
Programming Lang: C++
Description : High-speed network authentication cracking tool
Hi Enrico,
On Fri, 08 Jul 2016 at 11:21:27 +0200, Enrico Zini wrote:
> gpg --verify tells me of a short key ID:
In fact the issuer subpacket is 8-bytes long [0], hence contains the
long key ID of the signer, as seen using ‘--list-packets’:
~$ gpg --list-packets "
imported
gpg: no ultima
On Fri, Jul 8, 2016 at 10:55 PM, wrote:
> I value stability of a FS over other considerations like shiny new features
> and performance. I know that Debian Stable includes only that versions of
> software that were considered rock-solid and mostly bug-free. But on the
> other hand I read docum
I value stability of a FS over other considerations like shiny new features and
performance. I know that Debian Stable includes only that versions of software
that were considered rock-solid and mostly bug-free. But on the other hand I
read documentation for version of a Linux kernel of Debian S
* Simon Richter , 2016-07-08, 14:33:
given that it is now possible to generate arbitrary short key ID
collisions[1], and that it's now computationally feasible to at least
generate a pair of keys with colliding long key IDs, I'd like to
rethink practices and tools.
With the web of trust, in p
On Fri, Jul 08, 2016 at 02:33:54PM +0200, Simon Richter wrote:
> > given that it is now possible to generate arbitrary short key ID
> > collisions[1], and that it's now computationally feasible to at least
> > generate a pair of keys with colliding long key IDs, I'd like to rethink
> > practices a
Hi Enrico,
On 08.07.2016 11:21, Enrico Zini wrote:
> given that it is now possible to generate arbitrary short key ID
> collisions[1], and that it's now computationally feasible to at least
> generate a pair of keys with colliding long key IDs, I'd like to rethink
> practices and tools.
With the
This is a call for help for one or two volunteers who:
- are keen on gitish (or similar workflows)
- have some time right now
- can speak Perl (as found in dpkg-source)
- are willing and able to do some negotiation as well as coding
Introduction:
One persistent difficulty with our current s
* Enrico Zini , 2016-07-08, 11:21:
$ mkdir /tmp/keyring
$ chmod 0700 /tmp/keyring
This way of creating a directory inaccessible to other is racy. Between
mkdir and chmod calls, the directory could be opened by an attacker (and
then kept open forever). A non-racy way looks like this:
$ mkd
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: r-cran-treescape
Version : 1.9.17
Upstream Author : Thibaut Jombart, Michelle Kendall, Jacob Almagro-Garcia,
Caroline Colijn
* URL : https://cran.r-project.org/web/packages/treescape/
* License
On Fri, Jul 08, 2016 at 08:56:37AM +0200, Adam Borowski wrote:
> On Thu, Jul 07, 2016 at 11:03:16PM -0700, Josh Triplett wrote:
> > Tollef Fog Heen wrote:
> > > ]] Josh Triplett
> > > > Tollef Fog Heen wrote:
> > > > > I personally recommend using deb.debian.org.
> > > >
> > > > That works nicely,
Hello,
given that it is now possible to generate arbitrary short key ID
collisions[1], and that it's now computationally feasible to at least
generate a pair of keys with colliding long key IDs, I'd like to rethink
practices and tools.
In the spirit of "first get to do it, then document it, then
]] Josh Triplett
> [Please CC me on replies.]
>
> Tollef Fog Heen wrote:
> > ]] Josh Triplett
> > > Tollef Fog Heen wrote:
> > > > I personally recommend using deb.debian.org.
> > >
> > > That works nicely, thanks! Seems to have decent performance.
> > >
> > > I couldn't find any announcement
30 matches
Mail list logo
