hi,
On Thu, Mar 6, 2014, at 2:23, Adam Conrad wrote:
I wouldn't be entirely against this option, if the performance hit is
measurably not awful in general purpose usage.
I'd rather approach the problem from the point of we must have correct
code.
Once we establish that we then ask the
I'd like to extend the installer's cryptsetup script to allow for:
1. Execution of a pre-cryptsetup script, if it exists, placed conveniently in
the root of the installation medium.
2. User specification of parameters.
The official installers do not allow this. While we can work around this
On 25 August 2013 17:54, PHP Nut php...@live.com wrote:
I'd like to extend the installer's cryptsetup script to allow for:
1. Execution of a pre-cryptsetup script, if it exists, placed conveniently
in the root of the installation medium.
2. User specification of parameters.
The official
On 6 March 2014 14:44, Ryan Lortie de...@desrt.ca wrote:
hi,
On Thu, Mar 6, 2014, at 2:23, Adam Conrad wrote:
I wouldn't be entirely against this option, if the performance hit is
measurably not awful in general purpose usage.
I'd rather approach the problem from the point of we must have
hi,
On Thu, Mar 6, 2014, at 2:23, Adam Conrad wrote:
I wouldn't be entirely against this option, if the performance hit is
measurably not awful in general purpose usage.
So I did some measurements against the 'radial-perf-test' in pixman,
compiled with all of the special asm/mmx/sse2/etc.
hi,
On Thu, Mar 6, 2014, at 15:12, Dimitri John Ledkov wrote:
I don't think that's the right approach here. We do have correct code
in our packages, and where needed packages do raise standards version
/ target cpu features etc. to generate performant / correct or
optimized code.
It seems
On Thu, Mar 06, 2014 at 08:12:13PM +, Dimitri John Ledkov wrote:
On Thu, Mar 6, 2014, at 2:23, Adam Conrad wrote:
I wouldn't be entirely against this option, if the performance hit is
measurably not awful in general purpose usage.
I'd rather approach the problem from the point of we
On Thu, Mar 06, 2014 at 04:06:31PM -0500, Ryan Lortie wrote:
On Thu, Mar 6, 2014, at 15:12, Dimitri John Ledkov wrote:
I don't think that's the right approach here. We do have correct code
in our packages, and where needed packages do raise standards version
/ target cpu features etc. to
hi,
On Thu, Mar 6, 2014, at 16:34, Steve Langasek wrote:
It's interesting to ask whether we *should* use -std=c99 by default. But
that's a rather large change, and not something we would do this late in
the cycle and not without rebuild tests beforehand.
I completely agree on this point. I
On Thu, Mar 06, 2014 at 01:34:54PM -0800, Steve Langasek wrote:
This is a prejudicial framing of the question. :) The compiler is not
producing code that is incorrect, it's producing code that is inconsistent
with the particular standard that glib upstream is expecting. If glib
requires a
On Thu, Mar 06, 2014 at 08:52:38PM -0500, Ryan Lortie wrote:
fwiw, gnu99 doesn't stop the bug. You have to pick -std=c99
specifically.
Curious. You'd have to ask someone who works more with GCC upstream
to be sure, but I'd consider that I bug. I've always assumed and
treated gnuXX as a
On Thursday, March 06, 2014 09:44:14 Ryan Lortie wrote:
...
By currently run on do you mean that we actually run on these in
situations that we know about, or that we have the theoretical ability,
if someone wanted to...
I'm fairly sure that Unity would not run nicely on any hardware from
Ryan Lortie [2014-03-06 16:06 -0500]:
double a, b;
a = get_value ();
b = get_value ();
if (a != b)
I know it's a bit tangential, but isn't it taught in like every book
and tutorial that one should never compare floating point numbers for
(in)equality? That's why e. g. Python has
On Wed, Mar 05, 2014 at 05:18:16PM +, Colin Watson wrote:
The best information I can find is in
https://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc-head-build-for-arm64-platform/,
which does suggest that there might be some hope, but it's not at all
clear whether GHC will get beyond
We've had a lot of internal Canonical discussions about our networking
story and before going to a UDS session [1] it was suggested to post to
ubuntu-devel.
*Network Restart*
I'd like to start by asking each of you what you think is the correct way
to restart networking on Ubuntu server? Feel
Why was it necessary to have discussions internally when they could
have been open by default?
On Thu, Mar 6, 2014 at 11:48 AM, Bryan Quigley
bryan.quig...@canonical.com wrote:
We've had a lot of internal Canonical discussions about our networking story
and before going to a UDS session [1] it
On 6 March 2014 21:32, Benjamin Kerensa bkere...@ubuntu.com wrote:
Why was it necessary to have discussions internally when they could
have been open by default?
Eh... this particular bug is public and well known in both Debian and
Ubuntu for a long time now.
As you can see in that email, he
If talking about the network, I would add:
*Wifi + Ethernet on Desktop*
The network gets lost if you have both wireless and Ethernet connection.
The wired network should be the preferred one, as it is usually faster.
Or else, the recently connected/enabled can become active. Anyway,
plugging
On Thursday, March 06, 2014 14:48:52 Bryan Quigley wrote:
We've had a lot of internal Canonical discussions about our networking
story and before going to a UDS session [1] it was suggested to post to
ubuntu-devel.
*Network Restart*
I'd like to start by asking each of you what you think is
The only feature I hold near and dear is that I be able
to ssh into a server in a rack 8000 miles away, fiddle
with /etc/network/interfaces if needed, and then reliably
ifdown/ifup one of god knows how many connections (I often
work with machines that have 8 or even more hardware ethers,
not to
On Thu, Mar 06, 2014 at 11:32:41PM +0100, Stanisław Hodur wrote:
*Wifi + Ethernet on Desktop*
Which reminds me of another common use of machines that a typical
GUI user won't think of.
I often configure laptops that for security have wifi, bluetooth
etc all turned off at BIOS level, and the
21 matches
Mail list logo
