Is that a world record using a mobile phone keyboard, like that on the DROID?
There's a massive difference between a full-size PC keyboard where you're using 8 fingers and a thumb at the same time, and ALL mobile phone keyboards, physical or virtual, where you use two thumbs.
Of course the OP does have rubbish full-size keyboard typing skills, but the point is still valid.
Reviews have put the DROID's on-screen keyboard as being far better than the physical keyboard it comes with.
Users have said that the onscreen keyboard on the iPhone is very usable once you are used to it. The correction it supplies makes it quite fast to use.
The on-screen keyboard on an iPhone is 2 inches away from the text box you are writing into, at most. It's very different.
This article is about a touch-mouse, not an onscreen keyboard.
I've never worried about the lack of a click when using a trackpad.
Indeed I believe the Apple mouse has tactile feedback in terms of having a full-body click anyway. Otherwise you would never be able to rest your fingers on the mouse when you were moving it.
The advantages of multitouch make things like wheels seem old school. Also I hate the fact that mousewheels click in discrete steps instead of being smoothly analogue-ish.
If Asus are paying $6 for Windows XP OEM, then surely Microsoft is dumping their product on the market? Probably why they're including it in their netbooks in favour of Linux.
Dumping product? Convicted monopolist? I think that there's a good chance here that some netbook OS vendors have a case here to make an official complaint about anti-competitive predatory tactics by Microsoft.
1) ARM version of Chrome OS - means $199 smartbooks instead of $299-$499 netbooks running Windows XP or Windows 7.
2) OS is free.
3) Actually Google might be offering a share of advertising revenue to manufacturers, as with Android. This means that the OS has a negative cost. We could see $149 smartbooks. Who is interested in a Windows 7 netbook at 3x the cost then?
4) Good enough for a second/cloud computer. Especially if it supports the "home cloud" with support for DNLA (media streaming) and other common home/office services.
However there are failings - firstly I think that Google need to make the OS Android compatible. I.e., installing the Dalvik VM and Android APIs by default. Android 2 allows higher resolutions. Android 3 will surely support resolutions up to smartbook (1024x600, 1366x768) and running an app as a tab within Chrome OS, allowing a unified platform. Surely therefore Chrome OS smartbooks will include multitouch displays...
Also Chrome OS 1 will surely be rough, like Android 1 and the G1. Droid is showing what Android 2 can do, and it's far more mature. Android 3 will probably be the first all-rounded and sweetly remembered variant. Android 4 will be good too. Android 5 through 7 will be dire.
I was really thinking about intact as in "will the building need to be pulled down afterwards" - I agree that the walls are more intact with this sheeting than not, and thus could prevent a building collapse, allowing people to get out instead of becoming pancakes.
I don't think this product is meant to protect against bullets. I'd suspect the brickwork it is attached to would do a better job of that.
This enabled a wall to flex under blast pressure, instead of exploding inwards. It is meant to save the lives of people inside. It isn't going to protect the building - it may still need to be demolished. But the people will get a chance to escape. Indeed it might keep load bearing walls intact enough to continue to bear a load for minutes longer, thus saving lives.
The job would just require taking a stanley knife and cutting the wallplastickevlar to disengage it from the floor/ceiling anchors that provide the tensile strength for the product to work effectively.
In a unionised industry that would be a valid job of course, requiring "knife use" qualifications and job protection.
In the real world, it'll take five minutes to make a room suitable for demolition.
Without: Building collapses, concertina effect. People are mushy pancakes. Happens quickly.
With: Building damaged seriously, vastly higher chance of no concertina effect (especially if on both sides of load bearing wall, so it can't flex back the other way, don't bomb blasts have an explosion, then a compression?). People not pancakes, nor sushi-fied from flying debris (windows excepted). Building may still collapse, but may happen a lot slower.
The videos clearly show that it isn't useful for keeping structure intact.
It's useful for limiting spread of masonry shrapnel by containing the walls.
So you have a bomb outside and it goes off, and the people inside the building (behind the walls - the ones behind glass are sushi regardless) will be better protected. The walls will still be destroyed.
They should develop a clear version for applying to glass, although for military uses I guess they wouldn't care about the X mesh, as the rest is clear-ish.
Easy CPU upgrades because the socket interface stay the same.
Some of those supoercomputers might have gone from dual-core 2GHz Opteron K8s through quad-core Opteron K10s to these new sexa-core Opteron K10.5s with only the need to change the CPUs and the memory.
Or possibly if the upgrades were done at a board level, HyperTransport has remained compatible, so your new board of 24 cores just slots into your expensive, custom, HyperTransport-based back-end. To switch to Intel would require designing a QPI-based back-end.
Of course Magny-Cours and Bulldozer will use the G34 socket, so that's not a plug-in and go upgrade when they come out in 2010 and 2011 respectively. But it will be a stable platform for several years itself, and thus be attractive.
Only recently AMD was clearing some debts for 30 cents on the dollar - i.e., the banks wanted money so bad that they allowed AMD to pay back one third of the amount they were willing to clear. AMD didn't have much spare money though, so they didn't clear much.
Imagine if AMD has another such offer on the table from their banks - they could clear far far more than the money they got from Intel. Getting the money now could have an overall net benefit greater than letting such a deal expire and getting a bit more from Intel in a couple of years. Never mind the interest payments they'll save paying them off now rather than in the future, even if there is no such deal.
I think putting everything behind them, getting freedom to manufacture as they like, and having a level playing field with the OEMs (sadly at a time when AMD's offerings aren't the shiniest) is more important to them.
It'll probably come with "Natal Play", a package of training mini-games that will let you down greatly, but will make the price seem a little more reasonable.
Let's face it, two 1MP cameras connected via USB isn't a lot of hardware. Most of the cost is in the software development, and if you can spread the cost over ten million purchasers and three Natal games each...
"Now a child who doesn't own a skateboard, and doesn't have the skills to ride a skateboard, will no longer have the ability to play a game involving skateboards."
You know, I press buttons on a controller because I can't actually fight/fly planes/race cars at 200mph/pilot spacecraft/do magic... don't take these away from me!
Java has StringBuilder (since 1.5, but as that release is now unsupported because it's so old I guess its a moot point).
But yes, SB is optimised for appending efficiently, and String is optimised for space and immutable operations.
Go appears to use += for String appending. I would hope that behind the scenes it is compiling to a StringBuilder type construct, rather than allocating a new string like with Java +=.
It's "Printf" because it's a public function. Private functions are in lower case.
Quite why they couldn't use a "public" or "private" (or "privfunc") keyword instead is another matter, but it's probably because they're trying to keep the code compact. Guess it could have been worse, could have been +printf for public, and -printf for private...
I find the lack of parenthesis in the for and if statements disturbing, especially as it mandates the braces for the following block. No more if (x) foo();, it's if x { foo() }.
The channels concept seems nice. The goroutines are a sensible feature for a common use case. The multiple return values is nice.
It needs an IDE at some point, or at least a code formatter for common IDEs/editors.
var s string = "foo" can be replaced with s:= "foo". Think of:= as "becomes".
This makes sense. Jython makes very good use of this.
I think a Java bytecode backend should be a rapid priority for the Go language programmers. I don't know how much of the Java runtime they can leverage to replace the minimal runtime they compile into the Go binaries at the moment though.
Also, because it is Google, a Dalvik compiler would make sense (for Android). This would be very similar in many ways to the Java backend.
As for go, it looks interesting, but it's currently a language, not a platform. I can see that changing down the line as more people develop the necessary frameworks (I see some basic collections, basic xml, etc are done already). Hopefully people will take the best of breed in any given area and use that, instead of half-assed implementations (e.g., port JodaTime instead of Java's Calendar as a date library). I can see that go is trying to make things simple in the common use case, and it also appears to have nicely compact source code (esp. compared with Java and C#!).
Audio is an optional component in mini-DisplayPort.
I presume that supporting audio would be done in the display output controller, so within the graphical portion of the computer (integrated within the 9400M, or discrete GPU). Maybe NVIDIA products don't support audio over DP themselves, or more likely Apple hasn't done the drivers to copy audio to the GPU from the audio controller for output via DP?
I meant a significantly cheaper, but slightly slower CPU.
To be fair, an ARM Cortex A9 outperforms Atom on a per-clock basis allegedly, and A8 compares well. However they'll be in $40 SoCs that include everything in one chip that requires several chips in the Intel solution, costing a lot more.
Venting? Vents controlled by sensors, and perhaps a backup of tearable membranes that tear open when pressure gets too high (or just a hinged panel that rests shut, and opens under a certain pressure, simplicity could win).
In summer when the dome is a greenhouse, hot air exiting the top via the vents will drag in cool air under the dome edge. I assume the dome edge isn't at ground level but metres or even tens of metres in the air, it's just the anchor lines that will connect to the ground). This could create a breeze even on still hot sultry days. Never mind the river that will surely be a climate regulator?
I would also hope that they had considered all of this back in 1979 when it was first thought up. Basics like keeping the device anchored and basic climate control would surely be the first thing considered with such a construction! Of course, what we see as common sense other people need to be told repeatedly...
Slashdot Mirror
Is that a world record using a mobile phone keyboard, like that on the DROID?
There's a massive difference between a full-size PC keyboard where you're using 8 fingers and a thumb at the same time, and ALL mobile phone keyboards, physical or virtual, where you use two thumbs.
Of course the OP does have rubbish full-size keyboard typing skills, but the point is still valid.
Reviews have put the DROID's on-screen keyboard as being far better than the physical keyboard it comes with.
Users have said that the onscreen keyboard on the iPhone is very usable once you are used to it. The correction it supplies makes it quite fast to use.
The on-screen keyboard on an iPhone is 2 inches away from the text box you are writing into, at most. It's very different.
This article is about a touch-mouse, not an onscreen keyboard.
I've never worried about the lack of a click when using a trackpad.
Indeed I believe the Apple mouse has tactile feedback in terms of having a full-body click anyway. Otherwise you would never be able to rest your fingers on the mouse when you were moving it.
The advantages of multitouch make things like wheels seem old school. Also I hate the fact that mousewheels click in discrete steps instead of being smoothly analogue-ish.
Hah, brilliant. Let's add a line to robots.txt saying "ignore content with these HTML IDs". Sounds useful to be honest.
Disallow: #articlebody
<div id="articlebody">Murdoch's trashy witterings</div>
could then be ignored, eradicated from the web, and thus save many innocent eyes from reading such gutter tripe.
If Asus are paying $6 for Windows XP OEM, then surely Microsoft is dumping their product on the market? Probably why they're including it in their netbooks in favour of Linux.
Dumping product? Convicted monopolist? I think that there's a good chance here that some netbook OS vendors have a case here to make an official complaint about anti-competitive predatory tactics by Microsoft.
Or the story is a load of rubbish.
Microsoft aren't considering:
1) ARM version of Chrome OS - means $199 smartbooks instead of $299-$499 netbooks running Windows XP or Windows 7.
2) OS is free.
3) Actually Google might be offering a share of advertising revenue to manufacturers, as with Android. This means that the OS has a negative cost. We could see $149 smartbooks. Who is interested in a Windows 7 netbook at 3x the cost then?
4) Good enough for a second/cloud computer. Especially if it supports the "home cloud" with support for DNLA (media streaming) and other common home/office services.
However there are failings - firstly I think that Google need to make the OS Android compatible. I.e., installing the Dalvik VM and Android APIs by default. Android 2 allows higher resolutions. Android 3 will surely support resolutions up to smartbook (1024x600, 1366x768) and running an app as a tab within Chrome OS, allowing a unified platform. Surely therefore Chrome OS smartbooks will include multitouch displays...
Also Chrome OS 1 will surely be rough, like Android 1 and the G1. Droid is showing what Android 2 can do, and it's far more mature. Android 3 will probably be the first all-rounded and sweetly remembered variant. Android 4 will be good too. Android 5 through 7 will be dire.
I was really thinking about intact as in "will the building need to be pulled down afterwards" - I agree that the walls are more intact with this sheeting than not, and thus could prevent a building collapse, allowing people to get out instead of becoming pancakes.
I don't think this product is meant to protect against bullets. I'd suspect the brickwork it is attached to would do a better job of that.
This enabled a wall to flex under blast pressure, instead of exploding inwards. It is meant to save the lives of people inside. It isn't going to protect the building - it may still need to be demolished. But the people will get a chance to escape. Indeed it might keep load bearing walls intact enough to continue to bear a load for minutes longer, thus saving lives.
I would suspect that the people near the bomb would be dead in that situation.
This product probably isn't designed for that use. Maybe it would reduce external shrapnel and protect bypassers.
The job would just require taking a stanley knife and cutting the wallplastickevlar to disengage it from the floor/ceiling anchors that provide the tensile strength for the product to work effectively.
In a unionised industry that would be a valid job of course, requiring "knife use" qualifications and job protection.
In the real world, it'll take five minutes to make a room suitable for demolition.
what if this is a load bearing wall?
Without: Building collapses, concertina effect. People are mushy pancakes. Happens quickly.
With: Building damaged seriously, vastly higher chance of no concertina effect (especially if on both sides of load bearing wall, so it can't flex back the other way, don't bomb blasts have an explosion, then a compression?). People not pancakes, nor sushi-fied from flying debris (windows excepted). Building may still collapse, but may happen a lot slower.
The videos clearly show that it isn't useful for keeping structure intact.
It's useful for limiting spread of masonry shrapnel by containing the walls.
So you have a bomb outside and it goes off, and the people inside the building (behind the walls - the ones behind glass are sushi regardless) will be better protected. The walls will still be destroyed.
They should develop a clear version for applying to glass, although for military uses I guess they wouldn't care about the X mesh, as the rest is clear-ish.
Easy CPU upgrades because the socket interface stay the same.
Some of those supoercomputers might have gone from dual-core 2GHz Opteron K8s through quad-core Opteron K10s to these new sexa-core Opteron K10.5s with only the need to change the CPUs and the memory.
Or possibly if the upgrades were done at a board level, HyperTransport has remained compatible, so your new board of 24 cores just slots into your expensive, custom, HyperTransport-based back-end. To switch to Intel would require designing a QPI-based back-end.
Of course Magny-Cours and Bulldozer will use the G34 socket, so that's not a plug-in and go upgrade when they come out in 2010 and 2011 respectively. But it will be a stable platform for several years itself, and thus be attractive.
http://blogs.amd.com/nigeldessau/2009/11/12/blog-77-a-time-for-peace/
No, Intel will not be doing any more OEM bullying.
Only recently AMD was clearing some debts for 30 cents on the dollar - i.e., the banks wanted money so bad that they allowed AMD to pay back one third of the amount they were willing to clear. AMD didn't have much spare money though, so they didn't clear much.
Imagine if AMD has another such offer on the table from their banks - they could clear far far more than the money they got from Intel. Getting the money now could have an overall net benefit greater than letting such a deal expire and getting a bit more from Intel in a couple of years. Never mind the interest payments they'll save paying them off now rather than in the future, even if there is no such deal.
I think putting everything behind them, getting freedom to manufacture as they like, and having a level playing field with the OEMs (sadly at a time when AMD's offerings aren't the shiniest) is more important to them.
It'll probably come with "Natal Play", a package of training mini-games that will let you down greatly, but will make the price seem a little more reasonable.
Let's face it, two 1MP cameras connected via USB isn't a lot of hardware. Most of the cost is in the software development, and if you can spread the cost over ten million purchasers and three Natal games each...
"Now a child who doesn't own a skateboard, and doesn't have the skills to ride a skateboard, will no longer have the ability to play a game involving skateboards."
You know, I press buttons on a controller because I can't actually fight/fly planes/race cars at 200mph/pilot spacecraft/do magic ... don't take these away from me!
Okay, this language is dead in the water, and dead to me.
Tabs are evil. Spaces are the one true way.
Java has StringBuilder (since 1.5, but as that release is now unsupported because it's so old I guess its a moot point).
But yes, SB is optimised for appending efficiently, and String is optimised for space and immutable operations.
Go appears to use += for String appending. I would hope that behind the scenes it is compiling to a StringBuilder type construct, rather than allocating a new string like with Java +=.
It's "Printf" because it's a public function. Private functions are in lower case.
Quite why they couldn't use a "public" or "private" (or "privfunc") keyword instead is another matter, but it's probably because they're trying to keep the code compact. Guess it could have been worse, could have been +printf for public, and -printf for private...
I find the lack of parenthesis in the for and if statements disturbing, especially as it mandates the braces for the following block. No more if (x) foo();, it's if x { foo() }.
The channels concept seems nice. The goroutines are a sensible feature for a common use case. The multiple return values is nice.
It needs an IDE at some point, or at least a code formatter for common IDEs/editors.
var s string = "foo" can be replaced with s := "foo". Think of := as "becomes".
This makes sense. Jython makes very good use of this.
I think a Java bytecode backend should be a rapid priority for the Go language programmers. I don't know how much of the Java runtime they can leverage to replace the minimal runtime they compile into the Go binaries at the moment though.
Also, because it is Google, a Dalvik compiler would make sense (for Android). This would be very similar in many ways to the Java backend.
Good luck with getting Perl more usable on Windows. I remember using ActiveState Perl back in the day...
How would you say Padre compares with the Eclipse Perl Perspective? http://www.epic-ide.org/
As for go, it looks interesting, but it's currently a language, not a platform. I can see that changing down the line as more people develop the necessary frameworks (I see some basic collections, basic xml, etc are done already). Hopefully people will take the best of breed in any given area and use that, instead of half-assed implementations (e.g., port JodaTime instead of Java's Calendar as a date library). I can see that go is trying to make things simple in the common use case, and it also appears to have nicely compact source code (esp. compared with Java and C#!).
Audio is an optional component in mini-DisplayPort.
I presume that supporting audio would be done in the display output controller, so within the graphical portion of the computer (integrated within the 9400M, or discrete GPU). Maybe NVIDIA products don't support audio over DP themselves, or more likely Apple hasn't done the drivers to copy audio to the GPU from the audio controller for output via DP?
Heh.
I meant a significantly cheaper, but slightly slower CPU.
To be fair, an ARM Cortex A9 outperforms Atom on a per-clock basis allegedly, and A8 compares well. However they'll be in $40 SoCs that include everything in one chip that requires several chips in the Intel solution, costing a lot more.
Venting? Vents controlled by sensors, and perhaps a backup of tearable membranes that tear open when pressure gets too high (or just a hinged panel that rests shut, and opens under a certain pressure, simplicity could win).
In summer when the dome is a greenhouse, hot air exiting the top via the vents will drag in cool air under the dome edge. I assume the dome edge isn't at ground level but metres or even tens of metres in the air, it's just the anchor lines that will connect to the ground). This could create a breeze even on still hot sultry days. Never mind the river that will surely be a climate regulator?
I would also hope that they had considered all of this back in 1979 when it was first thought up. Basics like keeping the device anchored and basic climate control would surely be the first thing considered with such a construction! Of course, what we see as common sense other people need to be told repeatedly...