I can already type very fast on my on-screen keyboard without the need for silly tactile gadgets, and haptic feedback exists for the folks who aren't able to do so.
I wonder how "very fast" you type and how that rates relative to others. Whether it be that you have superhuman abilities to type faster without this sort of capability or you deem your speed to be 'fast enough', either way there are portions of the population that do either do not have your ability or are not satisfied as easily.
For one, I need the tactile feedback because the feedback enables me to move with more confidence. Haptic feedback is little more than a gimmick, I need to feel the different keys. Also, I let my unused fingers largely rest on the keys. I can't touch-type on a touchscreen because my stray fingers are constantly triggering stray keypresses.
I'm still not crazy about this even if it works as designed. Changing between text entry and non-text entry become a bit more cumbersome and it's a switch I make constantly. Laptops continue to be my favored strategy for this and a number of reasons, but the problems they are trying to address are an issue for a lot of people.
The issue being that with the plans with discounted phones, the subsidy is baked into the plan. To say a cell phone associated with a such a plan is indicitave if the realistic retail price of a tablet *not* tied to a carrier would be silly.
A number of people have indicated this may be an off-contract price, but pointed to devices that have such incredibly crippled specs that couldn't possibly drive a pixel count appropriate for a larger screen.
I concur on idle, but on the 'web 2.0' functions, I really haven't noticed a downside in the long run. I have to confess creating a comment is far less intrusive than it was before and the structure for discussions hasn't changed too much. I will say sometimes the filtering has unfortunate consequences compared to old days (e.g. comments that are in reply to something modded into oblivion have no visual cue indicating they are a reply to anything instead of a top level post, leaving me sometimes scratching my head at the impetus for a post before realizing they must have been replying to someone).
I want to say I enjoy slashdot as one of the few sites actually implementing a nice and full threaded discussion system. We aren't talking about obsolescence, but rather a preference. Too many discussion systems either reorder posts, support no or one level of reply, and other such silly limitations.
Aside from that, the quality of commentators tends to be higher. More often than not, someone related to or very keenly aware of the subject of a story chimes in with additional data whereas most other forums explode in a barrage of inane chatter, trolls and woefully misinformed people. Yes, slashdot is subjected to that as well *but* if we are grading on a curve here, slashdot's community comes out pretty good.
In terrestial radio, you have maybe 6-10 distinct things to watch/record at given point of time.
If you pay a *whole* lot more for satellite or cable, you get one order of magnitude more stuff to watch at a given point of time. If left to 'surf', this is also 10 times more work to trudge through.
In order to watch something I like, I can either align my schedule to it or have my PVR attempt to record it only to get out of sync due to a baseball game (or else have them cancel that showing entirely, which means no way of watching what I wanted whether I liked the baseball game or not). The logistics of broadcast television are a pain with PVR as a hackish workaround.
Meanwhile, any arbitrary video stream accessible from hulu, youtube, or netflix out of *thousands* is immediately available, not tied up in arbitrary 'channels', not bound to a restricted broadcast medium.
I suppose the only thing that's missing is the 'I don't know what to watch so just spew something at me'. Hulu desktop almost does this but generally just throws movie trailers at me. Something like Pandora mechanics would probably outdo television for a contiguous stream of stuff that keeps me engaged, since a television channel frequently has no theme consistency timeslot-to-timeslot.
That was done frequerntly if I recall right. I think on occasion the 'stop the turbolift' conversations didn't take more time than some 'let the turbolift go' conversations. Obviously turbolifts go to their destination, make whooshing sound effects, and open the doors when they detect conversation is over. 'Computer stop' was just a signal to cut the sound effects.
I've made the same request before and I'll make it again.
Give me some way to search window titles to filter the window preview. KDE does this, compiz does this. I have lots of windows and searching with keyboard would be nice.
Mouseover an application icon in the 'activities' view should filter away windows not belonging to that icon and make the windows belonging to that app take up the full screen.
KDE 4.7+Icon Tasks has been a fairly decent experience though. I wish the single window and multi-window case of an application behaved more similarly though. If I click on an icon with only one window, it toggles minimize. If multi-window, present windows. I can make the multi-window do minimize toggle, but I actually kind of want the converse change...
I don't think price is driving this or is going to drive this. I see tablets that are already about the same price as a console. But you are spot on with the other points. They can (and do) mitigate the connection issue with various docks (notably MHL standard is pushing enough for remote media experience at least), but the game playing from the couch use case is not on the radar.
I would also add to the list extreme consistency. The dedicated home video game console market has never had more than 3 mainstream models at a time. A game developed for PS3 will have the same experience on a brand new as a 4 year old model. No RAM upgrades, no clockspeed or GPU bumps. Consumer only has to sweat the "is it xbox 360?' sort of question instead of 'how many cores, what clockspeed, ram amount, os type and version?'.
I would note that the handheld segment could be at some risk, they can't have more horsepower than a cell phone and people are a bit more selective about how much stuff they will carry on their person. I think they will be kept alive to some extent by being designed for gaming. The control scheme is critical, and one good for a lot of game playing would be too intrusive on a phone.
Across the board, when faced with relatively high unemployment and no strong indication of that correcting itself, the answer is *not* to make it easier for employers to stretch a workforce thinner, causing fewer people to work longer hours. If anything, should take action that encourages more workers employed with fewer hours. Create a tendency for more people to be employed and for the pay to be more evenly distributed...
Yes, 90% of my stuff is irrelevant. I can tell from the subject line most of the time. I generally ignore it and it doesn't take time out of my day to deal with it. I leave it on the server and in the off chance I was wrong, a phone call or chat has me with a place to delve into the history. Bonus: I can read the most recent update and largely ignore the leadup.
The issues around chat style interfaces: -BCC is sometimes critical. e.g. you have to get something to your boss for reference but do not want them pulled into some silly discussion -Asynchronous communication amongst a bunch of people. If a guy in China wants to have a discussion with people in europe and the US, chat works poorly -It's harder to ignore the 'meat' of messages that aren't pertinent to you.
No matter what, people *will* subject you to irrelevant communication. You have to pick the medium that lets you manage that most efficiently.
If we were to accept a binary format, then at least it shouldn't be from a group that says up front:
At this point we have no intention to standardize the format and we take the liberty to alter it as we see fit. We might document the on-disk format eventually, but at this point we don’t want any other software to read, write or manipulate our journal files directly.... we don’t want any other software to read, write or manipulate our journal files directly
This is absolutely unacceptable for projects in *nix land intending to serve such a central role as logging.
Reading the actual original document, I don't think it focuses so much on security. But to the extent it does, it's pretty pointless. They make noise about an authenticated chain of entries so you can't just modify the middle, *but* that provides no benefit as the attacker can then just rebuild the chain from that point forward. Their answer is to send it to some place that cannot be modified once transmitted. This is exactly the same as remote syslog policies, no additional security, but added complexity for no gain.
Additionally, they *could* have a system with plaintext and a binary format in place and I recommend they change their minds to do so. The binary blob can contain offsets into a corresponding text file. Thus the good old unix way (which the systemd people seem intent on destroying) is preserved while at the same time get their enhancements.
They *do* have some valid points. Syslog can't cope with binary data, it doesn't provide a good per-user logging facility, large text files are hard to search, and syslog has insufficient service/event type facilities making complex analysis a requirement in some scenarios. Even in a simplistic case, I have been left at a loss for 'what string *should* I grep for?' Many services ignore syslog because of it's limitations as pointed out in the artcile, making things that much more complicated.
But at the exact same time they bemoan so many services doing different logging, they propose making yet another facility and recommend keeping rsyslog running because they aren't going to handle syslog messages. They tell people 'tough you have to use systemd' and 'tough you must use our logging'.
They dismiss java-style namespace management due to variable width, which I think is just going *too* far to acheive theoretical performance gains. They get *very* defensive about UUIDs, and I accept when managed correctly they are unique, *but* it adds a layer of obfuscation unless you have a central coordinating master map of UUID to actual usable names. Uniqueness is an insufficient criteria. Have both worlds. An application submits a message with both a human-readable namespace *and* a UUID. If your logging facility already has the UUID, ignore the namespace. If your hash table does not have that UUID, store a mapping between the UUID and namespace. Then your tool has the added bonus of having a way to dump a quick list of currently observed message types to search by.
I have seen a number of applications do GPGU because it has a *lot* of theoretical potential. I saw quite a few places spend a lot of money assuming they'd sort it out. Most (not all) found that the advertised benefit was not feasible to use with their workload. In some cases it was because the development cost was high, but in many cases they found they really *couldn't* execute in that context no matter the cost.
From the other end, even Intel is making great strides in CPU capability. When people painfully started doing transcode on GPGPU, they made some pretty dramatic results. Then Sandy Bridge brought a transcoding engine along that blew all the GPGPU transcode work out of the water. Despite having indisputably weak GPUs, they are able to deliver potent responses to GPGPU usage of the GPU chips.
Either way, GP-GPU has no bearing on Bulldozer, the architecture doesn't seem particularly more amenable to GPGPU. With Bulldozer, AMD is gambling that somehow (between Piledriver and OS advances) that the limitations hurting their performance today will be alleviated. Intel had a similar sort of behavior around Netburst (except with an assumption of IA64 taking over as a long term strategy), and it didn't pan out for them. It may or may not pan out for AMD.
Don't forget, Intel's very successful Core 2 Duo came from a previous design (Pentium M) that had been reserved to laptops
That was a bit of a special case. It's not a testament of how fundamentally awesome low power processors are, and more of a illustration of *just* how bad NetBurst was. The Pentium M skipped NetBurst entirely because they *couldn't* make it work acceptably in a mobile device.
*Usually* the low power parts optimize for overall wattage and *not* performance per watt. If they can get 25% more performance but at 10% more power, a desktop context may elect to do it and a mobile may elect not to.
one of them - which is being revamped from #3 supercomputer position of the world - will be #1 supercomputer of the world when complete ?
You mean Jaguar, which is adding nVidia Tesla GPUS, memory, and refreshing the cluster interconnect while also doing Bulldozer? Where the Bulldozers are replacing Istanbul processors and *not* Magny-Cours? Even amongst the Magny-Cours in the top, they are 8-core not 12-core. Even for HPC there is some thought that 12-core will outperform Bulldozer due to shared FPU for many workloads, *but* GPUs are becoming the vogue way of doing that stuff anyway.
As others have pointed out, processors matter, but everything else matters *more* per dollar. Cray is a surprisingly small company that can't change their architecture (HTX IO oriented, IIRC) on a whim and even if Intel provides some boost in theory, it's not an effort they can afford.
Though I'm suspicious that Bulldozer is going down remarkably like NetBurst (NetBurst made design compromises for marketable massive clock gains, Bulldozer similarly makes compromises to boost the now-marketable core count) and time may prove that wrong, but this article was crap.
It looked like they cherry picked some benchmarks from the world at large with no control. As pointed out in the article, the tpmC benchmark had massive storage differences and the cost delta means there were probably node count differences. There are so many things in play that it is impossible to derive any sort of statement specifically about the processors. The article, however uses that as a point to show AMD is more expensive to make AMD look bad but in the same breath says better SSDs probably drove the benefit to steal AMD's thunder. He can't have it both ways. I'm inclined to believe the storage architecture was the key in terms of cost and performance given the nature of the test.
Later, the article says AMD should have just done 16-core Magny-Cours. Clearly AMD should hire him as he is a genius who *must* have considered all the complexities and figured out a way to achieve that core density when no one else in the industry has. No one pretends for a second that a bulldozer module matches 2 'real' cores, but they can't just wave their wand and make a 16-core package of the old architecture. Bulldozer is all about trying to ascertain the 'important' bits of a core and share other bits in the hopes the added resource gives most of the benefit of an additional core without the downsides that make it impossible to do that many cores on a socket.
My point is that projects *like* linux forced their hand, but then they realized that 'outsourcing' the work by contributing it upstream is actually easier and not giving up anything 'important'. I doubt this realization would have occurred otherwise.
OSX isn't exactly a shining example of a company giving everything back. Sure, the 'boring' foundation stuff gets up, but the larger body of code that they actually perceive as 'valuable', they keep to themselves (else we would have another somewhat sane OSS implementation of Cocoa/Quartz stuff).
Well, I meant only in the redistributable scenario, since otherwise there is no difference between BSD and GPL from a practical perspective. I presume that Tanenbaum makes the same simplification.
Do you think for a second that the likes of IBM would *ever* have contributed back to FreeBSD if that had been the 'winner'? No way, they would have taken it for themselves and kept it private. For the early life of linux, this was largely a moot point as the community was largely comprised of enthusiasts and the logistics of how the community was managed mattered more than licensing, but as things progressed into the 2000s, the GPL did have an impact as more and more commercial users were forced to adopt a particular behaviour with respect to contributions.
The point is not whether or not he 'should have known better at the time', the point is even today he refuses to concede that Linux has gotten as far it has due to something more than 'dumb luck'.
I think that would be a hard sell. You employ a system that has a very real risk of rendering your data useless to yourself with the only added benefit of password being of no use in the event of an unclean shutdown. Given that a strong password is only a 'weakness' if you are in a scenario where you are compelled to surrender it, the mechanism doesn't add significant security in the event of industrial espionage or a foreign government taking just your equipment without access or ability to force you to reveal the password. If they *did* have you and didn't care about your rights, you'd probably either suffer greatly as they won't believe you and continue whatever they are doing or surrender the data (e.g. whatever you have in your head, ignoring storage on the computer). Aside from a legal seizure of equipment in pursuit of a criminal case, I don't see the 'benefit' of such a system.
Linux was behind, but generally expressed a more practical set of sensibilities that caused the relevant bits to catch up and pass BSD a bit quickly.
All of them sucked on driver support, but I seem to recall Linux tending to getting more drivers more quickly than BSD. Some of the quality was less than stellar, but there was a willingness to go with something that mostly worked and refine it in the larger community. This sort of approach was pretty well required to work as a software platform running without the cooperation of the hardware platform you are on.
GPL may have scared off companies in the beginning and maybe even a few to this day, but the value of companies that would reject GPL and embrace BSD is rather low to the community. GPL forced the companies that *did* use it to contribute back. BSD-only companies felt any and all work they did was theirs and theirs alone and BSD upstream didn't benefit. Over time, it's snowballed and most successful companies cannot ignore the benefits of Linux. It may be common sense now that their is lower maintenance cost of submitting it upstream even if not required by license, but had GPL never made waves, the 'keep your code to yourself or else' mindset may have persisted.
I don't understand how one can say BSDI suit could do anything much for Linux. The suit did not preclude the creation of FreeBSD/NetBSD and thus Linux and BSD both had opportunity. If the claim is that BSDI lent some sort of credibility/support, during that time Linux had none of that either (Red Hat didn't even technically have an offering until 94, and I would say it wasn't worth taking seriously until '97 or so).
Whatever went 'right' for Linux and 'wrong' for BSD had nothing to do with that suit.
Slashdot Mirror
I can already type very fast on my on-screen keyboard without the need for silly tactile gadgets, and haptic feedback exists for the folks who aren't able to do so.
I wonder how "very fast" you type and how that rates relative to others. Whether it be that you have superhuman abilities to type faster without this sort of capability or you deem your speed to be 'fast enough', either way there are portions of the population that do either do not have your ability or are not satisfied as easily.
For one, I need the tactile feedback because the feedback enables me to move with more confidence. Haptic feedback is little more than a gimmick, I need to feel the different keys. Also, I let my unused fingers largely rest on the keys. I can't touch-type on a touchscreen because my stray fingers are constantly triggering stray keypresses.
I'm still not crazy about this even if it works as designed. Changing between text entry and non-text entry become a bit more cumbersome and it's a switch I make constantly. Laptops continue to be my favored strategy for this and a number of reasons, but the problems they are trying to address are an issue for a lot of people.
The issue being that with the plans with discounted phones, the subsidy is baked into the plan. To say a cell phone associated with a such a plan is indicitave if the realistic retail price of a tablet *not* tied to a carrier would be silly.
A number of people have indicated this may be an off-contract price, but pointed to devices that have such incredibly crippled specs that couldn't possibly drive a pixel count appropriate for a larger screen.
You made a $70 dollar downpayment and will be paying off the phone over the next two years.
I concur on idle, but on the 'web 2.0' functions, I really haven't noticed a downside in the long run. I have to confess creating a comment is far less intrusive than it was before and the structure for discussions hasn't changed too much. I will say sometimes the filtering has unfortunate consequences compared to old days (e.g. comments that are in reply to something modded into oblivion have no visual cue indicating they are a reply to anything instead of a top level post, leaving me sometimes scratching my head at the impetus for a post before realizing they must have been replying to someone).
They already 'learned' a lesson:
New technology *will* destroy your business model, so destroy the technology while you still have power!
I want to say I enjoy slashdot as one of the few sites actually implementing a nice and full threaded discussion system. We aren't talking about obsolescence, but rather a preference. Too many discussion systems either reorder posts, support no or one level of reply, and other such silly limitations.
Aside from that, the quality of commentators tends to be higher. More often than not, someone related to or very keenly aware of the subject of a story chimes in with additional data whereas most other forums explode in a barrage of inane chatter, trolls and woefully misinformed people. Yes, slashdot is subjected to that as well *but* if we are grading on a curve here, slashdot's community comes out pretty good.
In terrestial radio, you have maybe 6-10 distinct things to watch/record at given point of time.
If you pay a *whole* lot more for satellite or cable, you get one order of magnitude more stuff to watch at a given point of time. If left to 'surf', this is also 10 times more work to trudge through.
In order to watch something I like, I can either align my schedule to it or have my PVR attempt to record it only to get out of sync due to a baseball game (or else have them cancel that showing entirely, which means no way of watching what I wanted whether I liked the baseball game or not). The logistics of broadcast television are a pain with PVR as a hackish workaround.
Meanwhile, any arbitrary video stream accessible from hulu, youtube, or netflix out of *thousands* is immediately available, not tied up in arbitrary 'channels', not bound to a restricted broadcast medium.
I suppose the only thing that's missing is the 'I don't know what to watch so just spew something at me'. Hulu desktop almost does this but generally just throws movie trailers at me. Something like Pandora mechanics would probably outdo television for a contiguous stream of stuff that keeps me engaged, since a television channel frequently has no theme consistency timeslot-to-timeslot.
That was done frequerntly if I recall right. I think on occasion the 'stop the turbolift' conversations didn't take more time than some 'let the turbolift go' conversations. Obviously turbolifts go to their destination, make whooshing sound effects, and open the doors when they detect conversation is over. 'Computer stop' was just a signal to cut the sound effects.
I've made the same request before and I'll make it again.
Give me some way to search window titles to filter the window preview. KDE does this, compiz does this. I have lots of windows and searching with keyboard would be nice.
Mouseover an application icon in the 'activities' view should filter away windows not belonging to that icon and make the windows belonging to that app take up the full screen.
KDE 4.7+Icon Tasks has been a fairly decent experience though. I wish the single window and multi-window case of an application behaved more similarly though. If I click on an icon with only one window, it toggles minimize. If multi-window, present windows. I can make the multi-window do minimize toggle, but I actually kind of want the converse change...
I don't think price is driving this or is going to drive this. I see tablets that are already about the same price as a console. But you are spot on with the other points. They can (and do) mitigate the connection issue with various docks (notably MHL standard is pushing enough for remote media experience at least), but the game playing from the couch use case is not on the radar.
I would also add to the list extreme consistency. The dedicated home video game console market has never had more than 3 mainstream models at a time. A game developed for PS3 will have the same experience on a brand new as a 4 year old model. No RAM upgrades, no clockspeed or GPU bumps. Consumer only has to sweat the "is it xbox 360?' sort of question instead of 'how many cores, what clockspeed, ram amount, os type and version?'.
I would note that the handheld segment could be at some risk, they can't have more horsepower than a cell phone and people are a bit more selective about how much stuff they will carry on their person. I think they will be kept alive to some extent by being designed for gaming. The control scheme is critical, and one good for a lot of game playing would be too intrusive on a phone.
Across the board, when faced with relatively high unemployment and no strong indication of that correcting itself, the answer is *not* to make it easier for employers to stretch a workforce thinner, causing fewer people to work longer hours. If anything, should take action that encourages more workers employed with fewer hours. Create a tendency for more people to be employed and for the pay to be more evenly distributed...
Yes, 90% of my stuff is irrelevant. I can tell from the subject line most of the time. I generally ignore it and it doesn't take time out of my day to deal with it. I leave it on the server and in the off chance I was wrong, a phone call or chat has me with a place to delve into the history. Bonus: I can read the most recent update and largely ignore the leadup.
The issues around chat style interfaces:
-BCC is sometimes critical. e.g. you have to get something to your boss for reference but do not want them pulled into some silly discussion
-Asynchronous communication amongst a bunch of people. If a guy in China wants to have a discussion with people in europe and the US, chat works poorly
-It's harder to ignore the 'meat' of messages that aren't pertinent to you.
No matter what, people *will* subject you to irrelevant communication. You have to pick the medium that lets you manage that most efficiently.
If we were to accept a binary format, then at least it shouldn't be from a group that says up front:
At this point we have no intention to standardize the format and we take the liberty to alter it as we see fit. We might document the on-disk format eventually, but at this point we don’t want any other software to read, write or manipulate our journal files directly. ... we don’t want any other software to read, write or manipulate our journal files directly
This is absolutely unacceptable for projects in *nix land intending to serve such a central role as logging.
Reading the actual original document, I don't think it focuses so much on security. But to the extent it does, it's pretty pointless. They make noise about an authenticated chain of entries so you can't just modify the middle, *but* that provides no benefit as the attacker can then just rebuild the chain from that point forward. Their answer is to send it to some place that cannot be modified once transmitted. This is exactly the same as remote syslog policies, no additional security, but added complexity for no gain.
Additionally, they *could* have a system with plaintext and a binary format in place and I recommend they change their minds to do so. The binary blob can contain offsets into a corresponding text file. Thus the good old unix way (which the systemd people seem intent on destroying) is preserved while at the same time get their enhancements.
They *do* have some valid points. Syslog can't cope with binary data, it doesn't provide a good per-user logging facility, large text files are hard to search, and syslog has insufficient service/event type facilities making complex analysis a requirement in some scenarios. Even in a simplistic case, I have been left at a loss for 'what string *should* I grep for?' Many services ignore syslog because of it's limitations as pointed out in the artcile, making things that much more complicated.
But at the exact same time they bemoan so many services doing different logging, they propose making yet another facility and recommend keeping rsyslog running because they aren't going to handle syslog messages. They tell people 'tough you have to use systemd' and 'tough you must use our logging'.
They dismiss java-style namespace management due to variable width, which I think is just going *too* far to acheive theoretical performance gains. They get *very* defensive about UUIDs, and I accept when managed correctly they are unique, *but* it adds a layer of obfuscation unless you have a central coordinating master map of UUID to actual usable names. Uniqueness is an insufficient criteria. Have both worlds. An application submits a message with both a human-readable namespace *and* a UUID. If your logging facility already has the UUID, ignore the namespace. If your hash table does not have that UUID, store a mapping between the UUID and namespace. Then your tool has the added bonus of having a way to dump a quick list of currently observed message types to search by.
I have seen a number of applications do GPGU because it has a *lot* of theoretical potential. I saw quite a few places spend a lot of money assuming they'd sort it out. Most (not all) found that the advertised benefit was not feasible to use with their workload. In some cases it was because the development cost was high, but in many cases they found they really *couldn't* execute in that context no matter the cost.
From the other end, even Intel is making great strides in CPU capability. When people painfully started doing transcode on GPGPU, they made some pretty dramatic results. Then Sandy Bridge brought a transcoding engine along that blew all the GPGPU transcode work out of the water. Despite having indisputably weak GPUs, they are able to deliver potent responses to GPGPU usage of the GPU chips.
Either way, GP-GPU has no bearing on Bulldozer, the architecture doesn't seem particularly more amenable to GPGPU. With Bulldozer, AMD is gambling that somehow (between Piledriver and OS advances) that the limitations hurting their performance today will be alleviated. Intel had a similar sort of behavior around Netburst (except with an assumption of IA64 taking over as a long term strategy), and it didn't pan out for them. It may or may not pan out for AMD.
Don't forget, Intel's very successful Core 2 Duo came from a previous design (Pentium M) that had been reserved to laptops
That was a bit of a special case. It's not a testament of how fundamentally awesome low power processors are, and more of a illustration of *just* how bad NetBurst was. The Pentium M skipped NetBurst entirely because they *couldn't* make it work acceptably in a mobile device.
*Usually* the low power parts optimize for overall wattage and *not* performance per watt. If they can get 25% more performance but at 10% more power, a desktop context may elect to do it and a mobile may elect not to.
one of them - which is being revamped from #3 supercomputer position of the world - will be #1 supercomputer of the world when complete ?
You mean Jaguar, which is adding nVidia Tesla GPUS, memory, and refreshing the cluster interconnect while also doing Bulldozer? Where the Bulldozers are replacing Istanbul processors and *not* Magny-Cours? Even amongst the Magny-Cours in the top, they are 8-core not 12-core. Even for HPC there is some thought that 12-core will outperform Bulldozer due to shared FPU for many workloads, *but* GPUs are becoming the vogue way of doing that stuff anyway.
As others have pointed out, processors matter, but everything else matters *more* per dollar. Cray is a surprisingly small company that can't change their architecture (HTX IO oriented, IIRC) on a whim and even if Intel provides some boost in theory, it's not an effort they can afford.
Though I'm suspicious that Bulldozer is going down remarkably like NetBurst (NetBurst made design compromises for marketable massive clock gains, Bulldozer similarly makes compromises to boost the now-marketable core count) and time may prove that wrong, but this article was crap.
It looked like they cherry picked some benchmarks from the world at large with no control. As pointed out in the article, the tpmC benchmark had massive storage differences and the cost delta means there were probably node count differences. There are so many things in play that it is impossible to derive any sort of statement specifically about the processors. The article, however uses that as a point to show AMD is more expensive to make AMD look bad but in the same breath says better SSDs probably drove the benefit to steal AMD's thunder. He can't have it both ways. I'm inclined to believe the storage architecture was the key in terms of cost and performance given the nature of the test.
Later, the article says AMD should have just done 16-core Magny-Cours. Clearly AMD should hire him as he is a genius who *must* have considered all the complexities and figured out a way to achieve that core density when no one else in the industry has. No one pretends for a second that a bulldozer module matches 2 'real' cores, but they can't just wave their wand and make a 16-core package of the old architecture. Bulldozer is all about trying to ascertain the 'important' bits of a core and share other bits in the hopes the added resource gives most of the benefit of an additional core without the downsides that make it impossible to do that many cores on a socket.
Sure thing, it's fe80::0011:22ff:fe04:0506.
My point is that projects *like* linux forced their hand, but then they realized that 'outsourcing' the work by contributing it upstream is actually easier and not giving up anything 'important'. I doubt this realization would have occurred otherwise.
OSX isn't exactly a shining example of a company giving everything back. Sure, the 'boring' foundation stuff gets up, but the larger body of code that they actually perceive as 'valuable', they keep to themselves (else we would have another somewhat sane OSS implementation of Cocoa/Quartz stuff).
Well, I meant only in the redistributable scenario, since otherwise there is no difference between BSD and GPL from a practical perspective. I presume that Tanenbaum makes the same simplification.
Do you think for a second that the likes of IBM would *ever* have contributed back to FreeBSD if that had been the 'winner'? No way, they would have taken it for themselves and kept it private. For the early life of linux, this was largely a moot point as the community was largely comprised of enthusiasts and the logistics of how the community was managed mattered more than licensing, but as things progressed into the 2000s, the GPL did have an impact as more and more commercial users were forced to adopt a particular behaviour with respect to contributions.
The point is not whether or not he 'should have known better at the time', the point is even today he refuses to concede that Linux has gotten as far it has due to something more than 'dumb luck'.
I think that would be a hard sell. You employ a system that has a very real risk of rendering your data useless to yourself with the only added benefit of password being of no use in the event of an unclean shutdown. Given that a strong password is only a 'weakness' if you are in a scenario where you are compelled to surrender it, the mechanism doesn't add significant security in the event of industrial espionage or a foreign government taking just your equipment without access or ability to force you to reveal the password. If they *did* have you and didn't care about your rights, you'd probably either suffer greatly as they won't believe you and continue whatever they are doing or surrender the data (e.g. whatever you have in your head, ignoring storage on the computer). Aside from a legal seizure of equipment in pursuit of a criminal case, I don't see the 'benefit' of such a system.
Linux was behind, but generally expressed a more practical set of sensibilities that caused the relevant bits to catch up and pass BSD a bit quickly.
All of them sucked on driver support, but I seem to recall Linux tending to getting more drivers more quickly than BSD. Some of the quality was less than stellar, but there was a willingness to go with something that mostly worked and refine it in the larger community. This sort of approach was pretty well required to work as a software platform running without the cooperation of the hardware platform you are on.
GPL may have scared off companies in the beginning and maybe even a few to this day, but the value of companies that would reject GPL and embrace BSD is rather low to the community. GPL forced the companies that *did* use it to contribute back. BSD-only companies felt any and all work they did was theirs and theirs alone and BSD upstream didn't benefit. Over time, it's snowballed and most successful companies cannot ignore the benefits of Linux. It may be common sense now that their is lower maintenance cost of submitting it upstream even if not required by license, but had GPL never made waves, the 'keep your code to yourself or else' mindset may have persisted.
I don't understand how one can say BSDI suit could do anything much for Linux. The suit did not preclude the creation of FreeBSD/NetBSD and thus Linux and BSD both had opportunity. If the claim is that BSDI lent some sort of credibility/support, during that time Linux had none of that either (Red Hat didn't even technically have an offering until 94, and I would say it wasn't worth taking seriously until '97 or so).
Whatever went 'right' for Linux and 'wrong' for BSD had nothing to do with that suit.