You do know that by "monitoring" they mean "recording", and by "may be" they mean "100% will be". Even small companies can afford a call recording system for their support lines. It would be remiss of Tesla not to record calls, particularly after enabling all the stats logging in the car for media reviews.
Yes, the ball is back in Musk's court, and we will now find out if they record their support calls. We will also hopefully find out where that charge went overnight.
Read the linked story. That was just one of the lies Musk alleges the journalist wrote. The reason the journalist got stranded was because he didn't charge the car enough to actually do the intended journey. That's like putting a gallon of gas into a car to drive 100 miles.
That's a recharge every three hours. Given that drivers are recommended to take a break every two hours, it's not so unreasonable as long as there is a rapid recharge point to take a break at. But yes, it's not like refilling at a gas station.
They're only worth that much because they're in space. But they're only potentially worth that much once there are space refineries and space manufacturing plants, to make use of the materials, turn them into useful things and then put those things together. The risk is that by the time these things exist, other sources of the materials have been captured in space as well, reducing the value of the first set of captured stuff. Of course, the refinery will be attached to the rock it is refining, so that will make that rock more valuable.
I hate those, they're totally pointless. "I'm possibly doing something, I don't know how much of it I've done, and I don't know when it will end, and I won't show you when I started".
To be honest, progress bars shouldn't be used for indeterminate timescales. If you can guess a time remaining, then say that, as this can be changed, and it is visually more useful than a context-less progress bar that can go in reverse.
That's because you're in the US, and as the post says, there's a short delay there whilst they process the required paperwork (import related?). I see the ordering page for the Model A, so it's available.
And the deprecation is not linear. It probably loses half its value every year, to the extend that most accountants would zero-value it after 4 years.
And old Athlon X2 PC is valueless, it has virtually no resale value. The biggest problem is that being old technology, it might cost more to run it for a couple of years than to buy a new low power system and run that.
There are many problems with the analysis, and using it for your own personal decision. Of the top of my head...
1) You can get virtual Minecraft server hosting for a lot cheaper, if that's all you want. 2) His electricity is really cheap, that is not the case elsewhere. 3) Availability of hardware in the house that is easily refactored for the desired use. 4) Is that hardware in the long term actually viable compared to buying a new low power SFF system to run your server? Why use the old 150W PC when you could have a 30W PC and the power savings from that (especially if your electricity costs are not as low as his). 5) Do you need to run it 24/7? 6) Is your upstream bandwidth enough to handle server clients from outside the home? 7) What do you actually need to run a headless Minecraft server, in terms of resources, for expected number of clients?
Very true, the GPU (Videocore IV) is disproportionately powerful. Then again the ARM core is more of an afterthought, as the GPU is capable of running as a CPU itself.
I thought that the RPi came with hardware acceleration for the graphics. Maybe it needs installing, or maybe you have an aversion to binary blobs?
Maybe you should try a lower resolution first before whining. 1600x900 on a 700MHz ARM11, Sheesh, even with GPU acceleration a $5 SoC like the RPi uses would struggle. What is it like at 1280x720? Or in a window? Is there a pixel doubled mode? If the performance improves at lower resolutions, then it's not vertex processing bound, but rendering bound.
There's a reason the base raspberry pi is $15. It's not a powerhouse.
It's impressive that Minecraft has been made to run on it. I presume it is based off the C Android version rather than the Java desktop version, and the graphics have been tuned down, as well as game features.
Even with the overclocking feature, you still only have a 900-1000MHz ARM11, which isn't very powerful by today's standards (although twice as powerful as my first Android phone, the HTC Hero).
The RPi Minecraft does have the interesting scriptable interface though, which is very interesting for programmatically generated worlds.
I wonder if Broadcom now have a more powerful SoC that could be used in a next generation RPi. I guess they don't want to ever move the price upwards, so the potential component prices have to drop to be suitable for inclusion.
Of course it made no sense to measure hard drive capacity using base 2, once you had accounted for the block size (512 bytes).
Simple unit cancellation for a standard hard drive's geometry of platters, tracks and sectors, which aren't measured in base 2.
e.g., (1000 tracks * 2 sides * 49 sectors/track) = 98000 sectors per drive.
* 512 bytes/sector = 49000 KiB per drive, advertised as 49MB.
I guess we should use kKiB (kilo-kilobyte) to be accurate, or MKiB, or GKiB. That's not likely though. But dividing by 1000 until you get a catchy number is not wrong once you've factored out the blocksize.
On the PC, using high density floppies: 160 tracks * 2 sides * 9 sectors/track * 512 bytes / sector = 1,474,560 bytes. The accurate capacity is 2,880 blocks, where a block is 512 bytes.
(or on the Amiga using double density floppies, 80*2*11*512 = 901,120 bytes). Most accurately, the capacity is 1,760 blocks.
The only base 2 thing there is the block size. But because the block size is quite significant, PC floppies had the accurate capacity measurement of 1440KB (or KiB if you're petty about this thing, but KiB didn't exist back then).
And yes, you can extend this to mechanical hard drives. (Numbers pulled from/dev/random) 100,000 tracks * 6 sides * 1001 sectors/track * 512 bytes/sector = 600,600,000 blocks = 300,300,000 KiB. But you can't really take it any further accurately because you can't continue dividing by 1024 and getting a nice integer number. So do you advertise this as a 300GB hard drive, or a 286GiB hard drive? Note that it makes no sense to divide by 1024 any further, as we're dividing quantities of tracks, sides and sectors.
So what that back in the day the computer scientists hijacked kilo/mega/giga because 2^10/2^20/2^30 was close enough to 10^3/10^6/10^9?
Sure, there's a standard now, the unpopular KiB/MiB/GiB, but no-one uses it.
Regardless, the number that should be reported when describing capacity should be the base 2 number when talking about RAM - as RAM is by its nature a base 2 capacity mechanism. The capacity can be described exactly this way.
But for hard drives, where the storage is in effect linear across multiple cylinders, heads, etc, is base 2 what should be used - ignoring historical usage? Well, block sizes are in powers of two... but we don't have a power of two number of blocks. We therefore don't have a capacity number that can be described totally accurately using the base 2 numbering system.
And SSDs? Due to bad blocks, and reserved storage area, we are turning something that was a base 2 capacity memory system into something with less capacity.
And what about the files themselves? They're not powers of two in size, and indeed they waste capacity at the end of the file because the basic unit of storage in a drive is the formatted block size (512 bytes, 4KB, etc). Maybe block based systems should be advertised as offering "2 Billion Formatted Blocks* (* 512 byte blocks)"! In addition that file is likely compressed in some way that you can't consider that it will use the same space in memory when loaded.
A strong argument is that because computer RAM is xGB, meaning x * 2^9 bytes, then we should use the same unit for other things in a computer that are expressed in GB, because in the end it is clearer to the user who can compare the two things, e.g., "the computer has 500 times more HD than RAM".
To provide a true cross-OS portable app framework, the use of HTML5, Javascript and CSS3 will become commonplace.
Where's Gnome in that? What you've described is a platform for applications to run upon, within a Browser Runtime. Google has even released an OS that is only a browser, with the above being the application runtime.
Gnome is a different, competing platform for applications to run upon, no browser required, but completely different APIs (UI, networking, I/O, etc). You will get nothing of the benefit of Javascript's browser libraries (unless you have something like browser = GnomeBrowser(); browser.run(webapp);) because they're irrelevant when you are using the Gnome Javascript Bindings.
Hmm, web programming is mostly web browser DOM manipulation, jQuery/similar, XML and JSON, all glued together with Javascript. Most web developers don't get any deeper into Javascript as a language than having lots of simple functions they call at various points. Using this as the primary basis for using Javascript as a primary language for a non-web-browser, non-DOM, non-JSON, non-XML, non-jQuery API like Gnome is quite an interesting decision.
iOS is mostly Objective C, which is not like Javascript. Maybe it's like Java after being mixed up with a billion square brackets. The API is specific to Apple of course, nothing can be applied to Gnome development.
Android is Java based, but again the main issue is that the Android APIs are useless for Gnome programming.
Doesn't matter, a good developer can pick up any language.
A better question is "which API should I learn". Javascript has a small API, and most web developers only know the DOM manipulation API, XML, JSON, jQuery or similar, etc. Main point is that the Gnome API is a different API from these, and developing Gnome Apps using Javascript means learning an entirely new API and dropping the one you know.
What Gnome should be doing is saying "come and learn the Gnome API, we have implementations for C, C++, Vala, Python, Java, Javascript, etc".
Slashdot Mirror
You do know that by "monitoring" they mean "recording", and by "may be" they mean "100% will be". Even small companies can afford a call recording system for their support lines. It would be remiss of Tesla not to record calls, particularly after enabling all the stats logging in the car for media reviews.
Yes, the ball is back in Musk's court, and we will now find out if they record their support calls. We will also hopefully find out where that charge went overnight.
Read the linked story. That was just one of the lies Musk alleges the journalist wrote. The reason the journalist got stranded was because he didn't charge the car enough to actually do the intended journey. That's like putting a gallon of gas into a car to drive 100 miles.
That's a recharge every three hours. Given that drivers are recommended to take a break every two hours, it's not so unreasonable as long as there is a rapid recharge point to take a break at. But yes, it's not like refilling at a gas station.
They're only worth that much because they're in space. But they're only potentially worth that much once there are space refineries and space manufacturing plants, to make use of the materials, turn them into useful things and then put those things together. The risk is that by the time these things exist, other sources of the materials have been captured in space as well, reducing the value of the first set of captured stuff. Of course, the refinery will be attached to the rock it is refining, so that will make that rock more valuable.
I hate those, they're totally pointless. "I'm possibly doing something, I don't know how much of it I've done, and I don't know when it will end, and I won't show you when I started".
To be honest, progress bars shouldn't be used for indeterminate timescales. If you can guess a time remaining, then say that, as this can be changed, and it is visually more useful than a context-less progress bar that can go in reverse.
That's because you're in the US, and as the post says, there's a short delay there whilst they process the required paperwork (import related?).
I see the ordering page for the Model A, so it's available.
I agree, there's the eMMC, and USB2. Not a patch on even plain old SATA, but if you don't need the absolute performance from the storage system...
Or there's waiting for the next ODROID which will surely be based around the Exynos 5.
This would probably suit you for your ARM server: http://hexus.net/tech/news/systems/51621-the-odroid-u2-17ghz-exynos-quad-core-raspi-rival/ you'll want an eMMC for the OS, but SATA is still an issue. Marvell might be a better SoC provider for that.
I don't think an Athlon X2 system was ever $2380!
And the deprecation is not linear. It probably loses half its value every year, to the extend that most accountants would zero-value it after 4 years.
And old Athlon X2 PC is valueless, it has virtually no resale value. The biggest problem is that being old technology, it might cost more to run it for a couple of years than to buy a new low power system and run that.
There are many problems with the analysis, and using it for your own personal decision. Of the top of my head...
1) You can get virtual Minecraft server hosting for a lot cheaper, if that's all you want.
2) His electricity is really cheap, that is not the case elsewhere.
3) Availability of hardware in the house that is easily refactored for the desired use.
4) Is that hardware in the long term actually viable compared to buying a new low power SFF system to run your server? Why use the old 150W PC when you could have a 30W PC and the power savings from that (especially if your electricity costs are not as low as his).
5) Do you need to run it 24/7?
6) Is your upstream bandwidth enough to handle server clients from outside the home?
7) What do you actually need to run a headless Minecraft server, in terms of resources, for expected number of clients?
There's a $25 model as well as a $35 model, or did you miss this?
Very true, the GPU (Videocore IV) is disproportionately powerful. Then again the ARM core is more of an afterthought, as the GPU is capable of running as a CPU itself.
Thanks for that, clearly the OP either has a badly configured Pi, some Pis are cranky, or he is just trolling.
YouTube should be filling up with RPi Minecraft videos right about now that disprove everything he's written anyway.
I thought that the RPi came with hardware acceleration for the graphics. Maybe it needs installing, or maybe you have an aversion to binary blobs?
Maybe you should try a lower resolution first before whining. 1600x900 on a 700MHz ARM11, Sheesh, even with GPU acceleration a $5 SoC like the RPi uses would struggle. What is it like at 1280x720? Or in a window? Is there a pixel doubled mode? If the performance improves at lower resolutions, then it's not vertex processing bound, but rendering bound.
Cool. Show us your multiplayer server that's better then? Let's just guess that the server is doing a massive amount of caching, because it can.
Also, this isn't based upon the desktop code, but the pocket edition code.
This is presumably forked from the C Android version, which is more optimised for lower power devices, at the cost of having fewer features.
$15! I meant $25, stupid cheap-ass work keyboard, and even stupider finger!
There's a reason the base raspberry pi is $15. It's not a powerhouse.
It's impressive that Minecraft has been made to run on it. I presume it is based off the C Android version rather than the Java desktop version, and the graphics have been tuned down, as well as game features.
Even with the overclocking feature, you still only have a 900-1000MHz ARM11, which isn't very powerful by today's standards (although twice as powerful as my first Android phone, the HTC Hero).
The RPi Minecraft does have the interesting scriptable interface though, which is very interesting for programmatically generated worlds.
I wonder if Broadcom now have a more powerful SoC that could be used in a next generation RPi. I guess they don't want to ever move the price upwards, so the potential component prices have to drop to be suitable for inclusion.
I live in 2013.
Of course it made no sense to measure hard drive capacity using base 2, once you had accounted for the block size (512 bytes).
Simple unit cancellation for a standard hard drive's geometry of platters, tracks and sectors, which aren't measured in base 2.
e.g., (1000 tracks * 2 sides * 49 sectors/track) = 98000 sectors per drive.
* 512 bytes/sector = 49000 KiB per drive, advertised as 49MB.
I guess we should use kKiB (kilo-kilobyte) to be accurate, or MKiB, or GKiB. That's not likely though. But dividing by 1000 until you get a catchy number is not wrong once you've factored out the blocksize.
(odd quantities of sectors was common)
1.44 * 1024 * 1000 byte
On the PC, using high density floppies: 160 tracks * 2 sides * 9 sectors/track * 512 bytes / sector = 1,474,560 bytes. The accurate capacity is 2,880 blocks, where a block is 512 bytes.
(or on the Amiga using double density floppies, 80*2*11*512 = 901,120 bytes). Most accurately, the capacity is 1,760 blocks.
The only base 2 thing there is the block size. But because the block size is quite significant, PC floppies had the accurate capacity measurement of 1440KB (or KiB if you're petty about this thing, but KiB didn't exist back then).
And yes, you can extend this to mechanical hard drives. (Numbers pulled from /dev/random) 100,000 tracks * 6 sides * 1001 sectors/track * 512 bytes/sector = 600,600,000 blocks = 300,300,000 KiB. But you can't really take it any further accurately because you can't continue dividing by 1024 and getting a nice integer number. So do you advertise this as a 300GB hard drive, or a 286GiB hard drive? Note that it makes no sense to divide by 1024 any further, as we're dividing quantities of tracks, sides and sectors.
So what that back in the day the computer scientists hijacked kilo/mega/giga because 2^10/2^20/2^30 was close enough to 10^3/10^6/10^9?
Sure, there's a standard now, the unpopular KiB/MiB/GiB, but no-one uses it.
Regardless, the number that should be reported when describing capacity should be the base 2 number when talking about RAM - as RAM is by its nature a base 2 capacity mechanism. The capacity can be described exactly this way.
But for hard drives, where the storage is in effect linear across multiple cylinders, heads, etc, is base 2 what should be used - ignoring historical usage? Well, block sizes are in powers of two... but we don't have a power of two number of blocks. We therefore don't have a capacity number that can be described totally accurately using the base 2 numbering system.
And SSDs? Due to bad blocks, and reserved storage area, we are turning something that was a base 2 capacity memory system into something with less capacity.
And what about the files themselves? They're not powers of two in size, and indeed they waste capacity at the end of the file because the basic unit of storage in a drive is the formatted block size (512 bytes, 4KB, etc). Maybe block based systems should be advertised as offering "2 Billion Formatted Blocks* (* 512 byte blocks)"! In addition that file is likely compressed in some way that you can't consider that it will use the same space in memory when loaded.
A strong argument is that because computer RAM is xGB, meaning x * 2^9 bytes, then we should use the same unit for other things in a computer that are expressed in GB, because in the end it is clearer to the user who can compare the two things, e.g., "the computer has 500 times more HD than RAM".
To provide a true cross-OS portable app framework, the use of HTML5, Javascript and CSS3 will become commonplace.
Where's Gnome in that? What you've described is a platform for applications to run upon, within a Browser Runtime. Google has even released an OS that is only a browser, with the above being the application runtime.
Gnome is a different, competing platform for applications to run upon, no browser required, but completely different APIs (UI, networking, I/O, etc). You will get nothing of the benefit of Javascript's browser libraries (unless you have something like browser = GnomeBrowser(); browser.run(webapp);) because they're irrelevant when you are using the Gnome Javascript Bindings.
Hmm, web programming is mostly web browser DOM manipulation, jQuery/similar, XML and JSON, all glued together with Javascript. Most web developers don't get any deeper into Javascript as a language than having lots of simple functions they call at various points. Using this as the primary basis for using Javascript as a primary language for a non-web-browser, non-DOM, non-JSON, non-XML, non-jQuery API like Gnome is quite an interesting decision.
iOS is mostly Objective C, which is not like Javascript. Maybe it's like Java after being mixed up with a billion square brackets. The API is specific to Apple of course, nothing can be applied to Gnome development.
Android is Java based, but again the main issue is that the Android APIs are useless for Gnome programming.
"what language should I learn"
Doesn't matter, a good developer can pick up any language.
A better question is "which API should I learn". Javascript has a small API, and most web developers only know the DOM manipulation API, XML, JSON, jQuery or similar, etc. Main point is that the Gnome API is a different API from these, and developing Gnome Apps using Javascript means learning an entirely new API and dropping the one you know.
What Gnome should be doing is saying "come and learn the Gnome API, we have implementations for C, C++, Vala, Python, Java, Javascript, etc".