I perhaps should have not been quite so forceful with your statement. If you have gone out and tried out some different keyboards and made a conscious choice, that's fine. It's people who just order some $10 keyboard or something because it's cheap that I don't get. (Or people who go "yeah I'd like to get that $50 keyboard but it's too expensive. But yes I need SLI and the extreme edition processor!")
I suspect being actually plugged in and powered makes the difference, though I don't discount the possibility of unusually poor build quality (in that respect) from MS. But it seems like just a teaspoon or two of water is enough to cause significant problems.
You hit someone with a Model M, they're going down.
Unfortunately that'll be me hitting you after I have to listen to you type for a couple hours.:-)
(I'm well aware of the model M's reputation, but I don't find the better "button feel" to be anywhere near worth the noise, let alone the lack of a split keyboard or the Natural 4000's reverse tilt which I really really wish was more common. That alone makes typing far more comfortable; I don't understand why it's basically the only keyboard out there with that feature.)
I think you'd have to do a little more than sneeze on it - but I am well aware of stories in the past where e.g. sporters who sweated a little (much) got told by the service center that the humidity indicators in their iPod (or similar) indicated the device got wet and thus the warranty was void.
Heck, there was a story on here a while back about how just bringing in your phone from the cold was enough to trip the humidity sensor from small amounts of condensation. Personally, I think that it's BS that's legal, but whatever, it is.
I've killed two separate MS Natural 4000s, one about 30 minutes after getting it. It's very rare that I'll spill, but man, it seems like just a little splash has a high probability of rendering it useless.
Personally though, the extra comfort of a comfortable-to-use keyboard is worth an occasional fairly-expensive (at least for a grad student) replacement. I never understand people who spend like $1500 for an awesome gaming rig or something and then get a cheapass keyboard, which is one of the couple components you actually use. But I might just be overly sensitive or something; I do pay a lot of attention to arm ergonomics as fallout from wrist problems many years back.
I do think that this is one of those very vague, under-spec'ed questions. But...
You're running out of disk space, yet you're encoding audio with a technically inferior format that uses more space for less quality than other formats.
If he's running out of space on 8 TB, I'd say that audio is almost certainly the least of his problem. I don't exactly have a huge CD collection, but I do have somewhere around 300 CDs that I have ripped to FLAC, and that comes to under 100 GB. He could have 8 times the number of CDs I do and the audio portion would still only be a reasonably small 10% -- and that's ignoring the difference between Vorbis and FLAC.
I've actually wanted to do some tests about that actually, and I might have a little spare time coming up. What I don't know is what programs to test with... I've got one or two pieces of software from my research group I might be able to trick up, but does anyone have any other suggestions for programs which build under both MSVC and MinGW without too much pain?
The only people that really need to look at the standards is the people who implement the standard -- these are the people the standards documents are written for.
One more group: people who write books and other information for your typical programmer.
Also language lawyers like me who need ammunition to tell people to stop doing stupid stuff.
So while I'll admit I wasn't familiar with AWE before your post (well, it sounds vaguely familiar, but that's all), It sounds more like overlays to me. Still sounds like it's something the program would have to be explicitly written for.
..your statement that "So GCC *could* use 6GB on a 32bits machine" is absolutely false...
OK, there is one qualification to this statement, which is that you have to stick to a flat memory model for it to hold. By my understanding, if you could split GCC somehow and access different places in memory across segments, you might be able to break the 4 GB virtual address space barrier.
You need to go re-read your source on PAE (or tell them to reread their source).
PAE does not increase the memory space available to a single process, so your statement that "So GCC *could* use 6GB on a 32bits machine" is absolutely false. What PAE allows is multiple processes to, in total, take more than 4 GB. (So you could have a 32-bit machine with 6 GB of RAM and have, e.g., two GCC processes, each taking 3 GB with no paging.)
Clarification (I've posted this a few times): there's no 64-bit version of MSVC that targets 32 bits. There is a 64-bit version which targets 64 bits, but that doesn't help the current situation.
Correct. There are toolchains for 32-targeting-32, 32-targeting-64, 64-targeting-64, but no 64-targeting-32. (And from what people are saying, no 64-to-32 on the near horizon either.)
I agree with that, and I don't want to dispute that particular benefit of GCC (or more broadly, open source).
But saying "I should have a 64->32 linker so that it can use more than 4 GB of memory" is a lot different from saying "MSVC is bloated if linking takes 4 GB".:-)
Templates out the wazoo. Don't blame me, I didn't design it. (Or write most of it; I'm only tangentially related nowadays.)
Point being, there are features which, while valuable, are costly. I blame our source, our fondness of templates, and the compilation consequences that templates almost necessitate way more than I blame GCC for having a poor implementation of templates.
But similarly, going "stupid bloaty MSVC, it shouldn't support this feature which can give double-digit percentage speedup because it takes a lot of memory" is stupid. LTO is costly -- period. It's just very worth it.
Clarification: the only linker for 32-bit targets is, itself, 32-bits.
The linker which targets 64-bit Windows is still 64 bits. If they had a 64-bit-to-32-bit cross compiler (they have the reverse, but not 64-to-32) that would solve Mozilla's problem. (Well, for some definition of "their problem.")
Speaking of someone who regularly does large C++ builds, MSVS is nowhere near a bad culprit here. The linker is essentially doing code generation -- link time optimization. Why? Because LTO gives a substantial performance benefit. The profile-guided optimization mentioned in the summary gets them about 10% over even doing non-profile-guided LTO.
One project I've worked on has single files which cause GCC to take over 6 GB to compile when you compile with -O2. Who's bloated now?
(Takeaway: broadly speaking, MSVS is actually very competitive, at least compared with GCC, when comparing similar settings.)
I didn't say I thought it wasn't going to get passed. I was just responding to the outright wrong claim that it had been passed and "gladly" signed into law by Obama.
I've always wondered what would happen if someone countersued for false advertisement or something. Like this cover says "Bach, six suites for cello", not "Bach, six suites for cello, arranged by so-and-so."
I'm not really saying "if you have Cygwin installed". I have it on all of my Windows installations and use it a fair bit. At the same time, it has a lot of problems. Interoperability with Windows programs can get really annoying (particularly translating paths back and forth), and my personal viewpoint is that I avoid it for most things if there's a native Windows alternative. (E.g. I use native Python, a native Emacs, usually even use cmd.exe instead of zsh, etc.)
I'm more talking about people who are constantly working in a Cygwin environment. It always seems like it'd be easier to change to Linux and run a VM or something for that one Windows app.
Slashdot Mirror
I perhaps should have not been quite so forceful with your statement. If you have gone out and tried out some different keyboards and made a conscious choice, that's fine. It's people who just order some $10 keyboard or something because it's cheap that I don't get. (Or people who go "yeah I'd like to get that $50 keyboard but it's too expensive. But yes I need SLI and the extreme edition processor!")
I suspect being actually plugged in and powered makes the difference, though I don't discount the possibility of unusually poor build quality (in that respect) from MS. But it seems like just a teaspoon or two of water is enough to cause significant problems.
You hit someone with a Model M, they're going down.
Unfortunately that'll be me hitting you after I have to listen to you type for a couple hours. :-)
(I'm well aware of the model M's reputation, but I don't find the better "button feel" to be anywhere near worth the noise, let alone the lack of a split keyboard or the Natural 4000's reverse tilt which I really really wish was more common. That alone makes typing far more comfortable; I don't understand why it's basically the only keyboard out there with that feature.)
I think you'd have to do a little more than sneeze on it - but I am well aware of stories in the past where e.g. sporters who sweated a little (much) got told by the service center that the humidity indicators in their iPod (or similar) indicated the device got wet and thus the warranty was void.
Heck, there was a story on here a while back about how just bringing in your phone from the cold was enough to trip the humidity sensor from small amounts of condensation. Personally, I think that it's BS that's legal, but whatever, it is.
I've killed two separate MS Natural 4000s, one about 30 minutes after getting it. It's very rare that I'll spill, but man, it seems like just a little splash has a high probability of rendering it useless.
Personally though, the extra comfort of a comfortable-to-use keyboard is worth an occasional fairly-expensive (at least for a grad student) replacement. I never understand people who spend like $1500 for an awesome gaming rig or something and then get a cheapass keyboard, which is one of the couple components you actually use. But I might just be overly sensitive or something; I do pay a lot of attention to arm ergonomics as fallout from wrist problems many years back.
Another option with FreeBSD is ZFS, which is pretty sexy.
I do think that this is one of those very vague, under-spec'ed questions. But...
You're running out of disk space, yet you're encoding audio with a technically inferior format that uses more space for less quality than other formats.
If he's running out of space on 8 TB, I'd say that audio is almost certainly the least of his problem. I don't exactly have a huge CD collection, but I do have somewhere around 300 CDs that I have ripped to FLAC, and that comes to under 100 GB. He could have 8 times the number of CDs I do and the audio portion would still only be a reasonably small 10% -- and that's ignoring the difference between Vorbis and FLAC.
I've actually wanted to do some tests about that actually, and I might have a little spare time coming up. What I don't know is what programs to test with... I've got one or two pieces of software from my research group I might be able to trick up, but does anyone have any other suggestions for programs which build under both MSVC and MinGW without too much pain?
The only people that really need to look at the standards is the people who implement the standard -- these are the people the standards documents are written for.
One more group: people who write books and other information for your typical programmer.
Also language lawyers like me who need ammunition to tell people to stop doing stupid stuff.
There's no obviously bad browser anymore, but we also don't have an obviously superior browser.
Alternatively, if you're me you think that all browsers are bad, but approximately equally. ;-)
So while I'll admit I wasn't familiar with AWE before your post (well, it sounds vaguely familiar, but that's all), It sounds more like overlays to me. Still sounds like it's something the program would have to be explicitly written for.
Interesting question. I'll get back to you.
(They'll be large, but not tremendously large. The real problem arises because of a combination of the size and lots of template use.)
..your statement that "So GCC *could* use 6GB on a 32bits machine" is absolutely false...
OK, there is one qualification to this statement, which is that you have to stick to a flat memory model for it to hold. By my understanding, if you could split GCC somehow and access different places in memory across segments, you might be able to break the 4 GB virtual address space barrier.
You need to go re-read your source on PAE (or tell them to reread their source).
PAE does not increase the memory space available to a single process, so your statement that "So GCC *could* use 6GB on a 32bits machine" is absolutely false. What PAE allows is multiple processes to, in total, take more than 4 GB. (So you could have a 32-bit machine with 6 GB of RAM and have, e.g., two GCC processes, each taking 3 GB with no paging.)
There is no 64-bit version of the MSVC linker
Clarification (I've posted this a few times): there's no 64-bit version of MSVC that targets 32 bits. There is a 64-bit version which targets 64 bits, but that doesn't help the current situation.
Correct. There are toolchains for 32-targeting-32, 32-targeting-64, 64-targeting-64, but no 64-targeting-32. (And from what people are saying, no 64-to-32 on the near horizon either.)
In this particular case, it's actually doing link-time code generation for optimization purposes.
I agree with that, and I don't want to dispute that particular benefit of GCC (or more broadly, open source).
But saying "I should have a 64->32 linker so that it can use more than 4 GB of memory" is a lot different from saying "MSVC is bloated if linking takes 4 GB". :-)
Templates out the wazoo. Don't blame me, I didn't design it. (Or write most of it; I'm only tangentially related nowadays.)
Point being, there are features which, while valuable, are costly. I blame our source, our fondness of templates, and the compilation consequences that templates almost necessitate way more than I blame GCC for having a poor implementation of templates.
But similarly, going "stupid bloaty MSVC, it shouldn't support this feature which can give double-digit percentage speedup because it takes a lot of memory" is stupid. LTO is costly -- period. It's just very worth it.
Also MSVC only has 32-bit binaries
Clarification: the only linker for 32-bit targets is, itself, 32-bits.
The linker which targets 64-bit Windows is still 64 bits. If they had a 64-bit-to-32-bit cross compiler (they have the reverse, but not 64-to-32) that would solve Mozilla's problem. (Well, for some definition of "their problem.")
Speaking of someone who regularly does large C++ builds, MSVS is nowhere near a bad culprit here. The linker is essentially doing code generation -- link time optimization. Why? Because LTO gives a substantial performance benefit. The profile-guided optimization mentioned in the summary gets them about 10% over even doing non-profile-guided LTO.
One project I've worked on has single files which cause GCC to take over 6 GB to compile when you compile with -O2. Who's bloated now?
(Takeaway: broadly speaking, MSVS is actually very competitive, at least compared with GCC, when comparing similar settings.)
Congratulations, you are the winner of the latest revision of my mind virus!
I didn't say I thought it wasn't going to get passed. I was just responding to the outright wrong claim that it had been passed and "gladly" signed into law by Obama.
I've always wondered what would happen if someone countersued for false advertisement or something. Like this cover says "Bach, six suites for cello", not "Bach, six suites for cello, arranged by so-and-so."
I'm not really saying "if you have Cygwin installed". I have it on all of my Windows installations and use it a fair bit. At the same time, it has a lot of problems. Interoperability with Windows programs can get really annoying (particularly translating paths back and forth), and my personal viewpoint is that I avoid it for most things if there's a native Windows alternative. (E.g. I use native Python, a native Emacs, usually even use cmd.exe instead of zsh, etc.)
I'm more talking about people who are constantly working in a Cygwin environment. It always seems like it'd be easier to change to Linux and run a VM or something for that one Windows app.