On Wed, Nov 08, 2017 at 09:43:29AM +0200, Henri Sivonen wrote:
> I agree that workstation GPUs should be avoided. Even if they were as
> well supported by Linux distro-provided Open Source drivers as
> consumer GPUs, it's at the very least more difficult to find
> information about what's true abou
With all this talk…
I’m eagerly waiting for the iMac Pro.
Best of all worlds really:
- High core count
- ECC RAM
- 5K 27” display
- Great graphic card
- Super silent…
I’ve been using a Mac Pro 2013 (the trash can one), Xeon E5 8 cores, 32 GB ECC
RAM, connected to two 27” screens (one 5K with DP
With all this talk…
I’m eagerly waiting for the iMac Pro.
Best of all worlds really:
- High core count
- ECC RAM
- 5K 27” display
- Great graphic card
- Super silent…
I’ve been using a Mac Pro 2013 (the trash can one), Xeon E5 8 cores, 32 GB ECC
RAM, connected to two 27” screens (one 5K with DP
Thanks Jeff, I understand your reasoning. 14 cores vs 10 is definitely
huge.
I will also add, there isn't anything to stop us to having more than one
config, just like we do with laptops.
I'm fortunate to be in this situation to finally help you all have
influence on the type of hardware that mak
Kris has touched on the many advantages of having a standard model. From
what I am seeing with most people's use case scenario, only the GPU is what
will determine what the machine is used for. IE: VR Research team may end
up only needing a GPU upgrade.
Fortunately the new W-Series Xeon's seem to
On 2017-11-07 5:03 PM, James Graham wrote:
On 07/11/17 13:47, Tom Ritter wrote:
Warning: they auto-shut down after 30 minutes (maybe? I never timed
it). I haven't put any effort into figuring out if that's
configurable, but I don't think it is.
I think that only happens once the trial period
On 11/7/17 4:13 PM, Sophana "Soap" Aik wrote:
Nothing is worse than hearing IT picked or chose hardware that nobody
actually wanted or will use.
If I could interject with a comment about the hardware we pick...
The last desktop I was shipped came with a 512 GB drive. One of our
srcdirs is ab
I’d like to add the VM multiplier: I’m working mainly on OSX and run a Windows
and a Linux VM in there with their own checkouts and objdirs. Instead of
allocating a comfortable size virtual disks, I end up resizing them quite
frequently to avoid running out of space to save as much as possible f
On 08/11/17 17:28, Boris Zbarsky wrote:
> The last desktop I was shipped came with a 512 GB drive. [..]
>
> In practice, I routinely run out of disk space and have to delete
> objdirs and rebuild them the next day, because I have to build
> something else in a different srcdir...
I totally agree
This thread is good feedback. I think changing the default to a 1TB SSD is
a reasonable request.
Please send any future comments regarding hardware to Sophana (
s...@mozilla.com) to increase the chances that feedback is acted on.
On Wed, Nov 8, 2017 at 9:09 AM, Julian Seward wrote:
> On 08/11/1
Does this cache bytecode for about: pages as well? As an example, caching
bytecode for various JS scripts from resource: and chrome: for about:home might
get interesting startup improvements...
Thanks,
Dan
___
dev-platform mailing list
dev-platform@li
Hi,
In bug 1317937 I intend to unship the feature of elements acting the
same way as elements in image maps.
This functionality was specced in HTML 4, but no other browser
implemented it and was removed from HTML 5.
Timothy (:tnikkel) tried to do it before, but it got blocked on getting
teleme
Is it always safe and portable to do:
char* p1 = ...;
uint8_t* p2 = reinterpret_cast(p1);
uint8_t u8 = p2[0];
without breaking strict aliasing?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Wed, Nov 08, 2017 at 06:04:27PM -0800, jww...@mozilla.com wrote:
Is it always safe and portable to do:
char* p1 = ...;
uint8_t* p2 = reinterpret_cast(p1);
uint8_t u8 = p2[0];
without breaking strict aliasing?
Strict aliasing permits any typed data to be accessed as char*,
so yes, this is
On Thursday, November 9, 2017 at 1:11:20 PM UTC+11, Kris Maglione wrote:
> On Wed, Nov 08, 2017 at 06:04:27PM -0800, jww...@mozilla.com wrote:
> >Is it always safe and portable to do:
> >
> >char* p1 = ...;
> >uint8_t* p2 = reinterpret_cast(p1);
> >uint8_t u8 = p2[0];
> >
> >without breaking strict
On Wed, Nov 08, 2017 at 08:09:17PM -0800, gsquel...@mozilla.com wrote:
On Thursday, November 9, 2017 at 1:11:20 PM UTC+11, Kris Maglione wrote:
On Wed, Nov 08, 2017 at 06:04:27PM -0800, jww...@mozilla.com wrote:
>Is it always safe and portable to do:
>
>char* p1 = ...;
>uint8_t* p2 = reinterpret
On 11/3/17 3:00 PM, Jonathan Kingston wrote:
Which specific issues?
The API in the specification is promise ready by using the permissions API,
is behind a permission prompt and requires a secure context.
Does that address the privacy concerns we had with device APIs before?
-Boris
___
On Thu, Nov 9, 2017 at 6:29 AM, Boris Zbarsky wrote:
> On 11/3/17 3:00 PM, Jonathan Kingston wrote:
>> Which specific issues?
>> The API in the specification is promise ready by using the permissions
>> API,
>> is behind a permission prompt and requires a secure context.
>
> Does that address the
18 matches
Mail list logo
