I still have not seen details about what sort of connectivity is provided to the back, so wouldn't make much in the way of assumptions of how one would connect a keyboard. If they do provide at least USB, that really isn't all that power hungry. If you're using the keyboard heavily, there's a good chance you are also usin far more power hungry systems (display, radios, etc). When not in use, it can be powered down completely.
The maemo/meego devices have given users root access out of the box, perhaps you have to take one minor step to indicate you know what that means, but that's about all. These devices are there for you, and don't really try to protect themselves from their users/owners. I haven't seen the sources for sailfish yet, but I gather many of the people at Jolla didn't like the portions of the os that were shipped binary only while they were at nokia. So I'd expect the openness to improve. From the sdk, it looks like they are continuing to use X11, so that means that pretty much any generic arm friendly linux application should run without porting (though there are pleanty of good reasons to specialise/port). For maemo devices, that meant there was just one simple package to install to add a debian chrooted enviroment, which of course gives access to the full debian arm repos.
Replacable batteries.
It looks like they have taken an interesting step following that philosophy with enabling functional expansion through interchangable backs.
Sailfish also has a pretty slick interface. I will hold off on judgement until I get a chance to use it for a while.
If a user-centric design philosophy (including openness/freedom) doesn't really matter to you, and you don't care about the user interface, yes it's just another phone. But then again, any modern cell phone is essentiall Turing-complete and you can build/connect accessories and power supplies around them. So at a high level of abstraction, no modern phone is distinguishable, nor should we expect to see one any time soon.
Perhaps the question should be whether or not consumers would be willing to pay for an application through mining for the developer. I could see that as preferrable to in-app charges or advertisement and various other sneaky ways game devs have tried to hide the way the real ammount they want consumers to pay for things.
To me, it looks as though Lenovo has been trying to make the Thinkpad line more profitable by slowily adopting common components/methologies from other lines. They could have assymilated the Thinkpad designs to make the Lenovo branded products better, but that would have increased the production cost, even if only slightly.
Its evident even in the firmware, where each generation moves away from handling more functionality in hardware (think things like the independent volume control/amplifier) to using software to make it look like it still functions like a Thinkpad.
Also, completely idiotic to follow Dell on the tablet design. The latchless lid on the latitude XT was stupid, and for whatever reason, Lenovo decided to follow suit. The x220 and x230 tablets are clearly yet another step down (I've had my nose in most of the tablet models since the x41). Don't get me wrong, the speed and low power capabilities (I frequently run at 6W when I want the battery life) are superior, but I think that's more a statement of the general trends in laptops (thank Intel for the cpu/chipset). The build quality and the bells and whistles under the hood, the things that differentiated the line, are trending towards the mean.
Have a look at the cypress PSOC family. The chips combine an ARM and an 8051 microcontroller with a pile of ad dsp and other special purpose logic as well as a modest ammount of programmable digital and analog resources.
The software is windows only, which is major (but not killer) downside for me. I've only played with one for a couple hours, but it was enough for me to want to try them out for a few things around the house, when I find the time.
I highly doubt that's the case. I suspect the defect/variation distributions of few if any generations of intel chips have actually matched the distribution of market demand. Going back at least to the 386, they have artificially crippled higher end models (beyond what was necessary from defects), to provide different price/feature/performance points for consumers. The SX line was just DX chips with the internal floating point unit disabled.
We might feel a little less cheated if Intel actually designed and fabricated different products so that we actually get what we pay for, and don't have to feel cheated because that new cpu is artificially crippled. Realistically, the production cost of the extra silicon is far less than the cost of designing different chips. And, yes some chips will naturally fall into the lower end models because of defects and variations. So whether or not we feel cheated, they are actually delivering a better value to the customer by artificially differentiating the models. People are accustomed to market segmentation, airfares being one major example, I suppose it just feels a little different knowing that you get a black box that is a first class seat with extra blocks added to squish you because you only wanted to pay for ecconomy class.
As to why the segmented market is reasonable, the fact of the matter is people do have different values and needs, and people want a price tag that matches those needs. Intel could charge a uniform price for all cpus, but then they would have to decide between alienating a huge number of customers by setting to high a price, or drastically reducing their profits. Say what you will about corporate greed, and even Intel's stagnation. They do reinvest huge ammounts of their profits into building new fabs, and other aspects of producing subsequent generations. Market segmentation enables them put more of the cost burden on the customers that have more money to play with and really care about the getting the performance now. Really, it most benefits the consumers that will feel cheated (I haven't heard people complaining about the higher prices of the higher end chips). If chip makers were acting with more bad faith (just look at the telcom and cable industry), then this would be more upsetting (and less about consumer value).
As for the lying issue. I don't think this has been much of a secret for the last 25 years. Its probably just a matter of more people are becoming aware of it now, people who are less familiar with the literature and issues. Also, I think Intel has been fairly stupid about marketing. The post-sale "upgrades" drew people's attention to issues that most people just don't want to know about, and probably didn't really appeal to all that many consumers. Its also a little sickening to see them put effort into developing a "secure" system that lets them sell hardware upgrades. Perhaps something like that would just work better for consumer relations if they provided a trade-up program, even if it does mean it would cost more for consumers to get the same upgrade (assuming the same profit for intel).
Many people seem to be going on and on about how innapropriate Linus' tone was. How many of you have read the thread. It doesn't matter how you feel about getting an email like that, Mauro was the target, and his responses don't come across as those of a crushed spirit. Read the emails again, he apologized, then gets on with bussiness, explaining what's going on in that little corner of the kernel.
Different domains have different ways of communicating and different standards of acceptable behavior. We wouldn't expect the same tone from a kindergarden teacher, a librarian, and a sailor on a navy ship in the middle of the atlantic. So sure, if that's your environment and it pisses you off, go ahead rag on Linus for a while, he can take it. If not, try imagining the librarian wandering around your office telling you to keep your voice down, or some other absurd situation which would drive you crazy but might not offend you so directly.
Yes, the kernel mailing lists technically constitute a public forum, but to an extent that says more about the public listening in on his domain than him shooting messages out to the world. He put the kernel out for all of us to use and enjoy. He didn't force himself upon the world (like some other OS developers).
Linus has a reputation for being harsh, but how often does he go off on a rant? How often does he rag on a clueless passerbyer who shoots off a silly patch to the kernel. Mauro, is not a fresh kernel developer wannabe, he's been working on the V4L stuff for years. Pressumably, he understands geek communication is not as slick and polished as corporate or political discorse, where saying things politely seems to be more important than actually conveying any useful information.
Some comments mentioned Dale Carnige and other stuff about sweet talking to convince people to give you what you want. I don't think Linus really has anything to prove. People respect him for his work. I'd love to see people protest on the streets, reject the Linux kernel cause they think Linus is an ass. Try switching to windows, mac, hey maybe even Hurd. Hmmmm, all project lead by even bigger assholes, never mind....
Finally, what's really in our best interest? Would you prefer Linus bottles up his frustration long enough to compose himself so he can be more polite? Maybe, he should go sit on the beach every time he feels like being rude until he calms down. Personally, I think he's more useful to me, bruising a few feelings here and there and getting back to work.
On a separate note, I don't think Mauro was right about his response. Pulse and kde blowing up like that because the kernel returned a different failure then expected is a clear failure, particularly for things that try to position themselves are core facilities, even if in userspace. That said, this does come as a response to a patch in a RC. If someone catches a change that will cause immediate problems, whether they are wrong or not, as long as the change wasn't some critical fix to an even worse problem, this is the time to revert first, and then commence discussion. Teasing an outsider for buggy userspace code, or for an audio server interacting with video systems (which is actually not too uncommon, don't know why he went off on that) was more innapropriate than Linus' blowup.
I'm sure he'd be receptive to criticism, arguements and second guesses. As long as the other person actually makes good points. He certainly hasn't brought the kernel to this stage soley on his own and by being a closed minded dictator.
A fair number of people have worked on the infrastructure and building the community and development methodologies. If anything, his reliance on other people to take care of their domains is probably part of why he went off like that.
Realistically, they might argue for a minute or two, but that's about it. Both are reasonably inteligent, can recognize the effort on a work in progress, and are perfectly capable of agreeing to disagree and move on when its a question of different philosophies. Shuttleworth puts a lot of effort into studying user interfaces and users, Linus does not. He has been known to complain about things he doesn't like in UIs, he knows what he likes and doesn't like, but I've yet to see him claim to be an expert in that area.
Moreover, Shuttleworth is pushing for interfaces that will work well for more typical people. Linus is perfectly capable of writing his own interfaces if he wants. His preferences seem to be fairly strong, and probably not along the lines of things that will work for most people.
Besides, both have many other interests and I'm sure they'd find something else more interesting to discuss.
I agree, I've had the best experiences with supermicro. Their OS compatability list is more than sufficient (they don't list Debian, but they cover enough distros that it doesn't matter). For one recent purchase, the list was sufficiently detailed to indicate that a motherboard I'd selected was compatible with FreeBSD 9.0, except the raid controller, which was supported by 8.2 (the driver missed the release window for the 9.0 kernel, but was trivial to compile). Aside from having to compile that one driver, I've never had any compatibility troubles with their motherboards with either Linux or BSD (haven't tried windows). I've also never had one fail (having used a few dozen over the last decade), so can't really comment on their warranty services.
For workstations, I mostly use Asus boards. They tend to have more bells and whistles and also have worked really well for me. I have used Intel boards, and can confirm they are also great but generally fall behind Asus and Supermicro on one end or the other (particularly considering their prices).
Except for laptops and smaller, I generally only buy boards that supprt ECC, that probably weeds out most of the crappy stuff on the market.
As for EFI, I haven't used it on a server or workstation yet, but I have used it on a laptop with an older bios that doesn't have the secure booting crap, or at least it's not enabled. From what I've seen its an ugly mess. Some cool ideas, but really lacking solid userfriendly tools. If you do a fresh install, it might not be too bad. I've only play with converting legacy bios installations to UEFI with and without GPT. For the most part, you can't configure/install the key components for EFI booting on a running system that was booted in legacy mode. The machines I've played with only support net booting with legacy bios (I typically net boot for installs and repair).
Converting a linux install without rewriting the entire disk is actually not too dificult, if you do it just right. However, don't try it unless you are comfortable with loosing the data on the disk. Windows seems to be a lot more finicky about EFI. For one, it will only boot with GPT partition tables (my bios and the linux kernel don't seem to mind using either GPT or legacy tables). Can't say I care enough about windows to have put in the effort to get the conversion to work.
Anyway, EFI is still surmountable, but life is easier if you avoid it and get a friendly board that still supports legacy booting.
Read the damn press release. It does say single link, but not single 100G link.
If they were demonstrating in-line compression at those speeds, or actually sending already compressed data at 4x the line rate, that would be intresting news.
Sloppy re-reporting.
At work (actual machine room), I've just been using old machines (obviously not running critical infrastructure there). At home, I got a raspberry pi to run bind, dhcpd, login, home automation and to wake up my home machines. But I haven't actually moved my dns services to it just yet.
Note that the 1800 is just for the tape drive. An 8 tape library with drive and media will be more like $4k, and that still only gets you 12TB (given the file types you mentioned, don't plan on getting any capacity boost from the LTO compression).
You will have to go with one really big library before tapes win on price. Unless of course you are willing to change tapes manually, or build your own robot/library out of lego. But even then that 24TB figure is only a lower bound on the cross over.
The first problem to consider is how you determine which files to backup. Filesystems like xfs, zfs, and btrfs have nice convenient ways to get a list of changed files (and for xfs and zfs, the contents of those files as well). For ext2/3/4 (and other older unixy filesystems) look at "dump". And of course, if you're working with a completely dumb filesystem, you can always use rsync (if your backup disk is remotely accessible) or some external/manual indexing to figure out what files to backup.
If your filesystem supports some form of dump (send for zfs), you can use that to create your incremental changes. If you only have a list of files, use tar, or rsync. If you have want to keep a full backup on the same drive, you can use rsync's batch mode (see the manpage) to efficiently generate incrememental backups, for filesystems that don't do a good job of that.
You don't want to hard link between your live tree and a backup tree. That will result in the changes showing up in both trees, obscuring the changes when you run a backup. It's a technique used with rsync for snapshotting, where two backups trees represent the state of the original filesystem at different times. To make that work, the links are broken for the files that differ between the two snapshots.
You might want to look into luminosity based research. The brightness at each pixel may contain some information of the angle of the surface with respect to the camera and a light source. At some point that looked potentially promising. But of course the technique can fail pretty easily.
Much of the work I've seen is based on trying to figure out how our brains do this all the time. Try closing one eye, see how 3D the world still looks (better than most 3D movies). You are going to have a tough challenge to beat that. But that doesn't mean its not worth trying.
I'm not really familiar with AMBA. However, if for whatever reason AMBA does not scale, one could simply architect a system where the reconfigurable fabric interfaces with multiple AMBA islands:) I hope that scalability is being carefully considered and it does not come to that.
It wouldn't be the first architecture to use FPGAs to support cooperation of processors. The Cray XD1 is one example, it had a mix of opterons and virtex fpgas, some of which were available for compute others solely for interconnect. On a side note the intel paragon used xilinx fpgas to control the leds on the doors, back when super computers where more fun to watch.
I agree I don't think Moore's law has been focused on sequential or even single threaded performance for quite a while. I do think things are getting more interesting. Clock and voltage scaling seem to be very slow if not entirely stalled. Density and die size still seem to be scaling nicely.
I'd also like to point out the trend for lower power devices. I wonder what the trend is for balance of compute and energy is for things like laptops and cell phones. The laptop trend seems to be slow decrease in power consumption with whatever compute fits in that power budget. Cell phones seem a bit more confusing. I would expect to see battery life of smart phones increase with each new generation, but there seems to be an obsession with computational power. On the upshot, at least cell battery life doesn't seem to be getting much worse. I suppose people might actually reject a phone that fails to survive a normal day of use.
All the early MPEG 4 accelerators I saw were implemented in FPGAs. Of course much of that was encoders instead of decoders, since that is the harder problem. Now you can buy cheap mpeg 4 asic/ip core accelerators. Those are still going to be much more energy efficient than using the array of general cores on a GPU.
As for implementing GPU pipelines on FPGAs, it has been done: http://hackaday.com/2008/05/21/open-graphics-card-available-for-preorder/ I'm sure I've seen other research projects or maybe just people screwing around and implementing GPU pipelines "because we can". Its also a convenient solution for educational purposes. But no, if you want to make an efficient GPU for general use, it does not make sense to map GPU logic onto the FPGA fabric. You would loose on the order of an order of magnitude in clock speed, and doing it that way you completely toss away the positive benefits of the FPGA architecture.
I think you might have a skewed impression of how complex mpeg4 encoding and decoding is, and how much area it consumes. Also in the comparison of FPGA logic cells and "gates" in a GPU is a bit faulty. In terms of raw transistor count the largest FPGAs tend to be a little ahead. That "million" or so logic elements in a FPGA does not translate to simple logic gates or transistors. The logic cells are multiple input lookup tables that are used to evaluate arbitrary boolean functions. How many traditional gates can you replace with a single 4 input lookup table? What about an 8 input LUT? The answer does depend on the logic you are mapping, but its almost never a 1:1 mapping.
Also FPGAs do have ram, fixed logic cores (dsp blocks/multipliers, etc), and even conventional processor cores. While its true that however big the array, someone will have a problem that won't fit, you can put an awful lot on a modern FPGA.
As for your final thought about fixed silicon. Not necessarily, look at this fellow's research: http://cas.ee.ic.ac.uk/people/nachiket/ He goes into why CPUs and GPUs are slow for running SPICE circuit simulations. Despite running at a fraction of the clock speed, his FPGA implementation completes the simulations faster and consumes much less power than the CPU or GPU.
True a fixed logic accelerator specifically designed to implement the algorithm would be faster, but how many special purpose fixed accelerators do you want to put on your chip? What if the implementation can benefit from dynamically adapting to the current problem? Sometimes it really is more efficient to provide reconfigurable logic and load in the best implementation you have for each problem. Dynamic hardware acceleration is likely one of the reasons intel is producing Atom-FPGA combos. There are ongoing research projects examining the benefits for mobile computing devices. Transistors are cheap, but people want to use cell phones for all sorts of strange things, and there's always something new on the horizon.
Tabula is a new FPGA company that implements time multiplexed logic to extend the effective size of a computation you can put in a
given size chunk of silicon: http://www.tabula.com/ Their products are still statically scheduled and not really amenable to the full virtualization of the SCORE model, but its a real product and you can buy one today.
There's a big space between the fully spatial FPGA and the fully temporal CPU, and we've been seeing that space fill slowly over time. From the CPU side, we've seen cores handle more operations per cycle, hyperthreading, and no multi-core is the default configuration. GPUs are now composed of hundreds or thousands of execution units that are simpler than CPU cores, but more complex than the logic blocks in FPGAs.
There are problems that are best suited for each of these architectures. When you play a graphics intensive game, you expect the GPU to handle stuff its good at and the CPU to handle the bits its good at. FPGAs are just a little bit more obscure. But hybridization does make sense. That's why we've seen PowerPC and Arm cores embedded in reconfigurable fabrics, and now Intel putting FPGA cores in the same package as their dies. We're long past the point of saying that any of these are irrelevant because they are not the optimal solution for all problems.
To add to that, your comment on idle resources. We're also hitting thermal limits. Yes we can still put more and more transistors in a chip, but we can't switch them all simultaneously at full speed without frying the chip. Increasing cache size and core count helps. But if you're going to have more area than can be used simultaneously it makes sense to add different resources that handle different tasks more efficiently (energy and latency). That's part of why intel, amd and nvidia are all mixing GPU and CPU cores on die. If the atom+fpga combo works out well, I would expect to see regions on reconfigurable fabric directly on die in the not to distant future.
a spreadsheet application will deliver results a lot faster.
Not really, particularly if you have the data already entered.
Running:
R
data=read.csv("data.csv")
hist(data)
takes far less time than selecting your columns, dragging the mouse over to the graph button, selecting the region for your plot, and then trudging through a multi-stage wizard. Even if you actually want to type in some data in a spreadsheet its frequently faster to save the table and load it up in R or gnuplot to graph it. And if you do want something like a histogram or a boxplot, excel doesn't stand a chance (gnumeric at least supports boxplots).
I might accept that creating a slightly prettied up graph might be a little quicker in a gui spreadsheet. But for quick and dirty and higher quality graphs they are slower, if they work at all. Once you start encoding your style preferences in little scripts that you load before graphing, you'll find even higher quality graphs take less time than mediocre graphs from a spreadsheet. And really there's something satisfying about tweaking one line in a single file and that automatically updating the style of 20 graphs in an article.
I generally find that when plotting, if doing it once its a coin toss whether to write a script or manipulate the data and plot manually, twice and scripting definitely breaks even and of course more than that and scripting just gets more and more valuable. R (and many other environments) save your history, so that if you do decide a day later you should have just written a script, its already there, you just need to copy the commands out of the history file. In excel, well at least you learned from experience what to do that next day.
As I see it there are two reasons to graph in a spreadsheet. First if you're actually working in a spreadsheet and just want a quick look at some data (not debating the merits of that, separate discussion). Second, when you're not sure what you want and are unfamiliar with the tools available, a gui gives you something to poke at blindly with a mouse. In that second case, I think one should accept the accept the pitfalls of ignorance with an intent to learn more and improve. Stubbornly grasping your spreadsheets, knowing there's a better world out there, will only hurt you in the long run.
If the prof is a co-author they get credit where it counts most for them. If you're at a research school, publications may be the primary metric for their performance, teaching and graduating students only count if they are a serious problem of if the research is sub-par. As such, get the prof to pay for the trip.
If the prof won't/can't pay check with the school. Many schools have travel grants for students in just this sort of situation.
Finally if all else fails and you really just don't want to go, but you've done the research, make the prof present it. You still get the author credit.
The Dell XT and XT2 and the HP TX all use roughly the same digitizer, though apparently different revisions in each. I have used a XT and XT2, though mostly in linux. I can say that I've seen multitouch function in windows, though I can't comment about stability for more than a few seconds of play.
Between the two, the xt2 is an incremental improvement: its considerably lighter, a bit faster, and the hard drive moved from an obscure "standard" to a SATA connector (which may more convenient for long term maintenance). The one advantage of the xt is that its now considerably cheaper.
If your primary usage is as a tablet, the dell laptops do not have a rigid latch to hold the lid in place, just magnets and rubber bumps/guides. It stays pretty well, but the sturdy latch on the thinkpad convertibles is better for prolonged use as a tablet.
Slashdot Mirror
Still think the N900 is the most useful phone I've used/seen.
I still have not seen details about what sort of connectivity is provided to the back, so wouldn't make much in the way of assumptions of how one would connect a keyboard. If they do provide at least USB, that really isn't all that power hungry. If you're using the keyboard heavily, there's a good chance you are also usin far more power hungry systems (display, radios, etc). When not in use, it can be powered down completely.
The maemo/meego devices have given users root access out of the box, perhaps you have to take one minor step to indicate you know what that means, but that's about all. These devices are there for you, and don't really try to protect themselves from their users/owners. I haven't seen the sources for sailfish yet, but I gather many of the people at Jolla didn't like the portions of the os that were shipped binary only while they were at nokia. So I'd expect the openness to improve. From the sdk, it looks like they are continuing to use X11, so that means that pretty much any generic arm friendly linux application should run without porting (though there are pleanty of good reasons to specialise/port). For maemo devices, that meant there was just one simple package to install to add a debian chrooted enviroment, which of course gives access to the full debian arm repos.
Replacable batteries.
It looks like they have taken an interesting step following that philosophy with enabling functional expansion through interchangable backs.
Sailfish also has a pretty slick interface. I will hold off on judgement until I get a chance to use it for a while.
If a user-centric design philosophy (including openness/freedom) doesn't really matter to you, and you don't care about the user interface, yes it's just another phone. But then again, any modern cell phone is essentiall Turing-complete and you can build/connect accessories and power supplies around them. So at a high level of abstraction, no modern phone is distinguishable, nor should we expect to see one any time soon.
Perhaps the question should be whether or not consumers would be willing to pay for an application through mining for the developer. I could see that as preferrable to in-app charges or advertisement and various other sneaky ways game devs have tried to hide the way the real ammount they want consumers to pay for things.
To me, it looks as though Lenovo has been trying to make the Thinkpad line more profitable by slowily adopting common components/methologies from other lines. They could have assymilated the Thinkpad designs to make the Lenovo branded products better, but that would have increased the production cost, even if only slightly.
Its evident even in the firmware, where each generation moves away from handling more functionality in hardware (think things like the independent volume control/amplifier) to using software to make it look like it still functions like a Thinkpad.
Also, completely idiotic to follow Dell on the tablet design. The latchless lid on the latitude XT was stupid, and for whatever reason, Lenovo decided to follow suit. The x220 and x230 tablets are clearly yet another step down (I've had my nose in most of the tablet models since the x41). Don't get me wrong, the speed and low power capabilities (I frequently run at 6W when I want the battery life) are superior, but I think that's more a statement of the general trends in laptops (thank Intel for the cpu/chipset). The build quality and the bells and whistles under the hood, the things that differentiated the line, are trending towards the mean.
Have a look at the cypress PSOC family. The chips combine an ARM and an 8051 microcontroller with a pile of ad dsp and other special purpose logic as well as a modest ammount of programmable digital and analog resources.
The software is windows only, which is major (but not killer) downside for me. I've only played with one for a couple hours, but it was enough for me to want to try them out for a few things around the house, when I find the time.
I highly doubt that's the case. I suspect the defect/variation distributions of few if any generations of intel chips have actually matched the distribution of market demand. Going back at least to the 386, they have artificially crippled higher end models (beyond what was necessary from defects), to provide different price/feature/performance points for consumers. The SX line was just DX chips with the internal floating point unit disabled.
We might feel a little less cheated if Intel actually designed and fabricated different products so that we actually get what we pay for, and don't have to feel cheated because that new cpu is artificially crippled. Realistically, the production cost of the extra silicon is far less than the cost of designing different chips. And, yes some chips will naturally fall into the lower end models because of defects and variations. So whether or not we feel cheated, they are actually delivering a better value to the customer by artificially differentiating the models. People are accustomed to market segmentation, airfares being one major example, I suppose it just feels a little different knowing that you get a black box that is a first class seat with extra blocks added to squish you because you only wanted to pay for ecconomy class.
As to why the segmented market is reasonable, the fact of the matter is people do have different values and needs, and people want a price tag that matches those needs. Intel could charge a uniform price for all cpus, but then they would have to decide between alienating a huge number of customers by setting to high a price, or drastically reducing their profits. Say what you will about corporate greed, and even Intel's stagnation. They do reinvest huge ammounts of their profits into building new fabs, and other aspects of producing subsequent generations. Market segmentation enables them put more of the cost burden on the customers that have more money to play with and really care about the getting the performance now. Really, it most benefits the consumers that will feel cheated (I haven't heard people complaining about the higher prices of the higher end chips). If chip makers were acting with more bad faith (just look at the telcom and cable industry), then this would be more upsetting (and less about consumer value).
As for the lying issue. I don't think this has been much of a secret for the last 25 years. Its probably just a matter of more people are becoming aware of it now, people who are less familiar with the literature and issues. Also, I think Intel has been fairly stupid about marketing. The post-sale "upgrades" drew people's attention to issues that most people just don't want to know about, and probably didn't really appeal to all that many consumers. Its also a little sickening to see them put effort into developing a "secure" system that lets them sell hardware upgrades. Perhaps something like that would just work better for consumer relations if they provided a trade-up program, even if it does mean it would cost more for consumers to get the same upgrade (assuming the same profit for intel).
Many people seem to be going on and on about how innapropriate Linus' tone was. How many of you have read the thread. It doesn't matter how you feel about getting an email like that, Mauro was the target, and his responses don't come across as those of a crushed spirit. Read the emails again, he apologized, then gets on with bussiness, explaining what's going on in that little corner of the kernel.
Different domains have different ways of communicating and different standards of acceptable behavior. We wouldn't expect the same tone from a kindergarden teacher, a librarian, and a sailor on a navy ship in the middle of the atlantic. So sure, if that's your environment and it pisses you off, go ahead rag on Linus for a while, he can take it. If not, try imagining the librarian wandering around your office telling you to keep your voice down, or some other absurd situation which would drive you crazy but might not offend you so directly.
Yes, the kernel mailing lists technically constitute a public forum, but to an extent that says more about the public listening in on his domain than him shooting messages out to the world. He put the kernel out for all of us to use and enjoy. He didn't force himself upon the world (like some other OS developers).
Linus has a reputation for being harsh, but how often does he go off on a rant? How often does he rag on a clueless passerbyer who shoots off a silly patch to the kernel. Mauro, is not a fresh kernel developer wannabe, he's been working on the V4L stuff for years. Pressumably, he understands geek communication is not as slick and polished as corporate or political discorse, where saying things politely seems to be more important than actually conveying any useful information.
Some comments mentioned Dale Carnige and other stuff about sweet talking to convince people to give you what you want. I don't think Linus really has anything to prove. People respect him for his work. I'd love to see people protest on the streets, reject the Linux kernel cause they think Linus is an ass. Try switching to windows, mac, hey maybe even Hurd. Hmmmm, all project lead by even bigger assholes, never mind....
Finally, what's really in our best interest? Would you prefer Linus bottles up his frustration long enough to compose himself so he can be more polite? Maybe, he should go sit on the beach every time he feels like being rude until he calms down. Personally, I think he's more useful to me, bruising a few feelings here and there and getting back to work.
On a separate note, I don't think Mauro was right about his response. Pulse and kde blowing up like that because the kernel returned a different failure then expected is a clear failure, particularly for things that try to position themselves are core facilities, even if in userspace. That said, this does come as a response to a patch in a RC. If someone catches a change that will cause immediate problems, whether they are wrong or not, as long as the change wasn't some critical fix to an even worse problem, this is the time to revert first, and then commence discussion. Teasing an outsider for buggy userspace code, or for an audio server interacting with video systems (which is actually not too uncommon, don't know why he went off on that) was more innapropriate than Linus' blowup.
I'm sure he'd be receptive to criticism, arguements and second guesses. As long as the other person actually makes good points. He certainly hasn't brought the kernel to this stage soley on his own and by being a closed minded dictator.
A fair number of people have worked on the infrastructure and building the community and development methodologies. If anything, his reliance on other people to take care of their domains is probably part of why he went off like that.
Realistically, they might argue for a minute or two, but that's about it. Both are reasonably inteligent, can recognize the effort on a work in progress, and are perfectly capable of agreeing to disagree and move on when its a question of different philosophies. Shuttleworth puts a lot of effort into studying user interfaces and users, Linus does not. He has been known to complain about things he doesn't like in UIs, he knows what he likes and doesn't like, but I've yet to see him claim to be an expert in that area. Moreover, Shuttleworth is pushing for interfaces that will work well for more typical people. Linus is perfectly capable of writing his own interfaces if he wants. His preferences seem to be fairly strong, and probably not along the lines of things that will work for most people. Besides, both have many other interests and I'm sure they'd find something else more interesting to discuss.
I agree, I've had the best experiences with supermicro. Their OS compatability list is more than sufficient (they don't list Debian, but they cover enough distros that it doesn't matter). For one recent purchase, the list was sufficiently detailed to indicate that a motherboard I'd selected was compatible with FreeBSD 9.0, except the raid controller, which was supported by 8.2 (the driver missed the release window for the 9.0 kernel, but was trivial to compile). Aside from having to compile that one driver, I've never had any compatibility troubles with their motherboards with either Linux or BSD (haven't tried windows). I've also never had one fail (having used a few dozen over the last decade), so can't really comment on their warranty services.
For workstations, I mostly use Asus boards. They tend to have more bells and whistles and also have worked really well for me. I have used Intel boards, and can confirm they are also great but generally fall behind Asus and Supermicro on one end or the other (particularly considering their prices).
Except for laptops and smaller, I generally only buy boards that supprt ECC, that probably weeds out most of the crappy stuff on the market.
As for EFI, I haven't used it on a server or workstation yet, but I have used it on a laptop with an older bios that doesn't have the secure booting crap, or at least it's not enabled. From what I've seen its an ugly mess. Some cool ideas, but really lacking solid userfriendly tools. If you do a fresh install, it might not be too bad. I've only play with converting legacy bios installations to UEFI with and without GPT. For the most part, you can't configure/install the key components for EFI booting on a running system that was booted in legacy mode. The machines I've played with only support net booting with legacy bios (I typically net boot for installs and repair).
Converting a linux install without rewriting the entire disk is actually not too dificult, if you do it just right. However, don't try it unless you are comfortable with loosing the data on the disk. Windows seems to be a lot more finicky about EFI. For one, it will only boot with GPT partition tables (my bios and the linux kernel don't seem to mind using either GPT or legacy tables). Can't say I care enough about windows to have put in the effort to get the conversion to work.
Anyway, EFI is still surmountable, but life is easier if you avoid it and get a friendly board that still supports legacy booting.
Read the damn press release. It does say single link, but not single 100G link. If they were demonstrating in-line compression at those speeds, or actually sending already compressed data at 4x the line rate, that would be intresting news. Sloppy re-reporting.
At work (actual machine room), I've just been using old machines (obviously not running critical infrastructure there). At home, I got a raspberry pi to run bind, dhcpd, login, home automation and to wake up my home machines. But I haven't actually moved my dns services to it just yet.
Note that the 1800 is just for the tape drive. An 8 tape library with drive and media will be more like $4k, and that still only gets you 12TB (given the file types you mentioned, don't plan on getting any capacity boost from the LTO compression). You will have to go with one really big library before tapes win on price. Unless of course you are willing to change tapes manually, or build your own robot/library out of lego. But even then that 24TB figure is only a lower bound on the cross over.
The first problem to consider is how you determine which files to backup. Filesystems like xfs, zfs, and btrfs have nice convenient ways to get a list of changed files (and for xfs and zfs, the contents of those files as well). For ext2/3/4 (and other older unixy filesystems) look at "dump". And of course, if you're working with a completely dumb filesystem, you can always use rsync (if your backup disk is remotely accessible) or some external/manual indexing to figure out what files to backup.
If your filesystem supports some form of dump (send for zfs), you can use that to create your incremental changes. If you only have a list of files, use tar, or rsync. If you have want to keep a full backup on the same drive, you can use rsync's batch mode (see the manpage) to efficiently generate incrememental backups, for filesystems that don't do a good job of that.
You don't want to hard link between your live tree and a backup tree. That will result in the changes showing up in both trees, obscuring the changes when you run a backup. It's a technique used with rsync for snapshotting, where two backups trees represent the state of the original filesystem at different times. To make that work, the links are broken for the files that differ between the two snapshots.
You might want to look into luminosity based research. The brightness at each pixel may contain some information of the angle of the surface with respect to the camera and a light source. At some point that looked potentially promising. But of course the technique can fail pretty easily. Much of the work I've seen is based on trying to figure out how our brains do this all the time. Try closing one eye, see how 3D the world still looks (better than most 3D movies). You are going to have a tough challenge to beat that. But that doesn't mean its not worth trying.
I'm not really familiar with AMBA. However, if for whatever reason AMBA does not scale, one could simply architect a system where the reconfigurable fabric interfaces with multiple AMBA islands :) I hope that scalability is being carefully considered and it does not come to that.
It wouldn't be the first architecture to use FPGAs to support cooperation of processors. The Cray XD1 is one example, it had a mix of opterons and virtex fpgas, some of which were available for compute others solely for interconnect. On a side note the intel paragon used xilinx fpgas to control the leds on the doors, back when super computers where more fun to watch.
I agree I don't think Moore's law has been focused on sequential or even single threaded performance for quite a while. I do think things are getting more interesting. Clock and voltage scaling seem to be very slow if not entirely stalled. Density and die size still seem to be scaling nicely.
I'd also like to point out the trend for lower power devices. I wonder what the trend is for balance of compute and energy is for things like laptops and cell phones. The laptop trend seems to be slow decrease in power consumption with whatever compute fits in that power budget. Cell phones seem a bit more confusing. I would expect to see battery life of smart phones increase with each new generation, but there seems to be an obsession with computational power. On the upshot, at least cell battery life doesn't seem to be getting much worse. I suppose people might actually reject a phone that fails to survive a normal day of use.
All the early MPEG 4 accelerators I saw were implemented in FPGAs. Of course much of that was encoders instead of decoders, since that is the harder problem. Now you can buy cheap mpeg 4 asic/ip core accelerators. Those are still going to be much more energy efficient than using the array of general cores on a GPU.
As for implementing GPU pipelines on FPGAs, it has been done: http://hackaday.com/2008/05/21/open-graphics-card-available-for-preorder/ I'm sure I've seen other research projects or maybe just people screwing around and implementing GPU pipelines "because we can". Its also a convenient solution for educational purposes. But no, if you want to make an efficient GPU for general use, it does not make sense to map GPU logic onto the FPGA fabric. You would loose on the order of an order of magnitude in clock speed, and doing it that way you completely toss away the positive benefits of the FPGA architecture.
I think you might have a skewed impression of how complex mpeg4 encoding and decoding is, and how much area it consumes. Also in the comparison of FPGA logic cells and "gates" in a GPU is a bit faulty. In terms of raw transistor count the largest FPGAs tend to be a little ahead. That "million" or so logic elements in a FPGA does not translate to simple logic gates or transistors. The logic cells are multiple input lookup tables that are used to evaluate arbitrary boolean functions. How many traditional gates can you replace with a single 4 input lookup table? What about an 8 input LUT? The answer does depend on the logic you are mapping, but its almost never a 1:1 mapping.
Also FPGAs do have ram, fixed logic cores (dsp blocks/multipliers, etc), and even conventional processor cores. While its true that however big the array, someone will have a problem that won't fit, you can put an awful lot on a modern FPGA.
As for your final thought about fixed silicon. Not necessarily, look at this fellow's research: http://cas.ee.ic.ac.uk/people/nachiket/ He goes into why CPUs and GPUs are slow for running SPICE circuit simulations. Despite running at a fraction of the clock speed, his FPGA implementation completes the simulations faster and consumes much less power than the CPU or GPU. True a fixed logic accelerator specifically designed to implement the algorithm would be faster, but how many special purpose fixed accelerators do you want to put on your chip? What if the implementation can benefit from dynamically adapting to the current problem? Sometimes it really is more efficient to provide reconfigurable logic and load in the best implementation you have for each problem. Dynamic hardware acceleration is likely one of the reasons intel is producing Atom-FPGA combos. There are ongoing research projects examining the benefits for mobile computing devices. Transistors are cheap, but people want to use cell phones for all sorts of strange things, and there's always something new on the horizon.
Reconfigurable logic can be virtualized to get around the area limitations. Have a look at the SCORE publications for research on that topic: http://www.seas.upenn.edu/~andre/compute_models.html
Tabula is a new FPGA company that implements time multiplexed logic to extend the effective size of a computation you can put in a given size chunk of silicon: http://www.tabula.com/ Their products are still statically scheduled and not really amenable to the full virtualization of the SCORE model, but its a real product and you can buy one today.
There's a big space between the fully spatial FPGA and the fully temporal CPU, and we've been seeing that space fill slowly over time. From the CPU side, we've seen cores handle more operations per cycle, hyperthreading, and no multi-core is the default configuration. GPUs are now composed of hundreds or thousands of execution units that are simpler than CPU cores, but more complex than the logic blocks in FPGAs.
There are problems that are best suited for each of these architectures. When you play a graphics intensive game, you expect the GPU to handle stuff its good at and the CPU to handle the bits its good at. FPGAs are just a little bit more obscure. But hybridization does make sense. That's why we've seen PowerPC and Arm cores embedded in reconfigurable fabrics, and now Intel putting FPGA cores in the same package as their dies. We're long past the point of saying that any of these are irrelevant because they are not the optimal solution for all problems.
To add to that, your comment on idle resources. We're also hitting thermal limits. Yes we can still put more and more transistors in a chip, but we can't switch them all simultaneously at full speed without frying the chip. Increasing cache size and core count helps. But if you're going to have more area than can be used simultaneously it makes sense to add different resources that handle different tasks more efficiently (energy and latency). That's part of why intel, amd and nvidia are all mixing GPU and CPU cores on die. If the atom+fpga combo works out well, I would expect to see regions on reconfigurable fabric directly on die in the not to distant future.
This changes nothing. Bose has been biased towards Masstech for decades. He was a prof there, and the company offered discounts to the students.
a spreadsheet application will deliver results a lot faster.
Not really, particularly if you have the data already entered. Running:
R
data=read.csv("data.csv")
hist(data)
takes far less time than selecting your columns, dragging the mouse over to the graph button, selecting the region for your plot, and then trudging through a multi-stage wizard. Even if you actually want to type in some data in a spreadsheet its frequently faster to save the table and load it up in R or gnuplot to graph it. And if you do want something like a histogram or a boxplot, excel doesn't stand a chance (gnumeric at least supports boxplots).
I might accept that creating a slightly prettied up graph might be a little quicker in a gui spreadsheet. But for quick and dirty and higher quality graphs they are slower, if they work at all. Once you start encoding your style preferences in little scripts that you load before graphing, you'll find even higher quality graphs take less time than mediocre graphs from a spreadsheet. And really there's something satisfying about tweaking one line in a single file and that automatically updating the style of 20 graphs in an article.
I generally find that when plotting, if doing it once its a coin toss whether to write a script or manipulate the data and plot manually, twice and scripting definitely breaks even and of course more than that and scripting just gets more and more valuable. R (and many other environments) save your history, so that if you do decide a day later you should have just written a script, its already there, you just need to copy the commands out of the history file. In excel, well at least you learned from experience what to do that next day.
As I see it there are two reasons to graph in a spreadsheet. First if you're actually working in a spreadsheet and just want a quick look at some data (not debating the merits of that, separate discussion). Second, when you're not sure what you want and are unfamiliar with the tools available, a gui gives you something to poke at blindly with a mouse. In that second case, I think one should accept the accept the pitfalls of ignorance with an intent to learn more and improve. Stubbornly grasping your spreadsheets, knowing there's a better world out there, will only hurt you in the long run.
If the prof is a co-author they get credit where it counts most for them. If you're at a research school, publications may be the primary metric for their performance, teaching and graduating students only count if they are a serious problem of if the research is sub-par. As such, get the prof to pay for the trip. If the prof won't/can't pay check with the school. Many schools have travel grants for students in just this sort of situation. Finally if all else fails and you really just don't want to go, but you've done the research, make the prof present it. You still get the author credit.
Any chance you have a parallel port? Should be able to boost your dump rate to 500kpbs or so.
The Dell XT and XT2 and the HP TX all use roughly the same digitizer, though apparently different revisions in each. I have used a XT and XT2, though mostly in linux. I can say that I've seen multitouch function in windows, though I can't comment about stability for more than a few seconds of play. Between the two, the xt2 is an incremental improvement: its considerably lighter, a bit faster, and the hard drive moved from an obscure "standard" to a SATA connector (which may more convenient for long term maintenance). The one advantage of the xt is that its now considerably cheaper. If your primary usage is as a tablet, the dell laptops do not have a rigid latch to hold the lid in place, just magnets and rubber bumps/guides. It stays pretty well, but the sturdy latch on the thinkpad convertibles is better for prolonged use as a tablet.
So far