nothing to understand, we have coal sufficient for centuries and the means to make it into every major type of hydrocarbon fuel.
It's true that there's enough coal for centuries. However, if we keep using it the way we do now, these centuries will be spent underwater. The power crisis will kick in when sea levels start rising so fast that power will be capped during peak ours, for *everyone*. Either we start adapting now, or we'll pay for it tenfold later.
Just as I posted that I remembered that idle power draw on 3.5" drives isn't 1W, it's ~4W... I was thinking about 2.5" drives. This is compared to the 40W to 60W that a typical CPU will consume.
With SSDs and the reduced issue of plater spin up, I can imagine servers that stand-by and wake up if there is any activity on a specified port
SSDs don't actually consume much less power than platter-based drives, but they're far more expensive. The spin-up/down is mitigated if there's good caching on the controller, and I think that's the key here -- caching. You can have a couple of terabytes on a server, but the drives aren't called until something is requested which *isn't* on the controller's buffer.
I should point out though that power consumption of HDs are insignificant compared to the rest of the system. If you want to avoid the spin-up issue, just never spin them down. An idle, spinning HD normally won't consume much over 1W -- that's one *single* watt. How does that compare to the CPU power draw?
Here's that article on Tom's Hardware where they revised their SSD power consumption tests, though it's a year old now.
(I should probably keep this in a text file on my desktop, it's a "batch of advice" which I frequently have to re-write, and it doesn't change much)
I mentioned the term "modern C++" above, though really it's better to call it "sane C++". By this I mean C++ that won't drive you nuts trying to figure out what went wrong, when something inevitably *will* go wrong. Practices that make programs more safe, and introspective.
If you already know C++ (the foundations, I mean), it'll be easier to shift to STL-dependent C++. If you're completely new to C++, these resources will still be very important, but you'll need to learn the lower-level stuff in parallel, so you can understand how STL containers/templates are built from the inside (which is important when you need to choose which ones to use).
A website that should very often sit in the background while you're coding/learning: C++ FAQ Lite. Following these rules will make it much easier to design and maintain your programs.
Another very useful website: cplusplus.com. It's a huge reference site, with a lot of examples.
The books I'd recommend: Accelerated C++ -- higher-level to lower-level approach. C++ Coding Standards -- similar to the C++ FAQ Lite in the nature of the advice, but covers more ground and is probably better organized. C++ Common Knowledge -- This is for a few months down the line, delves into some nuances.
Software:
Windows: Visual Studio C++ Express -- You can force it to stick to ANSI C++. It's still the best IDE for C++ on windows (IMO).
Linux/Mac: Eclipse, probably Eclipse IDE for C/C++ Developers. Remember though that you can tweak Eclipse into just about anything.
If you're writing end-user applications, keep in mind two frameworks: Qt and wxWidgets.
Quick note about Boost: If you can create a structure using some combination of STL components, do that before resorting to Boost. Boost is highly abstracted, and you should only use the parts which would otherwise be extremely complicated to create from scratch (like regexp).
I guess "deprecated" is the wrong term, technically. What I meant was, that "in practice", you'd move past many of the lower-level elements of C++ and use STL instead. There's no reason to write your own String class when there's std::string, nor write your own Array class when there's std::vector (and other containers for array-like structures). Because of this, manual memory allocation is rare -- you'd only use 'new' and 'delete' in very special cases. The rest of the time you'd probably depend on RAII and scoping. You'd also avoid pointers and raw arrays, unless, again, you're *creating* a container, or if there's some extreme performance issue.
Then there's the C-compatibility stuff, that you'd never use in a pure-C++ program. They're just there to stay compatible with C (which is very important, but if you're writing something from scratch, you're not likely to malloc in C++).
These things aren't deprecated, but they are in the "lower level" bracket of C++, and in most situations are there to write the higher-level classes/templates. And since almost any container you're likely to need already exists in the STL, you're not likely to find them in a program that leans on the STL.
That's kind of the philosophy of Accelerated C++, in which the higher-level elements are covered first, and only then does it delve into the lower levels (which is the reverse way of how C++ is learned in academia).
I suppose that the main problem C++ has is its breadth (which I guess is what you meant when you said "complex beast").
(this comment didn't really go anywhere, but I'll post it anyway...)
Two things came to mind as I read that: First -- Is "modern" C++ (with STL and possibly boost) a larger beast than "modern" Java? Haven't they both been inflated to the point that 50%+ of the language is deprecated, and whenever you bring one of them up you have to "be more specific" about "which C++" or "which Java" you're referring to?
Second -- I use both C and C++ for different needs, and while it's true that C can be "kept simple" in some environments, any project of meaningful scale will become a nightmare to maintain/debug. Whenever I have a choice to skip-to-C++ (usually in embedded programming, where speed and program size are still a big issue) I do so just to I can use containers and avoid throwing pointers around. While it maybe possible to argue that C is simpler, it's also one of the languages that makes it the easiest thing in the world to shoot yourself in the foot with a 12-gauge. I'll use C when there's no other choice (again, embedded systems), but I'll switch to C++ as soon as the architecture is large/fast enough to support it.
I was referring to the "there's more than one way to do(obfuscate) it" part. Even in human languages, the ones where you only need a small set of basic vocabulary in order to communicate are much easier to learn and use.
PHP has this in common with Perl. You have 15 tools to do the same job, and each with its own keyword(reserved word). An easy way to figure out if a language is going to be a pain to use and maintain is look up its reserved words list. Another is to have two different programmers write the same program and compare the two -- the more the two programs differ, the more of a hassle it'll be.
And no, I didn't mean "read aloud", although there's also that. I don't consider this particularly readable.
You can *force* any language to appear unreadable. I'm talking about a program that was written by a competent programmer. Compare a random Python script with a random Perl script. Are you actually saying there's no difference in readability?
Javascript going back and forth between "standardized" and "open-source" depending on the ratio between the "its a published standard" and the "the standard is irrelevant, how it works in Gecko and Webkit is what matters" camps
The difference in implementation of JavaScript in browsers is actually minimal. It's the DOM, events, and CSS-related issues that mess things up. If you stick to *just* JavaScript, the worst that could happen is that IE won't have all of the Array methods (which can be filled in using the language). When it comes to implementing ECMAScript, the different browsers conform quite well.
When you say "easier to understand", do you mean "easier to read" or "easier to learn"? I guess that readability is in the "eye of the beholder", but really when you get to Python and Ruby they're almost *objectively* easier to read. With Python, you almost don't have to know the language to understand a program, it practically looks like pseudo-code (being loosely based on ABC, which is as pseudo as you can get).
I'm assuming that they meant "dynamic languages", which is relatively difficult to define as well. Is Java technically "dynamic"? (I honestly don't know how to answer that, BTW)
Java is definitely the exception, however: static-typing, and the requirement to compile to bytecode. Also, Java is the only language here that's suitable for math-oriented programming, the rest of the languages are primarily used to handle text and/or manage data-structures that contain strings as their edge(leaf?) nodes.
I guess I meant the comments which cited specific previous behavior, like what this person had previously posted on his site and elsewhere. I only knew about this guy because his abrasive language has ended up on slashdot before (check out the very first comment, by eldavojohn). I've never used his software, nor seen his code, but it doesn't take a profiler to figure out that the way he communicates with others is the primary reason for the problems he describes.
In this particular case, the slashdot reaction was "in kind" -- garbage in, garbage out. You could argue that posting this as a story on slashdot was trolling to begin with (at the moment there's a "troll" tag attached to this article, though it could change of course), but once it's been put out there, I'm not surprised by the comments that followed. Intelligent articles will usually attract intelligent reactions on slashdot, but if you pour blood in the water then this is what you get.
Also, while I don't exactly enjoy/condone this type of discourse, many of the posts are emotional reactions. Even if the result isn't pretty, it would be wrong to censor the outcome. I suppose the only thing I can really present as an argument is the usual "if you don't like it, don't look at it".
While I don't like the "plagiarize" comment in particular, I do agree that it's a plus to point out to your employer that you've implemented OSS. If they have half a brain, they will recognize that being able to implement/integrate OSS into a project is a *credit* to the developer. It means that they can spot, and take advantage of, resources that don't need to be constructed from scratch.
If your employer wants you to do X, which one of the following answers will they most like to hear:
1) I can get it done with this $5k software. Just buy it and I'll get to work.
2) I can get it done in 6 months, provided I have 2 additional programmers to work with me.
3) Sure, I know of this FOSS project that'll get the job done. You'll have it up and running over the weekend.
Nonsense. The GPL protects the freedom of coders by ensuring that they are free to modify code.
The parent post did point out that this will, unnecessarily, turn into a license war thread. At which point he started that war by throwing the first stone (wrapped in an "IMHO", but we know that doesn't change anything).
Licenses have nothing to do with TFA, as the comments above have well pointed out. There's no need to get sucked (suckered?) into another one of these flame wars just because this guy (who wrote TFA) decided to make licenses the cause of his problems, almost arbitrarily.
Attempting to follow my own "advice", I won't give my opinion on the license issue, humble or not. I will, however, point out that choosing a different license, *any* license, would not have solved this person's problems. See comments above for details.
But it's been smoking for 6 years. Are you going to keep the firetruck stationed there the entire time?
Besides, the Apple tablet in question is rumoured to have taken an unusual time to develop.
Wow! It's almost like the reason for the rumor not coming true is baked into the rumor itself!
As the saying goes, it's a self-fulfilling... rumor(?)...
You know, it's odd, I submitted my 5-page long fantasy review of the Asus EeeTablet just a couple of days ago, and it got no traction. Neither did my review of the fictitious Lenovo ThinkTablet, or my poignant preview of the Dell InspironPad...
Maybe I just can't write good fiction. I've been told that my protagonists lack a certain polish... They aren't glossy enough, and don't have the necessary price tag to attract the reader.
The 12" screen will suck the battery life out of it very quickly. For the resolution they mentioned, I actually think that the screen is too big. Something around 10" would be easier to carry around, because as it is, it seems like a rather large thing to carry around except indoors (which, I realize, is currently what it's being marketed for).
Also, he's right about the netbook aspect at least in the sense that a netbook is a feally-featured computer. This will only give you a buffed up browser, and you're going to need to depend on their software for all of the UI and functionality. In this respect, a netbook will indeed "cream" a device like this. It's far more versatile.
To me, this looks far from an iPhone with a big screen. At least in this demo the hardware seemed unresponsive, sluggish, and several attempts had to be made to get a gesture to work properly. And it was being used by someone who was already used to the device. Notice how much trouble he was having just exiting full-screen mode in YouTube, which was displaying a video that was clearly choppy (Flash uses no hardware acceleration for video).
Having said that, if they *did* manage to get the production model to a semi-usable state, enabling users to "theme" the keyboard will be important. At the very least, they'll need to give several keyboard layout options.
If all I had to go by is the demo video linked here, I'd say they're not even close to a marketable product. Which is a shame, because the overall idea is nice.
How appropriate, then, that the one thing they *do* oversee in-house is the manufacturing processes for the *cases*. They've invested quite a bit in manufacturing process development and patenting, resulting in things like the "Unibody" laptops and those highly-resilient aluminum coating materials.
So many of their customers, after all, "judge a notebook by its cover"...
Speaking of additional factors to throw into the mix:
While there's something to be said for knowing the exact hardware that your software will be running on, most reviews will comment on the very well-designed power management in Windows. In fact this is something that, from what I understand, is continually being patched through windows update. So there's a good chance that the laptop you bought 2 years ago, with the same version of windows, has a *longer* battery life, on average, than when you originally bought it. Honestly, if this information came *from* MS, I wouldn't believe them, but I've run into this particular power management anecdote in enough different articles that I tend to believe there's some truth to it.
This isn't to contradict the claim that Apple may be "lying less", but I think it's a consideration.
Slashdot Mirror
nothing to understand, we have coal sufficient for centuries and the means to make it into every major type of hydrocarbon fuel.
It's true that there's enough coal for centuries. However, if we keep using it the way we do now, these centuries will be spent underwater. The power crisis will kick in when sea levels start rising so fast that power will be capped during peak ours, for *everyone*. Either we start adapting now, or we'll pay for it tenfold later.
Just as I posted that I remembered that idle power draw on 3.5" drives isn't 1W, it's ~4W... I was thinking about 2.5" drives. This is compared to the 40W to 60W that a typical CPU will consume.
With SSDs and the reduced issue of plater spin up, I can imagine servers that stand-by and wake up if there is any activity on a specified port
SSDs don't actually consume much less power than platter-based drives, but they're far more expensive. The spin-up/down is mitigated if there's good caching on the controller, and I think that's the key here -- caching. You can have a couple of terabytes on a server, but the drives aren't called until something is requested which *isn't* on the controller's buffer.
I should point out though that power consumption of HDs are insignificant compared to the rest of the system. If you want to avoid the spin-up issue, just never spin them down. An idle, spinning HD normally won't consume much over 1W -- that's one *single* watt. How does that compare to the CPU power draw?
Here's that article on Tom's Hardware where they revised their SSD power consumption tests, though it's a year old now.
(I should probably keep this in a text file on my desktop, it's a "batch of advice" which I frequently have to re-write, and it doesn't change much)
I mentioned the term "modern C++" above, though really it's better to call it "sane C++". By this I mean C++ that won't drive you nuts trying to figure out what went wrong, when something inevitably *will* go wrong. Practices that make programs more safe, and introspective.
If you already know C++ (the foundations, I mean), it'll be easier to shift to STL-dependent C++. If you're completely new to C++, these resources will still be very important, but you'll need to learn the lower-level stuff in parallel, so you can understand how STL containers/templates are built from the inside (which is important when you need to choose which ones to use).
A website that should very often sit in the background while you're coding/learning: C++ FAQ Lite. Following these rules will make it much easier to design and maintain your programs.
Another very useful website: cplusplus.com. It's a huge reference site, with a lot of examples.
The books I'd recommend:
Accelerated C++ -- higher-level to lower-level approach.
C++ Coding Standards -- similar to the C++ FAQ Lite in the nature of the advice, but covers more ground and is probably better organized.
C++ Common Knowledge -- This is for a few months down the line, delves into some nuances.
Software:
Windows: Visual Studio C++ Express -- You can force it to stick to ANSI C++. It's still the best IDE for C++ on windows (IMO).
Linux/Mac: Eclipse, probably Eclipse IDE for C/C++ Developers. Remember though that you can tweak Eclipse into just about anything.
If you're writing end-user applications, keep in mind two frameworks: Qt and wxWidgets.
Quick note about Boost: If you can create a structure using some combination of STL components, do that before resorting to Boost. Boost is highly abstracted, and you should only use the parts which would otherwise be extremely complicated to create from scratch (like regexp).
I guess "deprecated" is the wrong term, technically. What I meant was, that "in practice", you'd move past many of the lower-level elements of C++ and use STL instead. There's no reason to write your own String class when there's std::string, nor write your own Array class when there's std::vector (and other containers for array-like structures). Because of this, manual memory allocation is rare -- you'd only use 'new' and 'delete' in very special cases. The rest of the time you'd probably depend on RAII and scoping. You'd also avoid pointers and raw arrays, unless, again, you're *creating* a container, or if there's some extreme performance issue.
Then there's the C-compatibility stuff, that you'd never use in a pure-C++ program. They're just there to stay compatible with C (which is very important, but if you're writing something from scratch, you're not likely to malloc in C++).
These things aren't deprecated, but they are in the "lower level" bracket of C++, and in most situations are there to write the higher-level classes/templates. And since almost any container you're likely to need already exists in the STL, you're not likely to find them in a program that leans on the STL.
That's kind of the philosophy of Accelerated C++, in which the higher-level elements are covered first, and only then does it delve into the lower levels (which is the reverse way of how C++ is learned in academia).
I suppose that the main problem C++ has is its breadth (which I guess is what you meant when you said "complex beast").
(this comment didn't really go anywhere, but I'll post it anyway...)
Two things came to mind as I read that:
First -- Is "modern" C++ (with STL and possibly boost) a larger beast than "modern" Java? Haven't they both been inflated to the point that 50%+ of the language is deprecated, and whenever you bring one of them up you have to "be more specific" about "which C++" or "which Java" you're referring to?
Second -- I use both C and C++ for different needs, and while it's true that C can be "kept simple" in some environments, any project of meaningful scale will become a nightmare to maintain/debug. Whenever I have a choice to skip-to-C++ (usually in embedded programming, where speed and program size are still a big issue) I do so just to I can use containers and avoid throwing pointers around. While it maybe possible to argue that C is simpler, it's also one of the languages that makes it the easiest thing in the world to shoot yourself in the foot with a 12-gauge. I'll use C when there's no other choice (again, embedded systems), but I'll switch to C++ as soon as the architecture is large/fast enough to support it.
I was referring to the "there's more than one way to do(obfuscate) it" part. Even in human languages, the ones where you only need a small set of basic vocabulary in order to communicate are much easier to learn and use.
PHP has this in common with Perl. You have 15 tools to do the same job, and each with its own keyword(reserved word). An easy way to figure out if a language is going to be a pain to use and maintain is look up its reserved words list. Another is to have two different programmers write the same program and compare the two -- the more the two programs differ, the more of a hassle it'll be.
And no, I didn't mean "read aloud", although there's also that. I don't consider this particularly readable.
I hope you intended that as satire.
You can *force* any language to appear unreadable. I'm talking about a program that was written by a competent programmer. Compare a random Python script with a random Perl script. Are you actually saying there's no difference in readability?
Javascript going back and forth between "standardized" and "open-source" depending on the ratio between the "its a published standard" and the "the standard is irrelevant, how it works in Gecko and Webkit is what matters" camps
The difference in implementation of JavaScript in browsers is actually minimal. It's the DOM, events, and CSS-related issues that mess things up. If you stick to *just* JavaScript, the worst that could happen is that IE won't have all of the Array methods (which can be filled in using the language). When it comes to implementing ECMAScript, the different browsers conform quite well.
APL: (~RâSRâ.Ã--R)/Râ1â"âR
(so pretty much like Perl...)
When you say "easier to understand", do you mean "easier to read" or "easier to learn"? I guess that readability is in the "eye of the beholder", but really when you get to Python and Ruby they're almost *objectively* easier to read. With Python, you almost don't have to know the language to understand a program, it practically looks like pseudo-code (being loosely based on ABC, which is as pseudo as you can get).
Personally I think people just got tired of counting parentheses...
Well, of course, you would need the flame to kill all of the TROLLS...
(or maybe bring some acid?)
I'm assuming that they meant "dynamic languages", which is relatively difficult to define as well. Is Java technically "dynamic"? (I honestly don't know how to answer that, BTW)
Java is definitely the exception, however: static-typing, and the requirement to compile to bytecode. Also, Java is the only language here that's suitable for math-oriented programming, the rest of the languages are primarily used to handle text and/or manage data-structures that contain strings as their edge(leaf?) nodes.
Perhaps next, they can follow Slashdot's example and phase out support for web browsers.
Slashdot supports web browsers? Since when!?
I guess I meant the comments which cited specific previous behavior, like what this person had previously posted on his site and elsewhere. I only knew about this guy because his abrasive language has ended up on slashdot before (check out the very first comment, by eldavojohn). I've never used his software, nor seen his code, but it doesn't take a profiler to figure out that the way he communicates with others is the primary reason for the problems he describes.
In this particular case, the slashdot reaction was "in kind" -- garbage in, garbage out. You could argue that posting this as a story on slashdot was trolling to begin with (at the moment there's a "troll" tag attached to this article, though it could change of course), but once it's been put out there, I'm not surprised by the comments that followed. Intelligent articles will usually attract intelligent reactions on slashdot, but if you pour blood in the water then this is what you get.
Also, while I don't exactly enjoy/condone this type of discourse, many of the posts are emotional reactions. Even if the result isn't pretty, it would be wrong to censor the outcome. I suppose the only thing I can really present as an argument is the usual "if you don't like it, don't look at it".
While I don't like the "plagiarize" comment in particular, I do agree that it's a plus to point out to your employer that you've implemented OSS. If they have half a brain, they will recognize that being able to implement/integrate OSS into a project is a *credit* to the developer. It means that they can spot, and take advantage of, resources that don't need to be constructed from scratch.
If your employer wants you to do X, which one of the following answers will they most like to hear:
1) I can get it done with this $5k software. Just buy it and I'll get to work.
2) I can get it done in 6 months, provided I have 2 additional programmers to work with me.
3) Sure, I know of this FOSS project that'll get the job done. You'll have it up and running over the weekend.
As I said, it only takes "half a brain".
Nonsense. The GPL protects the freedom of coders by ensuring that they are free to modify code.
The parent post did point out that this will, unnecessarily, turn into a license war thread. At which point he started that war by throwing the first stone (wrapped in an "IMHO", but we know that doesn't change anything).
Licenses have nothing to do with TFA, as the comments above have well pointed out. There's no need to get sucked (suckered?) into another one of these flame wars just because this guy (who wrote TFA) decided to make licenses the cause of his problems, almost arbitrarily.
Attempting to follow my own "advice", I won't give my opinion on the license issue, humble or not. I will, however, point out that choosing a different license, *any* license, would not have solved this person's problems. See comments above for details.
As the saying goes, there's no smoke without fire
But it's been smoking for 6 years. Are you going to keep the firetruck stationed there the entire time?
Besides, the Apple tablet in question is rumoured to have taken an unusual time to develop.
Wow! It's almost like the reason for the rumor not coming true is baked into the rumor itself!
As the saying goes, it's a self-fulfilling... rumor(?)...
You know, it's odd, I submitted my 5-page long fantasy review of the Asus EeeTablet just a couple of days ago, and it got no traction. Neither did my review of the fictitious Lenovo ThinkTablet, or my poignant preview of the Dell InspironPad...
Maybe I just can't write good fiction. I've been told that my protagonists lack a certain polish... They aren't glossy enough, and don't have the necessary price tag to attract the reader.
But I'll keep trying!
The 12" screen will suck the battery life out of it very quickly. For the resolution they mentioned, I actually think that the screen is too big. Something around 10" would be easier to carry around, because as it is, it seems like a rather large thing to carry around except indoors (which, I realize, is currently what it's being marketed for).
Also, he's right about the netbook aspect at least in the sense that a netbook is a feally-featured computer. This will only give you a buffed up browser, and you're going to need to depend on their software for all of the UI and functionality. In this respect, a netbook will indeed "cream" a device like this. It's far more versatile.
To me, this looks far from an iPhone with a big screen. At least in this demo the hardware seemed unresponsive, sluggish, and several attempts had to be made to get a gesture to work properly. And it was being used by someone who was already used to the device. Notice how much trouble he was having just exiting full-screen mode in YouTube, which was displaying a video that was clearly choppy (Flash uses no hardware acceleration for video).
Having said that, if they *did* manage to get the production model to a semi-usable state, enabling users to "theme" the keyboard will be important. At the very least, they'll need to give several keyboard layout options.
If all I had to go by is the demo video linked here, I'd say they're not even close to a marketable product. Which is a shame, because the overall idea is nice.
"Take a mountain turn it into a mole"
How appropriate, then, that the one thing they *do* oversee in-house is the manufacturing processes for the *cases*. They've invested quite a bit in manufacturing process development and patenting, resulting in things like the "Unibody" laptops and those highly-resilient aluminum coating materials.
So many of their customers, after all, "judge a notebook by its cover"...
Speaking of additional factors to throw into the mix:
While there's something to be said for knowing the exact hardware that your software will be running on, most reviews will comment on the very well-designed power management in Windows. In fact this is something that, from what I understand, is continually being patched through windows update. So there's a good chance that the laptop you bought 2 years ago, with the same version of windows, has a *longer* battery life, on average, than when you originally bought it. Honestly, if this information came *from* MS, I wouldn't believe them, but I've run into this particular power management anecdote in enough different articles that I tend to believe there's some truth to it.
This isn't to contradict the claim that Apple may be "lying less", but I think it's a consideration.