Slashdot Mirror

Since they didn't test Solaris, the test is meaningless. It's the only OS in existence right now with caching and data management features designed specifically to take advantage of flash to improve real-world performance. The submitter's assertion to the contrary is a deliberate lie, an assumption that until Microsoft does something it hasn't been done, or at best sheer ignorance.

Read up on the ZFS L2ARC and the use of supercap/DRAM/flash subsystems for separate intent logs that make up the hybrid storage pool. There are plenty of white papers and other material out there, and of course you can also read the source code.

The #1 primary thing for myself and most folks is data integrity.

End-to-end checksumming and automatic recovery. It's so huge it just blows by most people.

Most current systems (at least in the mainstream x86/x64 world) have ridiculously high error rates and data corruption rates.

The systems have evolved over the years with this a known factor, and so systems are reasonably robust to that decay, at least at the lower level. But its a real problems.

System busses introduce errors. Network cards (particularly TOE) introduce errors. Disk controllers, cables, and drives introduce errors. Non ecc memory introduces huge amounts of errors.

(When I say 'high' and 'huge' I mean at volume. When you've got machines constantly thrashing a large disk pool 24 hours a day, 7 days a week, 52 weeks a year, for the lifetime of the system, even 1 error in a trillian ops becomes quite significant.)

Now mind you, many high end SAN systems give you nice snapshotting, mirroring, etc features. But with ZFS you get the data integrity goodness, PLUS snapshotting, mirroring, pooling, etc, for free and open source, without having to pay 6-figures USD for SAN equipment.

The discussion of UML's death has been very interesting. Along those lines, we invite you to participate in a survey of how Use Cases are used (within or outside UML). We would really like to hear your views about Use Cases and what you are doing with them. We have recently created a web survey and we would love to get your responses and ideas, no matter what you think! The survey can be found at: https://www.uleth.ca/survey/uml/ The survey is hosted by the University of Lethbridge in Alberta Canada. We are Brian Dobing, from the University of Lethbridge, and Jeff Parsons, Memorial University of Newfoundland. We are primarily researchers and teachers, not UML consultants or book writers. We have no preconceived notions of what distinguishes good vs bad Use Cases, when and how they should be used, etc. But we are very interested in your views. Some of our work was published in the Communications of the ACM and is available free online at: http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=461 We have recently completed a longer article based on this research and should be able to provide it to anyone interested in a few months. (It isnâ(TM)t published yet.) You can request a copy if you complete the survey â" but actually we will provide it free to anyone so please donâ(TM)t enter a lot of garbage data just to get the paper. Just send us an email (there are email links on the first page of the survey). We really welcome all opinions, including those that say weâ(TM)re asking the wrong questions etc. Our goal is to help the UML and Use Case community better understand what it going on. To that end, the OMG is supporting our research and has provided a link to our survey on their web pages (omg.org and uml.org). We look forward to hearing from you and providing you with some interesting feedback in return. Once again, the link is: https://www.uleth.ca/survey/uml/

In this interesting interview with ACM Queue, Mary Lou Jepsen (the founding Chief Technology Officer of One Laptop Per Child) notes that CPU power is not the key value proposition of an ultra-light PC, it's how fast one can turn the CPU on and off to conserve power.

The entire software application stack is moving to a rich-but-thin client architecture. Even with the puny CPU and RAM the OLPC XO affords, I can edit my documents, spreadsheets, and email on Google Apps, upload my comments to Slashdot, read e-books, listen to music, etc. I do need a PC with more horsepower for my thick-client apps. But for on-the-go, I'd rather save the weight and battery life.

Frankly, none of the UMPC darlings I've seen and used -- the Eee PC included -- is as functional as the OLPC XO. The dual screen makes it possible to go from the subway tunnel to direct sunlight without skipping a beat. Try that with any other laptop. The XO feels like the first truly portable, mobile PC.

XML is not necessarily for human eyes. With the strict rules on non-overlapping closing of tags, its parsing and expansion is very easily stored and visualized as a tree. So parsing in general is actually quite easy. Also when you consider people like this http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=247&page=4 (ACM! So take it seriously!) who want to convert all Turing complete programming languages into XML abstractions, and call it the future, well... I'm honestly not sure why as you're right, we could have certainly done all this before. It's just sort of a generalization that everybody can agree on. Then again, maybe it's a response to, "Hey! _Anything_ is better than LISP!"

Too true - for most purposes the programmer should not have to worry about such things. This is a failing of C/C++ which makes it inappropriate for most software development. Using languages more appropriate for typical applications, it is not impossible to go for years without a segfault. There are reasons why so many programmers work in interpreted environments such as Perl, PHP, Ruby, Lisp, Haskell, etc. - beyond each language's particular strengths these languages provide fundamental productivity and security advantages over low-level languages.

I used to teach a software quality assurance workshop, and in the course of collecting information for the class found substantial research showing that, regardless of programming language (from assembler to 4G languages), given 'good' programming practice (structured design and programming and walkthroughs among other things - this was a while back), on average there was one bug every 200 lines of production, released code. About 70% of these bugs were in the original design. That means 30% were actual coding errors. The research was performed in large scale, corporate, government and military related projects. I've probably still got the book somewhere ...

At that time it was also found that a team could produce, on average, about one line of production-release code per person-hour (this includes planning, design, testing, documentation, etc.). Actual coding accounted for about 15% of the total number of person-hours IIRC.

Many modern languages provide much better support for the programmer, and any possible performance advantage of bare-metal programming is no longer very relevant. Today even 'bare-metal' programming usually isn't, because processors now have their own memory management, CPU load management, etc. and the OS and auto-loaded libraries take up 95% of the slack. Much of the original domain of C (described once as "structure PDP-11 Macro assembler", I think by Kernighan or Richie) is now the domain of Intel and AMD processor hardware design teams, and to some extent Linus and friends.

Embedded processor systems may or may not require this low level access; operating system kernel programming may or may not. There is an arguable case for an OS to be built as a microkernel written close to the hardware, with a userland programming environment based a modern interpreted language - Mach + Java, or Mach + LISP could be exemplars.

[I am not a LISPer, but I am reminded of the remark that "all languages evolve over time to emulate LISP - badly." (source??) Maybe it's true.]

Therefore IMHO, C (or C++) is no longer the most appropriate tool for most programming applications. It may be necessary for coding to hardware, but for general applications there is no longer any excuse for using a language that does not prevent such basic problems, and requires so much of the programmer's mindshare for such low-level problem prevention. This link provides some perspective. (I was unable to find the original citation for the phrase "programming without a net".) If I can perform a complete HTTP access of a document and retrieve all the ancillary files using a single function call, then I have saved hundreds of lines of code, each with its bug probability, and saved many hours of coding.

By way of analogy, at one time it was necessary to adjust the spark gap differently for starting vs. running an automobile engine (Ford Model T). Tire patching was an every-20-miles event. As things advanced, shifting gears no longer required double clutching due to synchromesh, then automatic transmissions took gear management out of the problem space. As automobiles advanced, the number of things that had to be manually dealt with has continually been reduced, or rather moved up the scale of complexity - nowadays we spend more time managing our traffic environment and looking at the moving map GPS display than we spend manag

Belong to the public and should not be held hostage by congress.

http://en.wikipedia.org/wiki/Open_spectrum

explanation of interference.

http://www.acmqueue.org/modules.php?name=Content&p a=showpage&pid=37

http://www.acmqueue.org/modules.php?name=Content&p a=showpage&pid=43

Chris

What I usually say when interview candidates ask about this is that back-end and data crunching code tends to be C++, web GUI front-end stuff tends to be Java and Javascript, and scripts tend to be Python. Whatever tool works best for the job. It's not much different from what I've seen at other jobs, except for using Python instead of something like Perl. But there are no hard and fast rules. For example, there was a slashdot article last week about an internal web app written in Python. Here's an older article that talks a bit about Google's philosophy for choosing tools. There are various articles on Google technologies floating around on the web site too. Before anyone asks, I have no idea what the relative size of the code base in each language is.

Disclaimer: I work for Google.

For those who, like me, had heard of dtrace but little more (is it like strace, for example), this is very handy article written by one of the authors in Communications of The ACM

http://www.acmqueue.org/modules.php?name=Content&p a=showpage&pid=361&page=1

Yeah,it's 5 pages long, so those won't RTFA are even less likely to read this, but it's a good read covering motivation, history, solution compromises and some anecdotes that could qualify for http://thedailywtf.com/

The first DVR was tested on July 8, 1965, when CBS explored the possibilities of instant freeze-frame and rewind for sporting event broadcasts. Ampex released the first commercial hard disk video recorder in 1967. The HS-100 recorded analog video onto a digital hard disk and could store a maximum of only 30 seconds.

Buying up our spectrum like this installs a natural monopoly that is inefficient.

A better system would be for public/gov to create a network of towers for wimax/wifi.

I BETYA SPRINT WILL MAKE WIMAX REALLY AFFORDABLE FOR EVERYONE !!!!
http://www.acmqueue.org/modules.php?name=Content&p a=showpage&pid=37
http://www.greaterdemocracy.org/OpenSpectrumFAQ.ht ml
http://en.wikipedia.org/wiki/Open_spectrum

Readers may also be interested in my comments on that paper.
Cheers,
Michi.

The interview is a few years old now, so I don't know how well the numbers hold up, but Jim Gray suggests that the postal service was a far cheaper mechanism for transferring terabytes of scientific data than any Internet: ACM interview.

For your intro work - go ahead and use an IDE. Let the students get something up and running, with as little overhead as possible. It's a chance for them to see they can make something happen. What you achieve, hopefully, is to whet their appetite for more.

In the end however, they won't know what's going on. Not in any comprehensive sense of the word. Java or Python won't let them know what's going on either, so you've lost very little by using an IDE. Using command line tools will only change the focus of leaning from the code to the tools. Just make sure the program (the education program) gives them an oppertunity to get a real understanding through a language that makes what's actually happening visible.

I've watched with dismay the level of understanding drop year over year. I don't see anything checking the fall. The poor showing of US schools in the recent ACM programming contest is a reflection of this problem.

Watching my daughter learn programming leaves me with no question about this issue. When she went from Java to C her understanding of what was actually taking place went up dramatically. It reinforced my belief that learning a low level language - C or assembly - is necessary for real computer literacy. (Please, not C++, with C++ you end up with the worst possible combination: tremendous complexity and no support. And the addition Object Orientation doesn't really help.)

While there are few programs (at least by line count) that require C today, the deeper understanding of what's happening pays off. It pays off in being able to know what to expect. It pays off in better code in any language. Understanding the details allows you make informed choices. It seems the academic community has lost this perspective. There seems to be a belief that the "details" are beneath them. "You shouldn't have to think about memory management" is a popular comment to this effect. Unfortunate this is simply out of touch with reality - perhaps one too any levels of indirection.

Any computer education program should require a significant investment in low level coding. Demanding academic programs should require most of the work be done this way. The quality of the graduates would increase substantially. What we're getting instead, as Alan Kay put it in an recent interview, is "java certification" which is a much lower standard. And, as a standard, it's simply too low.

Dobberpuhl has a nice record of creating awesome chips and selling them for a lot (IIRC he sold his last chip company to Broadcom for $2billion) - and has pretty much re-assembled many of the better parts of the StrongARM team for this one - so I bet it does well.

I predict IBM'll buy them for their answer to StrongARM.

Low power chips?

This from the man who helped create the Alpha - long known as a low power / low heat chip.

(Wait until the morning to understand - this comment is from the mysterious far future)

Ricoh copiers run NetBSD. Jim Barton has written about licensing issues in the Tivo; they picked Linux over BSD because it was technically superior.

Excuse me, but does anyone in this industry even KNOW what relational means any more?

What is the type system used by this "relational" database? What are the candidate keys? What kind of constraints can I specify? What or where are the relvars? Can I create views? Does it allow declarative queries? How do I issue arbitrary relational expressions? How does it reconcile the hierarchical storage of most filesystems with the more general relational model?

Oh, you mean it just indexes metadata from files, for more speed? THAT'S NOT RELATIONAL! That's not even the level of abstraction you get from SQL databases (which are also definitely not relational).

Then again, this is the same Microsoft that gave us this utterly useless paper.

Aside: can you believe that both Jim Gray and Ted Codd received Turing awards???

http://www.acmqueue.org/modules.php?name=Content&p a=showpage&pid=209

Nonetheless, the relational guys took the challenge and said, "If we're going to be successful, we're going to have to perform as well as the IMS on the bread-and-butter transactions." A great deal of energy went into this, and I think it is fair to say that the relational implementations did okay. Today, all the best TPC-C [Transaction Processing Performance Council Online Transaction Processing Benchmark] results you see are with relational systems. The IMSes of the world are not reporting TPC-C results because, frankly, their price performance isn't very good.

This "paper" (wasn't there one a couple weeks from some Microsoft dude, which was equally useless?)

I suspect you mean this article by (the highly regarded) Jim Gray, whose opinion I'm much more inclined to seriously consider than the ramblings of the subject article's author (someone who, based on his company's product, apparently considers a B-Tree to be an innovative solution).

But I admit I found Gray's article equally disconcerting (perhaps he's been spending too much time on the sailboat in the SF Bay, and MSFT needed a shill to push their "XML Uber Alles" and Longhorn vision?).

SQL has managed to overcome a lot of derision over the years, and, tho the language has often been a bit slow on the uptake, it has managed to adapt admirably to abstract datatypes, recursive queries, OLAP, etc. Perhaps as importantly, the 90's left us with empirical evidence that the O-R juggernaut may have been ill conceived, with the failures of GemStone (which has since re-invented itself), and the disasterous impact of Informix's Illustra (nee Postgres) adventure.

Let's face it, SQL just works. Most people I've met who complain about SQL usually

• (a) don't know how to tune a database and/or
• (b) don't know how to properly use SQL and/or
• (c) are stuck using a half-assed DBMS

So, to paraphrase Twain, "The rumors of SQL's death have been greatly exaggerated."

Comparison of various CPU in MIPS/Watt or MFLOPS/Watt.

http://www.acmqueue.org/modules.php?name=Content&p a=showpage&pid=80&page=4

And some suppliers of efficient servers.
http://www.transmeta.com/success/server.html

Having dealt with HP, I would be inclined to look at one of the other vendors.

Google are doing to I.T. what Arkwright did to textiles during the Industrial Revolution and Ford did to manufacturing at the turn of the century. The vast majority of those in I.T. who don't follow their basic model are going out of business in the near future. There will only be a few niche players and a few Google like companies.

Anyway, the magic formula for the system to use is MIPS per Watt, or MFLOPS per Watt. The power requirements and heat produced by high density computers is a real problem to deal with, it's the real limiting factor for your data centre. The cost of the individual computers is relatively small in comparison.

e.g.
http://www.acmqueue.org/modules.php?name=Content&p a=showpage&pid=80&page=4

Anyway, I'd be building a Transmeta based cluster even though the absolute per CPU performance is lower than the latest AMD or Intel offerings (I'm assuming you need to keep ix86 compatability). So, go look for Transmeta blades or Transmeta 1/2 U or 1 U based servers.

I think that this was a /. story but the ACM ran a humorous piece that depicted zealous overindulgance in all things UML as a disease to be cured.

I'm a QA Analyst for a large software firm creating a Point of Sale program. It is complete crap.

It's complete crap because of the reasons you stated above. Our company thinks that QA is a division and not a process. All we are allowed to do is run through some use cases and make sure the thing's still broke. There is no review of requirements (they only write the Use Cases after the module's been built), no code reviews, no Unit Testing, no nothing and the app bearly runs because of it.

QA is not part of the development process. It's only tacked on after the fact. We often get builds that don't even run only to find out that developers didn't even try to run the app after trying to fix it. They've been getting away with this because the QA department manager reports to the development manager and the QA manager's a real wimp. The developer's excuse is that if they had to test it, it would slow them down. They also use the famous "It's not our job."

It's been in development for three years and we are currently trying to sell it to customers. One has already dropped us and the two remaining will probably leave soon. We get nightly builds and a weekly build that we are supposed to test each week. It takes at least half a day, sometimes two days, to even get it running.

It's also so big that it can't all be tested in every release (See this article, also in the Queue last month - http://www.acmqueue.org/modules.php?name=Content&p a=showpage&pid=277) We're way understaffed and they will be more understaffed as every QA person is looking for a new job.

You're right on with the list you mentioned and we can't get any upper management here to listen to us. The previous poster isn't the only one who's missing out.

Needless to say, if you are approched to buy "The Next Generation Java POS" and it seems to have more bugs than it should, run as fast as you can. It's worse than you think. They don't call it a POS system for nothing.

So ... the folks over at ACM Queue didn't have actual knowledge of a programming language?

The FreeBSD operating system provides the jail(2) system call and the jail(1) command for imprisoning a process and its future decendants. The jail facility is based on the chroot(2) implementation, but prevents well-documented means to escape chroot confinement, offering partitioning of the file system, process, and networking namespaces. The facility removes all super-user privileges that would affect objects not entirely inside the jail.

For more information read:

• Poul-Henning Kamp and Robert Watson. Jails: Confining the omnipotent root. In Proceedings, SANE 2000 Conference. NLUUG, 2000.PDF, HTML.
• Poul-Henning Kamp and Robert Watson. Building Systems to be Shared Securely ACM Queue vol. 2, no. 5 - July/August 2004 HTML

What's with all these so-called interviews which are basically a handful of random questions asked by an interviewer who seems to be doing his junior-high homework assignment? OSNews is bad enough... can't they ask anything interesting, or actually engage in a conversation about the subject? Linus has lots of interesting things to say, but unfortunately these folks can't think of what to ask.

The interviews in ACM Queue, particular the one with Jim Gray interviewed by David Patterson, was much much more intriguing.

...is here!

here you go

I'd mod you up if that was possible ;) Anyway I'll keep the conversation here on Slashdot.

I must admit that although I continue to receive ACM Queue issues, my opinion of Queue was largely formed by Volume 1, Issue 1. They say you never get a second chance at a first impression. Queue's first impression was pretty bad.

The authors are from the usual suspects: IBM, Microsoft, and Sun. I realize these are huge organizations with large staffs and bottomless research budgets, but these three organizations are massively over-represented in the mainstream publications. They also have a habit of shilling for their employers, which gets old after a few decades. If I wanted to read about why Microsoft thinks .NET web services are the next big thing, I could just as easily pick up InfoWorld or read C|Net.

Speaking of shilling, let's take a look at vol. 1, issue 1, article 1, sentence 1. Web services are emerging as the dominant application on the Internet. How did that one squeak by the editorial board? The assertion is demonstrably false, as e-mail, news, and entertainment combine to form almost all internet use, even in business. Voice-over-IP is picking up steam, and RSS has recently added to the functionality of web journalism, but web services remain in the primordial ooze. They certainly aren't the "dominant application" and probably will never be.

The subtle advertising continues. For example, MapPoint.Net provides maps and location services is an example and This document can be used by program development tools, such as Microsoft's Visual Studio .NET is another. Yeah, we know Visual Studio .NET is a development tool, thanks for working that in. That sort of thing tips the author's hand as a corporate promoter, even if he doesn't conciously realize it.

Another example I see in the Queue and in virtually all other mainstream publications is the tendency of corporate researchers to refer to existing, perfectly servicable software as "legacy systems." The subtle derision is meant to gently remind the user that anything he already owns should be thought of in the past tense, and anything the software industry is now offering should be considered superior. My Bridge market data feed from Reuters is a legacy system, but an XML/.Net/WSDL/HTTP service consisting of a subset of Bridge's functionality heralds the dawn of an era of happiness and light. And this sort of thing slides past the Queue's editorial board in every issue.

I'll try to keep an open mind when I next get Queue, but presently every time I see it my advertising-defense system goes to Defcon Zero. I hope you can be more stern with your contributors in the future, to help trim out their sponsored bias.

Right now, the state of the art in software security is to pass your code through some kind of static source-code analyzer such as ITS4 or Fortify that looks for dangerous practices and known bugs. That's a great start, and, according to my friend Gary McGraw--chief technology officer of Cigital and author of several books on software security--who works with the stuff, it catches a significant number of potential security problems. But, as you can see, the compiler already knows a lot of what it needs to in order to make a good stab at determining what is being done wrong.

One really neat concept is embodied in the Perl programming language--tainting. The idea of tainting is that the interpreter tracks the source of data and turns off dangerous operations if they are called directly as a result of user input. For example, when you're running a Perl script in taint mode, it turns on a lot of error checking before passing user-provided data to certain system calls. When you try to open a file for write using a filename that is tainted data, it checks to make sure the directory tree ownerships for the target directory are correct and that the filename doesn't contain "../" path expansions. In other words, the runtime environment tracks not just the type and value of the data but also its origin. You can imagine how nice this capability can be for writing server-side code or captive applications.

Unfortunately, few programmers use tainting because it imposes an extra burden on the programmer, and it's sometimes difficult to figure out a secure way to get the job done. But what if we built tainting-type capabilities right into our runtime environments for C/C++? A simple high-value approach might be to modify I/O routines (read/write) to determine if they are connected to a socket from a remote system, and to do some basic checks on data coming across it, such as checking to see if the stack is altered across calls to certain functions following I/O.

Ranum is citing this as an example of a way that existing tools -- such as GCC -- could be enhanced in such a way that programmers using currently popular languages (C/C++) would have a better security safety net without having to be retrained in practices (like checking for buffer overflows) that while obvious are still under-utilized in most software. The whole article is interesting reading, but this remark about Perl's taint mode seems like one of the best concrete examples of a modern protective language feature.

Right now, the state of the art in software security is to pass your code through some kind of static source-code analyzer such as ITS4 or Fortify that looks for dangerous practices and known bugs. That's a great start, and, according to my friend Gary McGraw--chief technology officer of Cigital and author of several books on software security--who works with the stuff, it catches a significant number of potential security problems. But, as you can see, the compiler already knows a lot of what it needs to in order to make a good stab at determining what is being done wrong.

One really neat concept is embodied in the Perl programming language--tainting. The idea of tainting is that the interpreter tracks the source of data and turns off dangerous operations if they are called directly as a result of user input. For example, when you're running a Perl script in taint mode, it turns on a lot of error checking before passing user-provided data to certain system calls. When you try to open a file for write using a filename that is tainted data, it checks to make sure the directory tree ownerships for the target directory are correct and that the filename doesn't contain "../" path expansions. In other words, the runtime environment tracks not just the type and value of the data but also its origin. You can imagine how nice this capability can be for writing server-side code or captive applications.

Unfortunately, few programmers use tainting because it imposes an extra burden on the programmer, and it's sometimes difficult to figure out a secure way to get the job done. But what if we built tainting-type capabilities right into our runtime environments for C/C++? A simple high-value approach might be to modify I/O routines (read/write) to determine if they are connected to a socket from a remote system, and to do some basic checks on data coming across it, such as checking to see if the stack is altered across calls to certain functions following I/O.

Ranum is citing this as an example of a way that existing tools -- such as GCC -- could be enhanced in such a way that programmers using currently popular languages (C/C++) would have a better security safety net without having to be retrained in practices (like checking for buffer overflows) that while obvious are still under-utilized in most software. The whole article is interesting reading, but this remark about Perl's taint mode seems like one of the best concrete examples of a modern protective language feature.

• Smithsonian - My favorite. I especially like the history articles they have.
• National Geographic - Great photography of course, but I read the Smithsonian first and don't always get to this one. This was basically free, though (I used expiring frequent flyer miles).
• Dr Dobb's Journal - Read this one religiously
• Linux Journal - Always read this one too.
• IEEE Spectrum - Usually one or two articles of interest.
• Communications of the ACM
• Computer - The magazine for the IEEE Computer Society
• Food and Wine - Don't really like it. I find it pretentious. Another free one.
• Flying - I'm not a pilot, but it is still interesting. Another freebie.
• Conde Naste Travel - Hate it. When I travel, I backpack and stay in cheap places, not 5 star hotels. But it was free.
• IEEE Communications - Not 100% sure on this title. I'm in telecomm, so this is useful when they cover optics stuff.
• Queue - From the ACM. Tries to be more oriented toward practicioners, whereas Communications of the ACM is more academic. Usually pretty good. They have been covering Open Source issues on a reqular basis.
• Maxim - Won't claim to read the articles because they suck. Cute girls, but the internet is a better source for that sort of stuff. This was also free.

Unfortunately, I don't have time to get through them all, but I at least look flip through them and read what really gets my attention

This sentence struck me as weird:

Admittedly, though, creating search engines to serve millions of users is an easier task than offering other remote services, such as e-mail and file sharing.

As has been pointed out by various /. stories, search is hard. With file sharing and e-mail, it seems to me that those would be easier to scale.

Toy is right. Besides the problem of roaming, power consumption is a huge problem with Wifi. 802.11b is a high bandwidth, long range (compared to Bluetooth at least) protocol. It consumes a lot of power just maintaining a link to the AP. According to this it consumes 800mW while idle with a link up, 950mW while receiving, and 1400mW while transmitting. Wifi might be practical for outgoing calls, but not the other way. You'd drain your battery ust sitting at a hotpot waiting for a call.

Jim Gray in an interview (previously mentioned on /.) also compared Moore's law and harddrive capacity increase. The bandwidth becomes a greater bottleneck, not storage capacity. That's why he ships his harddrives.

The interview is quite long and interesting.

Probably not, but according to Turing Award winner Jim Gray, it soon will.

What economic incentives are there to improve last-mile bandwidth to WANs? Will such bandwidth always be woefully lacking?

Maybe it's just MSIE being wierd, but the story appeared in a really small font.

The "printable version" is far easier to read.

Seems like we need to point the FCC towards Open Spectrum (mentioned in a previous Slashdot article). After all, why go to all the trouble of reshuffling the tiny spectrum we've got now when the proper devices and management can give us more bandwidth than we know what to do with yet?

He said the end is near; we only have a factor of 100 left in density-then the Seagate guys are out of ideas. So this 200-gig disk that you're holding will soon be 20 terabytes, and then the disk guys are out of ideas. The database guys are already out of ideas! What do you do with a 200-gig disk drive? You treat a lot of it as tape. You use it for snapshots, write-anywhere file systems, log-structured file systems, or you just zone frequent stuff in one area and try to waste the other 190 GB in useful ways. Of course, we could put the Library of Congress holdings on it or 10,000 movies, or waste it in some other way ... Not many of us know what to do with 1,000 20-terabyte drives-yet, that is what we have to design for in the next five to ten years ... we have to convert from random disk access to sequential access patterns. Disks will give you 200 accesses per second, so if you read a few kilobytes in each access, you're in the megabyte-per-second realm, and it will take a year to read a 20-terabyte disk. DP So disks are not random access any more? JG That's one of the things that more or less everybody is gravitating toward. The idea of a log-structured file system is much more attractive. There are many other architectural changes that we'll have to consider in disks with huge capacity and limited bandwidth.

expect things to be about 50-60 times as powerful as they are today.

Actually storage capacities are doubling each year, not each 18 months, and have been doubling annually since about 1989. So in 10 years your 100G hard drive will be 100 terabytes. Unfortunately, access speeds are only improving by about 10%/year, so searching for a file on your 100T drive will take about a week....

I don't normally flame people on Slashdot, but IMO your knee-jerk pro-authority attitude is the root cause of all our problems in England. Having people with your sort of attitude around is a real drag. The kind of things you want don't make anyone safer, they make life harder and more dangerous for everyone.

That's assuming current speeds. Well, as data gets more dense, the access speed inherently gets much faster, assuming the RPMs stay constant. If physical size stays the same, random access can't really get too much slower. So what is it that is going to be bad about terabyte disks?

The problem, as Jim Gray outlines it in the ACMQueue article:

"But starting about 1989, disk densities began to double each year. Rather than going slower than Moore's Law, they grew faster. Moore's Law is something like 60 percent a year, and disk densities improved 100 percent per year.

"Today disk-capacity growth continues at this blistering rate, maybe a little slower. But disk access, which is to say, 'Move the disk arm to the right cylinder and rotate the disk to the right block,' has improved about tenfold. The rotation speed has gone up from 3,000 to 15,000 RPM, and the access times have gone from 50 milliseconds down to 5 milliseconds. That's a factor of 10. Bandwidth has improved about 40-fold, from 1 megabyte per second to 40 megabytes per second. Access times are improving about 7 to 10 percent per year. Meanwhile, densities have been improving at 100 percent per year."

There's a lot more about this in the article. Check it out; it's +5 Informative stuff.

This conversation with Jim Gray, head of Microsoft's Bay Area Research Center, has grim, eye-opening comments on the growing gap between storage densities and access speeds/bandwidth. Currently the most effective way to send a multi-terabyte disk array is by UPS -- turns out a UPS truck has a "bandwidth" equivalent to about 7 megabytes/second. And the problem of practical access speeds is only going to get worse. At current and near-future access speeds, searching a 20-terabyte disk might take a year.

"At the FAST [File and Storage Technologies] conference about a year-and-a-half ago, Mark Kryder of Seagate Research was very apologetic. He said the end is near; we only have a factor of 100 left in density--then the Seagate guys are out of ideas. So this 200-gig disk that you're holding will soon be 20 terabytes, and then the disk guys are out of ideas. The database guys are already out of ideas!"

...rendering any improvements to the filesystem as superfluous.

Nothing is further from the truth. Mailing Disks is Faster than Uploading Data From the linked article: it will take a year to read a 20-terabyte disk

While we're still using hard-drives, though, things may yet change beyond recognition.

The other day I came across this discussion between Jim Gray (MS Research) and David Patterson (Pardee Prof. at UC Berkeley) suggesting among other things that if the disks get much bigger (Terabytes) they're likely to be serial-access rather than random-access (the return of mag-tape, but flatter, because that way you could read a 20TB disk in a day instead of a year), and the return of sneakernet (for terabytes of data, it's cheaper to fed-ex a computer set up as a fileserver containing the data on a hard-drive than it is to ftp it. And the bitrate's better with the 12-hour delivery from fed-ex.

TomV