Depending on the lease terms, you may simply get replacement equipment once your current is obsolete (e.g. workstation is a couple revs out of date).
Tax benefits can be dramatic. Speak to your tax accountant / lawyer.
Depreciation of assets can look very bad on a publicly traded company's books. To avoid this, many public companies lease as much as they can.
Often leasing means consolidation. In this day of CDW and the like, that's not as big a benefit, but it used to be huge.
There are probably other advantages I'm not thinking of. Of course, the down side is that you can't just treat the hardware as your own. Your developers (if you have any) will be especially displeased to hear that they're not allowed to just slap in some RAM or a hard-drive they had lying around.
"It's hard to reverse engineer a mind becuase unlike reverse engineering a BIOS or widget, we don't really understand how a mind works,"
I would argue (and I could be proven wrong) that today we have a very general understanding of how a mind works... in that we understand the concept of a neural network which does seem to be a decent model for the basic "mind" which makes choices for us... the problem comes about where we attempt to understand HUMAN BEHAVIOR which is the combination of a mind (neural network) and dozens of auxiliary, special-purpose systems ranging from the neurons in the optic nerve that perform a plethora of pre-processing on the retina's image data to the area in the brain that we're just discovering models our "empathy"; it allows us to re-process visual information about others as if we were experiencing what they are.
These special-purpose systems are sometimes inside the brain (the latter example) somtimes outside (the former), but they are not part of what we traditionally expect consciousness to be.
These tools make many of the tasks that we expect AIs to perform nearly impossible. For example, facial recognition seems like it should be easy, but once you sit down with a camera and try to make the computer "see" differences, you find that faces all look very much alike. We are tricked -- by a shockingly sophisticated facial recognition pre-filter in our brain -- into thinking that faces are widely distinct, but they are not (the old "all [race] look alike," is actually true... for all values of [race]).
So, while we might look at an AI and say, "unless it can tell faces apart, it's not 'smart'," it turns out that that's actually a pretty poor measure of pure intelligence.
Other aspects of our instinctive measures of intelligence such as language, managemetn of a human body (e.g. walking), etc. all have one or more of these auxiliary systems at their heart.
So we really have two problems: create a machine that can think; and create a machine that can behave like a human.
The former is either within our grasp, or already possible. The latter is going to have to be the product of an enourmous reverse-engineering effort which has probably only just begun.
You're being abusive. This will be my last attempt to communicate with you in this thread. Clearly, you're not interested in the topic so much as... actually, I'm not clear what it is that you're trying to accomplish.
"You don't know what you're talking about."
Last refuge....
"Functional languages are *easier* to optimize, not harder."
You're confusing terms here.
First off, you're obviously correct. A purely functional language is much easier to optimize than a non-functional language.
Of course.
Now please go back and read what I wrote. I was speaking of the end result: execution time (presumably on modern hardware). I'm going to repeat myself at the end of this message for the third and final time. If you still have trouble understanding the difference between what you're saying and what I'm saying, then I'm afraid I can't help you.
It's very easy to perform many sorts of near-optimal transformations on a functional program, and while there's deminishing returns here, there are in ALL programming languages (perfect transformation of a grammar into its optimal form, is of course, known to be a hard problem, but that's not dependant on the language in question).
Now we get into that ugly bit: when you take your code and plunk it down on modern hardware, you find that your program performs poorly! This is because modern hardware is fundamentally NOT functional in nature. In fact, it's quite assertively operational!
So now you have to take your near-perfectly optimized functional specification for a program and transform it into an operational instruction set. There are, of course, many ways to do this, and it turns out that finding the optimal one is actually much harder than having performed simple functional transformations on your code in the first place.
There are other reasons that MOST functional programming languages cannot reasonably be optimized down to code that out-performs, say C, but they're all a matter of choosing to be a high-level language, and other high-level languages suffer the same problems regardless of how functional or procedural / operational (e.g. in a language with dynamic types).
There, I've repeated myself. I hope this helps.
If you consider anything in this message to be other than well-established fact at this point, then please provide a compiler which compiles ANY functional language down to machine code such that compile time plus execution time is less than or equal to that for the equivalent C program and gcc with normal (-O2) optimization.
If you're still confused as to how any of this could be possible, sit down and write a translator between your favorite functional language and C. That should explain a lot.
I see newspapers that lead with "LIAR!!!" and "HE SHOULD BE ASHAMED!" (Boston Herald is my example here, though there are many more examples around the nation).
I see bloggers that lead with stories of equally low journalistic standards.
Yep, looks like the bloggers have really stepped up and brought their standards of publication in line with the mainstream. Bravo guys!
"I've been following Ruby for a while and practically no-one in the community has any interest in Parrot let alone CPAN."
Well, you're looking at it from one point of view. The Ruby-on-Parrot effort is quite strong, and while it does await finial Parrot semantics for some basics Ruby needs, there's already a primative parser in the Parrot source tree, contributed by Ruby developers.
I think you're confusing BUZZ with INTEREST. Parrot development doesn't generate much buzz because it can't be used for anything real-world yet. That is changing rather quickly these days, as Pugs pushes forward finalization of many Parrot features.
As for CPAN... I don't expect anyone's sitting around saying, "oh, I'll just put off everything until I have access to CPAN," but there's no denying that transparent access to the world's largest source code programming moudule repostitory wouldn't hurt Ruby at all!
" Let me know more about those mysterious purely functional languages that can't be optimized."
You'll have to tell me, since I'm unaware of any such mysteries, and I never said that purely functional langauges can't be optimized. I didn't even say that they can't be optimized to at least match the performance on non-functional languages. What I did say was that you could not do so practically (i.e. the compute resources required are disproportionate to non-purely-functional languages by orders of magnitude).
This is something that those of use who LIKE functional programming languages have been aware of for decades. I don't know why it's a shock to you.
Flash has a number of excellent features, which will continue to be a useful and valuable thing until SVG integration into mainstream browsers is complete.
Vector drawing is one of those things that sounds like a useless add-on until you consider how much time and disk cash you devote to every two-bit logo you see every day. If logos were all vector graphics, they'd be far smaller, far better looking on whatever display type you happen to have (because YOU get to choose how the rendering is optimized for that device) and generally much more usable.
Woefully, this isn't why people use Flash. People use Flash because they want to ANIMATE, and animation is rarely a boon for the end-user.
Even worse, it's often used to hijack the look and feel of your browser, imposing some horrid DVD-like menu system that you have to re-learn to interact with (and have no hope if you're disabled).
It's not an uphill battle to track visitors. You can track a visitor just fine. You can even track them from business transaction to business transaction just fine.
What advertisers are having a hard time doing is tracking visitors across sites or across casual visits to the same site, and I'm THRILLED by that. Hey, I know it makes their business harder and less cost effective, but that's not really my problem. Let the Web business model collapse a bit more. I think it's healthy.
Oh, and using Flash won't help. Most people are getting wise to Flash and are installing features like the Firefox plugin that requires you to click on an icon in order to activate a flash component (should you want to). I consider Flash dangerous, and I don't execute dangerous code unless I REALLY trust the place I'm getting it.
"A laguage, in of itself, cannot be measured by speed."
Not so.
There are purely functional languages that are -- for all practical purposes -- impossible to optimize as well as either procedural or hybrid procedural/functional languages.
However, that's beside the point. Java in particular is NOT just a language. Java is a specification for a fair amount of the IMPLEMENTATION as well. Java specifies the behavior of GC, type storage, and many other implementation details ot a level that precludes many hardware or OS specific optimizations.
There are non-conforming compilers that ignore these strictures (and get excellent performance), but they are not -- strictly speaking -- compiling Java.
Languages like Ruby, Python, Perl and PHP on the other hand, make no such strict demands, and thus can be optimized appropriately for the platform.
When we say "optimized bytecode compiler" these days, we generally mean that it does JIT. I know, I know, it's bad use of the terminology, but generally that's what people mean.
Ruby has one other massive advantage over Java on the medium-term horizon: Parrot. The Ruby-on-Parrot effort is progressing nicely, and when that is complete, Ponie will give Ruby transparent access to all of CPAN (thought yet another JITted bytecode system) even for those who don't like or can't use Perl.
At that point, Ruby becomes (IMHO) the most attractive HLL in existance (until Perl 6 lands... IF Perl 6 lands...)
Nice stuff. Glad to see my assumptions about the Python community not accepting change were unfounded.
I'm constantly (and pleasantly) surprised by the communities that support Python, Perl, Ruby, Pike and the like. These languages continue to evolve, take advantage the surroundings and generally make life easier for their user baes. Even PHP continues to grow.
"Often you don't care what kind of object something is so long as it has some certain method. To put it in a practical way I work with zope which is a python based app server which has an object database as part of it. Often I will run queries and get objects back. Most of the time I don't care if it is a file, picture, dtml document, or any of the many other types in the db all I care is that it has an id and it is willing to draw its url."
This is a reasonable thing to do in any language that handles typing through something like an interface. For example, in Perl 6:
sub display_as_uri($data does locatable) {
return $data.uri; } # And here's a sample declaration of locatable assuming a URI package like Perl 5's: role locatable {
method uri() returns URI {...} } # And an example class that uses this: class myimage does locatable {
method uri($image:) returns URI::URL {
my URI::URL $u = "http://{.myhost}{.imagepath}";
} } # And so.... print display_as_url( myimage.new("flower.jpg") );
Here we recieve $data as a generic "Any" datatype, but we make certain assertions about its type: it must provide the identifiable and loctables "roles". It might be an image or a description of a hardware order... you don't care. You just want to verify that it can do what you asked it to do at compile time (well, compile time is a tricky thing in Perl 5, but close enough).
You can do this with nothing but generic typing, but you lose the ability to make assertions about the capabilities you will be relying on.
Python could easily do the same thing, but I suspect it would be too radical a change. I know that the changes in Perl 6 have already polarized the Perl community strongly, and we've always been a "you can have it your way" kind of bunch... Python tends to attract people with a strong sense that there is a right and a wrong way to do just about anything, so convincing them that a new way has value would seem... challenging.
Still, this is not unique to Perl 6, and I think this kind of genric typing coupled with interface assertions is going to become a difficult feature to live without.
Well, to be fair, TCL had a fairly decent model for getting speed out of a string-re-evaluation language. Of course, it was also one of the world's most painful languages to program in....
I wrote a few largish things (all pieces of much larger things) in TCL. It was fun, but frustrating to debug, and annoying trying to keep levels of re-evaluation straight at times.
Back to Python: work continues on Parrot-based Python which provides a very nice JIT compiler, and has demonstrated some execellent speed returns. Of course, it's all fairly early, but given the existance of Pugs on the Perl 6 side pushing Parrot development into overdrive, I expect to see a real-world-useable Parrot fairly soon.
Ruby is also a nice choice if you're looking for a bit more performance in your HLL.
"your choices are not limited to Walmart and Kmart."
The Indian-familiy-run convinience store down the street has video surveilence. Same for the supermarket, local PC hardware store, hobby shop, comic shop, asian food store, hardware store... just where was it you were suggesting I shop?
Article pointed to is from the 30th, two days ago, so it's not A.F. fodder.
Re:56 april fools in one day
on
EU to Ban Macs
·
· Score: 2, Interesting
Imagine bothering to complain about what Slashdot has been doing on April fools for the last... what, 6 years? 7? You know it's coming. You know that this site does not and has never taken itself that seriously.
Hell, I'm off to sign up as a subscriber. This is some of the best stuff Slashdot has put together!
That bit on unrolling the idle loop had me gasping for air!
The CIA suffered from "group-think" (that strange affliction that makes them mislead the president into doing exactly what he was going to do anyway), and now Slashdot's suffering from "geek think".
I did read it. That's why I refered to the various tie-in agreements and such in my OP. It sounds like a very normal PC piece. If it's an April Fools, then they forgot the first rule of April Fools structure: start with the believable, and keep moving people further and further into a fantasy. The quality of an April Fools is judged on the basis of pulling someone all the way over into fantasy so baroque that they'll smack themselves for buying it, but managing to keep them with you right up until you deliver the punch-line. If you never deliver the punch-line, then it's just generic fiction.
"Note to staff: The thing about April 1st jokes is that they should be subtle enough to catch the reader unawares."
Note to Slashdot readers new to the concept (your UID says one thing, your post says another): Slashdot is a Web Log in the original sense (not the modern "I wanna type where everybody knows my name" sense), and as a result they report on the goings on of the day on the Net. If you have a problem with the idea that people are putting up lame-ass April fools jokes today -- and so that's what there is to "log" on Slashdot -- then go create something wonderfully inventive on April 1 next year!
"I don't think we need any more TLDs. Especially since silly TLDs like.museum and.aero are created which are either too long, or aren't restricted in use to just museums and aerospace companies."
You're restricting yourself to a view that has no technical value, and ultimately, almost no social value.
Top level domains are meaningless. Secondary level domains are meaningless.
They are keys into a database which is distributed around the world, and nothing more. The primary reason that we use them is that most humans can remember a string of phoneme-representing-glyphs much more easily than a string of numbers.
It's all nice and vanity-platish for IBM to own ibm.com, but there's no real value there. People who need to know IBM's domain name would find it even if it were example.mil.
DNS isn't a context-sensitive search engine, and as soon as people get over thinking of it that way, we'll all be quite a lot better off. In fact, I'd be happy if you were NOT allowed to own the name of your company as a domain name... it would force some thought behind the trade-offs involved (like the likelyhood that your really long domain name can actually be transcribed off of a business card without error).
Ahem... not that this is Slashdot or anything, but can we be a tad more specific here than "System:PC"? I presume this is a Windows-only game, but since I don't know that, and there are actually some fine Linux/Windows hybrid games out there (I play NWN under Linux for example), it would be nice if you could cite hardware platform AND OS supported in a review.
"
95 per cent of information technology groups "are not delivering some number of projects on time or to the full satisfaction of the business executive.""
Could it be that marketing is always overselling the product?
Why is everyone responding as if this were about software companies delivering product to external entities? First off, the article cites "IT groups" and "IT descision makers".
Ok, so that said, here is why it happens: IT departments in most large companies are operating in a grey area between development and infrastructure administration. When you ask someone to make sure the bathroom works tomorrow, they usually make the deadline because there is a known path between where you are (broken bathroom) and where you want to be (working bathroom). When you ask someone to build you a new building with a fancy new biohazard containment system that the CDC just approved, you are assured that many issues that arrise will not have been encountered before by the people involved, and therefore will not be part of your timeline.
It's all about the number of unknown variables involved in the plan, and gets really sticky when the number of unknowns is, itself, unknown.
Even being conservative in the face of such developments, you may, more often than not, discover that you were wrong or that you're not satisfied with the result. Welcome to being a developer. We live with this our entire career, and it pisses US off too.
Slashdot Mirror
- Depending on the lease terms, you may simply get replacement equipment once your current is obsolete (e.g. workstation is a couple revs out of date).
- Tax benefits can be dramatic. Speak to your tax accountant / lawyer.
- Depreciation of assets can look very bad on a publicly traded company's books. To avoid this, many public companies lease as much as they can.
- Often leasing means consolidation. In this day of CDW and the like, that's not as big a benefit, but it used to be huge.
There are probably other advantages I'm not thinking of. Of course, the down side is that you can't just treat the hardware as your own. Your developers (if you have any) will be especially displeased to hear that they're not allowed to just slap in some RAM or a hard-drive they had lying around."It's hard to reverse engineer a mind becuase unlike reverse engineering a BIOS or widget, we don't really understand how a mind works,"
I would argue (and I could be proven wrong) that today we have a very general understanding of how a mind works... in that we understand the concept of a neural network which does seem to be a decent model for the basic "mind" which makes choices for us... the problem comes about where we attempt to understand HUMAN BEHAVIOR which is the combination of a mind (neural network) and dozens of auxiliary, special-purpose systems ranging from the neurons in the optic nerve that perform a plethora of pre-processing on the retina's image data to the area in the brain that we're just discovering models our "empathy"; it allows us to re-process visual information about others as if we were experiencing what they are.
These special-purpose systems are sometimes inside the brain (the latter example) somtimes outside (the former), but they are not part of what we traditionally expect consciousness to be.
These tools make many of the tasks that we expect AIs to perform nearly impossible. For example, facial recognition seems like it should be easy, but once you sit down with a camera and try to make the computer "see" differences, you find that faces all look very much alike. We are tricked -- by a shockingly sophisticated facial recognition pre-filter in our brain -- into thinking that faces are widely distinct, but they are not (the old "all [race] look alike," is actually true... for all values of [race]).
So, while we might look at an AI and say, "unless it can tell faces apart, it's not 'smart'," it turns out that that's actually a pretty poor measure of pure intelligence.
Other aspects of our instinctive measures of intelligence such as language, managemetn of a human body (e.g. walking), etc. all have one or more of these auxiliary systems at their heart.
So we really have two problems: create a machine that can think; and create a machine that can behave like a human.
The former is either within our grasp, or already possible. The latter is going to have to be the product of an enourmous reverse-engineering effort which has probably only just begun.
"What a bunch of crap."
... actually, I'm not clear what it is that you're trying to accomplish.
You're being abusive. This will be my last attempt to communicate with you in this thread. Clearly, you're not interested in the topic so much as
"You don't know what you're talking about."
Last refuge....
"Functional languages are *easier* to optimize, not harder."
You're confusing terms here.
First off, you're obviously correct. A purely functional language is much easier to optimize than a non-functional language.
Of course.
Now please go back and read what I wrote. I was speaking of the end result: execution time (presumably on modern hardware). I'm going to repeat myself at the end of this message for the third and final time. If you still have trouble understanding the difference between what you're saying and what I'm saying, then I'm afraid I can't help you.
It's very easy to perform many sorts of near-optimal transformations on a functional program, and while there's deminishing returns here, there are in ALL programming languages (perfect transformation of a grammar into its optimal form, is of course, known to be a hard problem, but that's not dependant on the language in question).
Now we get into that ugly bit: when you take your code and plunk it down on modern hardware, you find that your program performs poorly! This is because modern hardware is fundamentally NOT functional in nature. In fact, it's quite assertively operational!
So now you have to take your near-perfectly optimized functional specification for a program and transform it into an operational instruction set. There are, of course, many ways to do this, and it turns out that finding the optimal one is actually much harder than having performed simple functional transformations on your code in the first place.
There are other reasons that MOST functional programming languages cannot reasonably be optimized down to code that out-performs, say C, but they're all a matter of choosing to be a high-level language, and other high-level languages suffer the same problems regardless of how functional or procedural / operational (e.g. in a language with dynamic types).
There, I've repeated myself. I hope this helps.
If you consider anything in this message to be other than well-established fact at this point, then please provide a compiler which compiles ANY functional language down to machine code such that compile time plus execution time is less than or equal to that for the equivalent C program and gcc with normal (-O2) optimization.
If you're still confused as to how any of this could be possible, sit down and write a translator between your favorite functional language and C. That should explain a lot.
Ethical standards.... hmmm.
I see newspapers that lead with "LIAR!!!" and "HE SHOULD BE ASHAMED!" (Boston Herald is my example here, though there are many more examples around the nation).
I see bloggers that lead with stories of equally low journalistic standards.
Yep, looks like the bloggers have really stepped up and brought their standards of publication in line with the mainstream. Bravo guys!
"I've been following Ruby for a while and practically no-one in the community has any interest in Parrot let alone CPAN."
Well, you're looking at it from one point of view. The Ruby-on-Parrot effort is quite strong, and while it does await finial Parrot semantics for some basics Ruby needs, there's already a primative parser in the Parrot source tree, contributed by Ruby developers.
I think you're confusing BUZZ with INTEREST. Parrot development doesn't generate much buzz because it can't be used for anything real-world yet. That is changing rather quickly these days, as Pugs pushes forward finalization of many Parrot features.
As for CPAN... I don't expect anyone's sitting around saying, "oh, I'll just put off everything until I have access to CPAN," but there's no denying that transparent access to the world's largest source code programming moudule repostitory wouldn't hurt Ruby at all!
" Let me know more about those mysterious purely functional languages that can't be optimized."
You'll have to tell me, since I'm unaware of any such mysteries, and I never said that purely functional langauges can't be optimized. I didn't even say that they can't be optimized to at least match the performance on non-functional languages. What I did say was that you could not do so practically (i.e. the compute resources required are disproportionate to non-purely-functional languages by orders of magnitude).
This is something that those of use who LIKE functional programming languages have been aware of for decades. I don't know why it's a shock to you.
Flash has a number of excellent features, which will continue to be a useful and valuable thing until SVG integration into mainstream browsers is complete.
Vector drawing is one of those things that sounds like a useless add-on until you consider how much time and disk cash you devote to every two-bit logo you see every day. If logos were all vector graphics, they'd be far smaller, far better looking on whatever display type you happen to have (because YOU get to choose how the rendering is optimized for that device) and generally much more usable.
Woefully, this isn't why people use Flash. People use Flash because they want to ANIMATE, and animation is rarely a boon for the end-user.
Even worse, it's often used to hijack the look and feel of your browser, imposing some horrid DVD-like menu system that you have to re-learn to interact with (and have no hope if you're disabled).
It's not an uphill battle to track visitors. You can track a visitor just fine. You can even track them from business transaction to business transaction just fine.
What advertisers are having a hard time doing is tracking visitors across sites or across casual visits to the same site, and I'm THRILLED by that. Hey, I know it makes their business harder and less cost effective, but that's not really my problem. Let the Web business model collapse a bit more. I think it's healthy.
Oh, and using Flash won't help. Most people are getting wise to Flash and are installing features like the Firefox plugin that requires you to click on an icon in order to activate a flash component (should you want to). I consider Flash dangerous, and I don't execute dangerous code unless I REALLY trust the place I'm getting it.
"A laguage, in of itself, cannot be measured by speed."
Not so.
There are purely functional languages that are -- for all practical purposes -- impossible to optimize as well as either procedural or hybrid procedural/functional languages.
However, that's beside the point. Java in particular is NOT just a language. Java is a specification for a fair amount of the IMPLEMENTATION as well. Java specifies the behavior of GC, type storage, and many other implementation details ot a level that precludes many hardware or OS specific optimizations.
There are non-conforming compilers that ignore these strictures (and get excellent performance), but they are not -- strictly speaking -- compiling Java.
Languages like Ruby, Python, Perl and PHP on the other hand, make no such strict demands, and thus can be optimized appropriately for the platform.
When we say "optimized bytecode compiler" these days, we generally mean that it does JIT. I know, I know, it's bad use of the terminology, but generally that's what people mean.
Ruby has one other massive advantage over Java on the medium-term horizon: Parrot. The Ruby-on-Parrot effort is progressing nicely, and when that is complete, Ponie will give Ruby transparent access to all of CPAN (thought yet another JITted bytecode system) even for those who don't like or can't use Perl.
At that point, Ruby becomes (IMHO) the most attractive HLL in existance (until Perl 6 lands... IF Perl 6 lands...)
Nice stuff. Glad to see my assumptions about the Python community not accepting change were unfounded.
I'm constantly (and pleasantly) surprised by the communities that support Python, Perl, Ruby, Pike and the like. These languages continue to evolve, take advantage the surroundings and generally make life easier for their user baes. Even PHP continues to grow.
It's a good time to be someone who enjoys coding.
This is a reasonable thing to do in any language that handles typing through something like an interface. For example, in Perl 6:Here we recieve $data as a generic "Any" datatype, but we make certain assertions about its type: it must provide the identifiable and loctables "roles". It might be an image or a description of a hardware order... you don't care. You just want to verify that it can do what you asked it to do at compile time (well, compile time is a tricky thing in Perl 5, but close enough).
You can do this with nothing but generic typing, but you lose the ability to make assertions about the capabilities you will be relying on.
Python could easily do the same thing, but I suspect it would be too radical a change. I know that the changes in Perl 6 have already polarized the Perl community strongly, and we've always been a "you can have it your way" kind of bunch... Python tends to attract people with a strong sense that there is a right and a wrong way to do just about anything, so convincing them that a new way has value would seem... challenging.
Still, this is not unique to Perl 6, and I think this kind of genric typing coupled with interface assertions is going to become a difficult feature to live without.
Well, to be fair, TCL had a fairly decent model for getting speed out of a string-re-evaluation language. Of course, it was also one of the world's most painful languages to program in....
I wrote a few largish things (all pieces of much larger things) in TCL. It was fun, but frustrating to debug, and annoying trying to keep levels of re-evaluation straight at times.
Back to Python: work continues on Parrot-based Python which provides a very nice JIT compiler, and has demonstrated some execellent speed returns. Of course, it's all fairly early, but given the existance of Pugs on the Perl 6 side pushing Parrot development into overdrive, I expect to see a real-world-useable Parrot fairly soon.
Ruby is also a nice choice if you're looking for a bit more performance in your HLL.
"your choices are not limited to Walmart and Kmart."
The Indian-familiy-run convinience store down the street has video surveilence. Same for the supermarket, local PC hardware store, hobby shop, comic shop, asian food store, hardware store... just where was it you were suggesting I shop?
Article pointed to is from the 30th, two days ago, so it's not A.F. fodder.
Imagine bothering to complain about what Slashdot has been doing on April fools for the last... what, 6 years? 7? You know it's coming. You know that this site does not and has never taken itself that seriously.
Hell, I'm off to sign up as a subscriber. This is some of the best stuff Slashdot has put together!
That bit on unrolling the idle loop had me gasping for air!
The CIA suffered from "group-think" (that strange affliction that makes them mislead the president into doing exactly what he was going to do anyway), and now Slashdot's suffering from "geek think".
Just think.
I did read it. That's why I refered to the various tie-in agreements and such in my OP. It sounds like a very normal PC piece. If it's an April Fools, then they forgot the first rule of April Fools structure: start with the believable, and keep moving people further and further into a fantasy. The quality of an April Fools is judged on the basis of pulling someone all the way over into fantasy so baroque that they'll smack themselves for buying it, but managing to keep them with you right up until you deliver the punch-line. If you never deliver the punch-line, then it's just generic fiction.
"Note to staff: The thing about April 1st jokes is that they should be subtle enough to catch the reader unawares."
Note to Slashdot readers new to the concept (your UID says one thing, your post says another): Slashdot is a Web Log in the original sense (not the modern "I wanna type where everybody knows my name" sense), and as a result they report on the goings on of the day on the Net. If you have a problem with the idea that people are putting up lame-ass April fools jokes today -- and so that's what there is to "log" on Slashdot -- then go create something wonderfully inventive on April 1 next year!
Is it a joke? I have to say, I dismissed the Gmail announcement last year as a joke for the same reasons, but clearly I was wrong.
The article seems reasonable enough, and mentions many of the sorts of tie-ins that I might expect.
"I look forward to a salesman knocking on my door and selling me a 6 foot wide stack of Wikipedia volumes to fill my shelves."
;-)
Based on the picture, I think that would be "kicking in your door"
It just never gets old
"I don't think we need any more TLDs. Especially since silly TLDs like .museum and .aero are created which are either too long, or aren't restricted in use to just museums and aerospace companies."
You're restricting yourself to a view that has no technical value, and ultimately, almost no social value.
Top level domains are meaningless. Secondary level domains are meaningless.
They are keys into a database which is distributed around the world, and nothing more. The primary reason that we use them is that most humans can remember a string of phoneme-representing-glyphs much more easily than a string of numbers.
It's all nice and vanity-platish for IBM to own ibm.com, but there's no real value there. People who need to know IBM's domain name would find it even if it were example.mil.
DNS isn't a context-sensitive search engine, and as soon as people get over thinking of it that way, we'll all be quite a lot better off. In fact, I'd be happy if you were NOT allowed to own the name of your company as a domain name... it would force some thought behind the trade-offs involved (like the likelyhood that your really long domain name can actually be transcribed off of a business card without error).
Ahem... not that this is Slashdot or anything, but can we be a tad more specific here than "System:PC"? I presume this is a Windows-only game, but since I don't know that, and there are actually some fine Linux/Windows hybrid games out there (I play NWN under Linux for example), it would be nice if you could cite hardware platform AND OS supported in a review.
Ok, so that said, here is why it happens: IT departments in most large companies are operating in a grey area between development and infrastructure administration. When you ask someone to make sure the bathroom works tomorrow, they usually make the deadline because there is a known path between where you are (broken bathroom) and where you want to be (working bathroom). When you ask someone to build you a new building with a fancy new biohazard containment system that the CDC just approved, you are assured that many issues that arrise will not have been encountered before by the people involved, and therefore will not be part of your timeline.
It's all about the number of unknown variables involved in the plan, and gets really sticky when the number of unknowns is, itself, unknown.
Even being conservative in the face of such developments, you may, more often than not, discover that you were wrong or that you're not satisfied with the result. Welcome to being a developer. We live with this our entire career, and it pisses US off too.