no other device can you paint with as well as the iPhone/iPod Touch
You should've conditioned that statement with something like "at that price point" or "of that size". As it is, I can simply say: a Tablet PC has better resolution, accuracy, software, and likely will not destroy your eyes when you use it to paint on the fly.
I tried using Goggles to prevent me from sending embarrassing E-mails when I'm drunk. The problem is that when I'm inebriated, I'm actually better at math...
How many of these articles are going to keep making it on/.? Last time the iPhone was used to make the cover art of some magazine, which was of course comparable to the moon landing.
I know that this sounds like trolling, and by some definitions it may be, but I think that even an objective reader (someone who *isn't* sick of hearing how the iPhone cured cancer) would find this particular "article" incredibly pandering.
If I were *looking* for hype and gimmicks, there's always digg.
If you're using Eclipse for Perl/PHP/Python and web standards (X/HTML/Javascript/CSS), then you may want to check out Komodo Edit.
For Java, it's hard to beat Eclipse, but for the other things you mentioned Eclipse is a bit heavy, IMO. Needless to say, if you have everything integrated into Eclipse so that you can do Java and the other languages, then you're probably better off with just one IDE. However I find Komodo very useful for dynamic languages as well as web standards.
I can't believe I'm pissed enough to post the following and likely launch myself to karma hell, but I am:
*I* modded that up. Look at the comment from the same poster linking to the message pad. This is nothing but hype, and the worse kind of it. The link to the tablet PC is a single-glance response to the entire thread.
Crap like "Before, unless I had a flashlight or a miner's hat, I could not draw in the dark." and "Colombo leans heavily on the Undo feature". OMFG! Apple brought us light! And the UNDO feature! The cover being created using an iPhone was a gimmick, the article about it was pandering, and the link from/. is simply embarrassing. There's no mod option for "+1 correct response to the entire thread".
Earlier today I was shot and the bullet hit the iPhone. The iPhone saved my life! It's a miracle! It was also hooked up to a speaker in an OR where a surgeon implanted a kidney. It's a surgical instrument! I often use the iPhone to shield my skin from harmful sunlight, to eat dinner off of, and to wipe my ass. It's my new GOD.
What pisses me off most is that this type of crap gets linked from/., somewhere I visit in hope to find hype and fraud rebuked. And then I find these types of "articles".
And of course by saying this I'm obviously a biased "hater". Fine by me.
Nobody saw this and think "external HD + bittorrent"? Just leave it on for as long as you like. I'm always looking for ways to offload background tasks to lower-power devices, and the best I can do for P2P right now is a laptop with a USB HD. It's low power, but if I didn't have a spare old laptop then the next-cheapest thing would be a netbook, which I'd probably want to use as, well, a netbook...
Google is leveraging economy of scale with their cargo containers. The primary benefits are modularity, and off-the-shelf components/interfaces.
However if you look at power usage and usage of space (which also translates into power, because of infrastructure costs), if you need "shallow web servers", then paralleling even "weaker" nodes could yield a better bottom line.
Blade computing, specifically, is extremely expensive. The reason is simply that you're buying high-end components which are intended for customers with cash reserves. What Google does is use CPUs/Motherboards/RAM/PSUs that are already on thin margins and massive distribution to a far broader audience. They've created their own modular, near-blade density model, which is far cheaper, and more robust (even if it does take up more space).
The project's site is located here. There's quite a bit of information there (check out the first PDF at the bottom of the page).
nVidia's CUDA would have a drastically different method for paralleling, as well as a fundamentally different instruction set, which I assume is more appropriate for heavy computation. The cores are on the same die, for one thing, and I'm willing to bet it's easier to program out of the box. Of course, I'm just inferring, I've never worked with the architecture.
I'm not entirely sure whether you were referring to the CNC analogy or an actual machine shop, so I'll assume both:
Analogy: You're always going to have exceptions, but if you can quickly re-task servers then there's no reason for them to sit still any of the time, unless you can't manage to find clients for your resource.
Literally a machine shop: I worked on a few projects involving automation and software/hardware interfaces, most of which required on-site installation. I don't know much about actually running such a place, and/or the economics involved, but I did catch one recurring pattern: an idle machine is money down the drain. The more expensive the machine, the more tight the schedule was, and the more "alerts" went off when it was not in use. I literally heard machinists complaining "but it's just sitting there!". I should mention that none of these were product lines, they were all general-purpose, multi-client shops that did custom orders. A mass-production line with one purpose would obviously be a different case.
Well, it's less broken if you consider that in major metropolitan areas
It's less broken?
Listen here: either it works, or it's broken. There's no grey area here. I'm not going to buy an analogy and have it crap out on me when conditions become a bit sketchy. Reliability is key in this business -- if an analogy has any downtime, I'm liable for it. You might as well buy a car and expect it to...
Regardless of the analogy (they were probably just thinking "dumb it down because we consider the people who read infoworld -- our audience -- to be idiots"), the part about the idling time usually isn't the case. Data centers will often outsource whatever "idle machine time" they have to various institutions, at least if they have any sense. There are many computing tasks that aren't too time sensitive, and research projects can have considerable leeway in terms of when the final computation is done and the numbers need to be inserted into spreadsheets or whatever.
If there's low traffic during the weekend, get the machines to crunch data for some other purpose, otherwise they're not paying for themselves.
Possibly a better analogy for this would be "machine time scheduling" in a machine shop. You don't let the $200k CNC milling machine just sit there and take up space -- it cost too much. Find *something* for it to do.
By the way, your sig should say: "Every expression is true, for *any* given value of 'true'", IMHO.
If this was an official/accepted definition, I would completely agree. In fact, if there was a standards committee that offered what you've written above as a proposal, I would back said proposal, if only so we could finally agree on the proper use of the term "branch".
This is not the case, however. Check out github and the terminology they use. If you use that site/service to manage your project, there's effectively no difference between a "fork" and a "branch". This is why I said this was perceptional, because really, it's like you said:
'you might as well call it a "fork" every time you edit a file'
In practice, on a mechanical level, it's exactly the same. This is why different people use "fork" in whatever context they choose.
I agree with your definition, but not everyone does.
Also, there are quite a few reasons why a proper "fork", not a "branch", would be beneficial. You could be leading a project, and one of the developers could decide to try a different approach, to a drastic extent. They would fork the codebase and start developing separately, to the point where there would be no way to merge his code with the main project. This new "subproject" could become a subset of the primary project, designed to deal with specific tasks.
At this point, the new code could remain under the same "roof", or that developer could opt to lead that fork independently. The difference between those two options would be great, but in the end they're both "forks", even by your definition (a new project is created, or "spawned").
In the end we're arguing semantics. I could choose to use your terminology, but I would have to preface what I mean whenever I do, so that people understand that when I say "fork", I specifically mean something that could not be merged back into the main project.
There's a difference between a product that relays "I don't buy crap" and one that screams "Guess what color *my* credit card is??".
It's more than fashion, with many/most of Apple's products. It's the upper, so called "BMW set". It's "Bling". It's almost regarded as jewelry that's 'ok' for a man to walk around with. It goes well with a Rolex. And yes, many people would consider is shameful to buy a watch with diamonds embedded in it.
Just once? I usually get modded "funny" when I'm serious, and "informative" when I'm joking.
Most/. mods are very bored individuals. It gives them something to do. They're not like us, the/. posters, who are intelligent, thoughtful, handsome, and socially adept.
Suppose this process gradually resolves itself, in any direction. So what happens to documentation in the meantime? What happens to educational institutions and anyone who wants to learn what is generally perceived to be the number one open source DB?
This isn't an end-user software project, where "mere mortals" can try every flavor and choose whichever fits their tastes. The newly initiated will want guidance and someone to point a finger at a URL, at which they would hopefully find a big "Download Here" button and a slew of pretty PDFs they can go through, as well as references to where they should look if they want to know more, like book titles, and courses.
This isn't going to benefit the project. It seems to me that the longer this takes, the more damage will be done.
1) Internally, anyone who's working on the project and wants to fork it in order to make disruptive changes, can do so in a "bubble" so that it doesn't effect the main branch. Yeah, I know that many people don't really consider that "a Fork", but rather a "Branch". In practice, however, there's very little difference. It's just perceptional.
2) It's a penalty that can be 'exacted' in case the overseeing developers/organization (see this story) have become detrimental to the project.
I suppose you can look at the first type of forking as beneficial and healthy (even as a type of internal natural selection process), while looking at the second one as the punishment that would befall "wrongdoers to the project".
Off the top of my head, though, two successful forks: Webkit and Inkscape.
(and I'm sure there are other beneficial uses of forks, I was referring to the primary types -- and again, only from my experience)
Slashdot Mirror
no other device can you paint with as well as the iPhone/iPod Touch
You should've conditioned that statement with something like "at that price point" or "of that size". As it is, I can simply say: a Tablet PC has better resolution, accuracy, software, and likely will not destroy your eyes when you use it to paint on the fly.
I tried using Goggles to prevent me from sending embarrassing E-mails when I'm drunk. The problem is that when I'm inebriated, I'm actually better at math...
I couldn't find iEyes in the app store. How much is it?
Serving as a phone is 17th on the list of iPhone features. Right after "Peggle".
How many of these articles are going to keep making it on /.?
Last time the iPhone was used to make the cover art of some magazine, which was of course comparable to the moon landing.
I know that this sounds like trolling, and by some definitions it may be, but I think that even an objective reader (someone who *isn't* sick of hearing how the iPhone cured cancer) would find this particular "article" incredibly pandering.
If I were *looking* for hype and gimmicks, there's always digg.
If you're using Eclipse for Perl/PHP/Python and web standards (X/HTML/Javascript/CSS), then you may want to check out Komodo Edit.
For Java, it's hard to beat Eclipse, but for the other things you mentioned Eclipse is a bit heavy, IMO. Needless to say, if you have everything integrated into Eclipse so that you can do Java and the other languages, then you're probably better off with just one IDE. However I find Komodo very useful for dynamic languages as well as web standards.
I can't believe I'm pissed enough to post the following and likely launch myself to karma hell, but I am:
*I* modded that up. Look at the comment from the same poster linking to the message pad. This is nothing but hype, and the worse kind of it. The link to the tablet PC is a single-glance response to the entire thread.
Crap like "Before, unless I had a flashlight or a miner's hat, I could not draw in the dark." and "Colombo leans heavily on the Undo feature". OMFG! Apple brought us light! And the UNDO feature! /. is simply embarrassing. There's no mod option for "+1 correct response to the entire thread".
The cover being created using an iPhone was a gimmick, the article about it was pandering, and the link from
Earlier today I was shot and the bullet hit the iPhone. The iPhone saved my life! It's a miracle!
It was also hooked up to a speaker in an OR where a surgeon implanted a kidney. It's a surgical instrument!
I often use the iPhone to shield my skin from harmful sunlight, to eat dinner off of, and to wipe my ass. It's my new GOD.
What pisses me off most is that this type of crap gets linked from /., somewhere I visit in hope to find hype and fraud rebuked. And then I find these types of "articles".
And of course by saying this I'm obviously a biased "hater". Fine by me.
Nobody saw this and think "external HD + bittorrent"? Just leave it on for as long as you like. I'm always looking for ways to offload background tasks to lower-power devices, and the best I can do for P2P right now is a laptop with a USB HD. It's low power, but if I didn't have a spare old laptop then the next-cheapest thing would be a netbook, which I'd probably want to use as, well, a netbook...
Same here -- and for a moment I was *so* happy...
And the truth is that the vast majority of servers spend the vast majority of their time waiting for something to do.
True. This is because of the warm and fluffy economy of ~2 years ago.
I said "often", not "most". And the amount will increase if they want to keep a roof over their heads.
Check out Anandtech's Bench. Specifically, the new Atom 230 and 330.
It simply depends on what your task is.
Google is leveraging economy of scale with their cargo containers. The primary benefits are modularity, and off-the-shelf components/interfaces.
However if you look at power usage and usage of space (which also translates into power, because of infrastructure costs), if you need "shallow web servers", then paralleling even "weaker" nodes could yield a better bottom line.
Blade computing, specifically, is extremely expensive. The reason is simply that you're buying high-end components which are intended for customers with cash reserves. What Google does is use CPUs/Motherboards/RAM/PSUs that are already on thin margins and massive distribution to a far broader audience. They've created their own modular, near-blade density model, which is far cheaper, and more robust (even if it does take up more space).
The project's site is located here. There's quite a bit of information there (check out the first PDF at the bottom of the page).
nVidia's CUDA would have a drastically different method for paralleling, as well as a fundamentally different instruction set, which I assume is more appropriate for heavy computation. The cores are on the same die, for one thing, and I'm willing to bet it's easier to program out of the box. Of course, I'm just inferring, I've never worked with the architecture.
I'm not entirely sure whether you were referring to the CNC analogy or an actual machine shop, so I'll assume both:
Analogy: You're always going to have exceptions, but if you can quickly re-task servers then there's no reason for them to sit still any of the time, unless you can't manage to find clients for your resource.
Literally a machine shop: I worked on a few projects involving automation and software/hardware interfaces, most of which required on-site installation. I don't know much about actually running such a place, and/or the economics involved, but I did catch one recurring pattern: an idle machine is money down the drain. The more expensive the machine, the more tight the schedule was, and the more "alerts" went off when it was not in use. I literally heard machinists complaining "but it's just sitting there!".
I should mention that none of these were product lines, they were all general-purpose, multi-client shops that did custom orders. A mass-production line with one purpose would obviously be a different case.
Well, it's less broken if you consider that in major metropolitan areas
It's less broken?
Listen here: either it works, or it's broken. There's no grey area here. I'm not going to buy an analogy and have it crap out on me when conditions become a bit sketchy. Reliability is key in this business -- if an analogy has any downtime, I'm liable for it. You might as well buy a car and expect it to...
ugh...
Regardless of the analogy (they were probably just thinking "dumb it down because we consider the people who read infoworld -- our audience -- to be idiots"), the part about the idling time usually isn't the case. Data centers will often outsource whatever "idle machine time" they have to various institutions, at least if they have any sense.
There are many computing tasks that aren't too time sensitive, and research projects can have considerable leeway in terms of when the final computation is done and the numbers need to be inserted into spreadsheets or whatever.
If there's low traffic during the weekend, get the machines to crunch data for some other purpose, otherwise they're not paying for themselves.
Possibly a better analogy for this would be "machine time scheduling" in a machine shop. You don't let the $200k CNC milling machine just sit there and take up space -- it cost too much. Find *something* for it to do.
By the way, your sig should say: "Every expression is true, for *any* given value of 'true'", IMHO.
There's also the FAWN project (also on /.)
Cores-per-die is not a valid metric, not with emerging prototypes that could drastically change how web content is served.
If this was an official/accepted definition, I would completely agree. In fact, if there was a standards committee that offered what you've written above as a proposal, I would back said proposal, if only so we could finally agree on the proper use of the term "branch".
This is not the case, however. Check out github and the terminology they use. If you use that site/service to manage your project, there's effectively no difference between a "fork" and a "branch". This is why I said this was perceptional, because really, it's like you said:
'you might as well call it a "fork" every time you edit a file'
In practice, on a mechanical level, it's exactly the same. This is why different people use "fork" in whatever context they choose.
I agree with your definition, but not everyone does.
Also, there are quite a few reasons why a proper "fork", not a "branch", would be beneficial. You could be leading a project, and one of the developers could decide to try a different approach, to a drastic extent. They would fork the codebase and start developing separately, to the point where there would be no way to merge his code with the main project. This new "subproject" could become a subset of the primary project, designed to deal with specific tasks.
At this point, the new code could remain under the same "roof", or that developer could opt to lead that fork independently. The difference between those two options would be great, but in the end they're both "forks", even by your definition (a new project is created, or "spawned").
In the end we're arguing semantics. I could choose to use your terminology, but I would have to preface what I mean whenever I do, so that people understand that when I say "fork", I specifically mean something that could not be merged back into the main project.
There's a difference between a product that relays "I don't buy crap" and one that screams "Guess what color *my* credit card is??".
It's more than fashion, with many/most of Apple's products. It's the upper, so called "BMW set". It's "Bling". It's almost regarded as jewelry that's 'ok' for a man to walk around with. It goes well with a Rolex.
And yes, many people would consider is shameful to buy a watch with diamonds embedded in it.
When the zombies take over this will be academic.
I propose we replace the 'M' with an 'R'.
In soviet Russia, the project forks YOU!
Just once? I usually get modded "funny" when I'm serious, and "informative" when I'm joking.
/. mods are very bored individuals. It gives them something to do. They're not like us, the /. posters, who are intelligent, thoughtful, handsome, and socially adept.
Most
Suppose this process gradually resolves itself, in any direction.
So what happens to documentation in the meantime? What happens to educational institutions and anyone who wants to learn what is generally perceived to be the number one open source DB?
This isn't an end-user software project, where "mere mortals" can try every flavor and choose whichever fits their tastes. The newly initiated will want guidance and someone to point a finger at a URL, at which they would hopefully find a big "Download Here" button and a slew of pretty PDFs they can go through, as well as references to where they should look if they want to know more, like book titles, and courses.
This isn't going to benefit the project. It seems to me that the longer this takes, the more damage will be done.
From my experience, it serves two purposes:
1) Internally, anyone who's working on the project and wants to fork it in order to make disruptive changes, can do so in a "bubble" so that it doesn't effect the main branch. Yeah, I know that many people don't really consider that "a Fork", but rather a "Branch". In practice, however, there's very little difference. It's just perceptional.
2) It's a penalty that can be 'exacted' in case the overseeing developers/organization (see this story) have become detrimental to the project.
I suppose you can look at the first type of forking as beneficial and healthy (even as a type of internal natural selection process), while looking at the second one as the punishment that would befall "wrongdoers to the project".
Off the top of my head, though, two successful forks: Webkit and Inkscape.
(and I'm sure there are other beneficial uses of forks, I was referring to the primary types -- and again, only from my experience)