It's an e-ink reader; it's supposed to be greyscale. While colour e-ink screens are now available, they're still *very* new technology, and not yet present in any currently shipping devices that I'm aware of.
Actually, if the Internet backbone ever reached exabit/sec speeds, the whole way we viewed data storage would change. I see no reason why most computers would need local storage at all.
Latency is why. It doesn't matter how fast the link to your storage is, if it's several ms away from you the delay gets annoying *real* fast.
You guys have a better product? Let's see it. Until then, stop acting like children.
That doesn't make the point any less valid. I don't need to have built a car to realise that a designer who creates a car with no brakes is incompetent.
You're missing the point. The issue is not that the project has problems - the issue is that the Diaspora devs are making elementary mistakes that should never have been made. The problems that have been pointed out essentially mean that they're clueless about how to write secure code, and as such anything they write / are responsible for is automatically suspect.
In order for Diaspora to be at all credible, the devs need to learn a hell of a lot about security first, or someone else needs to take over the project - the kind of mistakes they're making here are elementary, and shows that not only do they have almost no knowledge of how to make a web application secure, they also aren't thinking through the logical consequences of what they're writing.
Diaspora isn't doomed because it has flaws, it's doomed because the developers have proven themselves to be fundamentally incompetent.
...the program is to be added to the daily Cron jobs to be executed so that each day it will report to Canonical over HTTP the number of times this system previously sent to Canonical...
That's not a very good method of tracking usage - not everybody leaves their PC on 24/7, so the cronjob may not always run - and using the number of cronjob runs as a counter for how long the system has been active isn't a great idea either. Storing the install date and sending that would be a better indication.
Google is your friend. Clue one. The southern cross cable *network* doesn't just go to Austria.
I am fully aware of that fact, and I did check Google before posting. Now instead of being so patronising, I suggest you make note of the following clues yourself, and then provide some evidence to back up your claim:
I never claimed the SSC system was a single cable - read my post again.
The SSC system doesn't go to *Austria* either - we don't live in the middle of Europe.
The SSC system is a ring network connecting NZ and Australia to the US via Hawaii & Fiji (ref).
There is no other cable system connecting NZ to anywhere of note internationally with a design capacity over half a gigabit or so.
You mention additional cables headed to the US and Japan with capacity charges on the order of 'cents per 100 gigabits', yet I find it extremely hard to believe such a claim - if that were true, then I could lease the entire capacity of one of the other low-capacity cables for a couple of bucks.
So as I said before - references please. Your claim has no credibility otherwise.
References please. Last time I looked, the SSC system was the only cable network in place that even comes close to the capacity needed to service NZ's internet requirements. Every other cable I'm aware of is several orders of magnitude slower, and therefore not even worth bringing to the table...
If, as you claim, there are actually other cables of meaningful capacity (which I personally doubt), there will be available data to support this - care to provide us with a link or two?
The real icing on the cake is (as mentioned near the end) the secondary drive doesn't require a whole lot of power so it can be run by a flywheel. Infinite torque?
Except it's actually snakeoil as far as "doesn't require a whole lot of power" goes - if you read the engineering report, they conclude that the control / secondary input requires the same torque as the primary input; i.e. the power requirements are simply split between both inputs. As a result, this thing isn't actually an IVT transmission on its own at all - it requires another CVT/IVT system to regulate the secondary / control input, or a second, equally powerful source of torque, or both.
On its own, this thing is useless as a transmission, although it is a rather innovative application of this type of gear system, and would help to reduce the load on a traditional CVT system, allowing for a greater-than-usual amount of power to be transferred through the system as a whole.
Which is why software should not be released until it is ready *enough* (and *enough* does scale) - with a major memory leak in X, Ubuntu currently doesn't fit into that category.
No, if it's a (supported) stable release from something like Debian, what you actually get is this:
User: "I have a memory leak in my X!"
Dev: "Please file a bug report with detailed instructions so we can reproduce the problem."
After a bit of time passes (how much depends on the severity of the bug) the problem is fixed, upstream if possible or locally to Debian if not, and the patched version hits the repositories. Next time this user updates their system, the problem vanishes.
That is why Debian is a far better choice than Ubuntu if you want something that really is stable and supported longterm - Ubuntu LTS is a joke.
Except it's not saying "I failed", it's saying "Haha, the other thing I talk to failed, but I'm still here providing you with a helpful error message."
I'd think that's a pretty good place to advertise, myself.
Varnish is a high-performance HTTP cache / reverse proxy / accelerator / router. This particular Slashdot 503 links to the Varnish site because Slashdot uses Varnish as part of its server stack, and Varnish is generating the error to moan about something upstream. Why not get in some free advertising?
...unless you use PAE, you can use at most 4 GB of RAM with a 32-bit OS, and a lot of that gets eaten up by device and BIOS mappings and holes.
That's utter garbage. 32bit operating systems have been addressing considerably more than 4GB of RAM for many years using PAE - the maximum address space using PAE is 64GB.
You're thinking of the low-power versions. If you look at something higher-powered, such as a Cree XR-E, then yes - you will need decent heatsinking to prevent the LED from frying itself.
Your assumption is like talking about a P4 CPU, and assuming it has the same thermal requirements as a low-end ARM CPU. Without heatsinking, the P4 will melt in short order - but the ARM will be just fine.
Slashdot Mirror
...can connect to an Asterisk server somewhere out there on the internet using Sipdroid...
Android 2.3+ has a native SIP client that integrates with the dialer - no need for a third-party app at all.
It's an e-ink reader; it's supposed to be greyscale. While colour e-ink screens are now available, they're still *very* new technology, and not yet present in any currently shipping devices that I'm aware of.
As an example, this is one of the reasons why SSD random I/O performance is so much better than rotating media.
Latency is why. It doesn't matter how fast the link to your storage is, if it's several ms away from you the delay gets annoying *real* fast.
I suspect it means that NELL can't unlearn stuff on its own - hence the 'human handlers' need to intervene from time to time to correct things.
That doesn't make the point any less valid. I don't need to have built a car to realise that a designer who creates a car with no brakes is incompetent.
You're missing the point. The issue is not that the project has problems - the issue is that the Diaspora devs are making elementary mistakes that should never have been made. The problems that have been pointed out essentially mean that they're clueless about how to write secure code, and as such anything they write / are responsible for is automatically suspect.
In order for Diaspora to be at all credible, the devs need to learn a hell of a lot about security first, or someone else needs to take over the project - the kind of mistakes they're making here are elementary, and shows that not only do they have almost no knowledge of how to make a web application secure, they also aren't thinking through the logical consequences of what they're writing.
Diaspora isn't doomed because it has flaws, it's doomed because the developers have proven themselves to be fundamentally incompetent.
Base Android comes with VPN support. What would OpenVPN add to this?
Hmm, let me see... How about support for OpenVPN networks? There's not exactly a whole lot of other things that OpenVPN is useful for!
That's not a very good method of tracking usage - not everybody leaves their PC on 24/7, so the cronjob may not always run - and using the number of cronjob runs as a counter for how long the system has been active isn't a great idea either. Storing the install date and sending that would be a better indication.
A 3V 18650 cell would be a very flat cell! Nominal voltage for an 18650 LiIon is 3.7V, with a maximum of 4.2V.
Google is your friend. Clue one. The southern cross cable *network* doesn't just go to Austria.
I am fully aware of that fact, and I did check Google before posting. Now instead of being so patronising, I suggest you make note of the following clues yourself, and then provide some evidence to back up your claim:
So as I said before - references please. Your claim has no credibility otherwise.
References please. Last time I looked, the SSC system was the only cable network in place that even comes close to the capacity needed to service NZ's internet requirements. Every other cable I'm aware of is several orders of magnitude slower, and therefore not even worth bringing to the table...
If, as you claim, there are actually other cables of meaningful capacity (which I personally doubt), there will be available data to support this - care to provide us with a link or two?
#include <stdio.h>
int main(void) {
while(printf("FUCK\n"));
}
There - brief, clear, and syntactically correct.
The real icing on the cake is (as mentioned near the end) the secondary drive doesn't require a whole lot of power so it can be run by a flywheel. Infinite torque?
Except it's actually snakeoil as far as "doesn't require a whole lot of power" goes - if you read the engineering report, they conclude that the control / secondary input requires the same torque as the primary input; i.e. the power requirements are simply split between both inputs. As a result, this thing isn't actually an IVT transmission on its own at all - it requires another CVT/IVT system to regulate the secondary / control input, or a second, equally powerful source of torque, or both.
On its own, this thing is useless as a transmission, although it is a rather innovative application of this type of gear system, and would help to reduce the load on a traditional CVT system, allowing for a greater-than-usual amount of power to be transferred through the system as a whole.
Which is why software should not be released until it is ready *enough* (and *enough* does scale) - with a major memory leak in X, Ubuntu currently doesn't fit into that category.
No, if it's a (supported) stable release from something like Debian, what you actually get is this:
After a bit of time passes (how much depends on the severity of the bug) the problem is fixed, upstream if possible or locally to Debian if not, and the patched version hits the repositories. Next time this user updates their system, the problem vanishes.
That is why Debian is a far better choice than Ubuntu if you want something that really is stable and supported longterm - Ubuntu LTS is a joke.
Except it's not saying "I failed", it's saying "Haha, the other thing I talk to failed, but I'm still here providing you with a helpful error message."
I'd think that's a pretty good place to advertise, myself.
Varnish is a high-performance HTTP cache / reverse proxy / accelerator / router. This particular Slashdot 503 links to the Varnish site because Slashdot uses Varnish as part of its server stack, and Varnish is generating the error to moan about something upstream. Why not get in some free advertising?
...unless the something you're staying up to do happens to be amphetamine.
Or polyphasic sleep, although admittedly polyphasic sleep does involve short naps, so it's not continuous waking-time, but it's pretty close.
...unless you use PAE, you can use at most 4 GB of RAM with a 32-bit OS, and a lot of that gets eaten up by device and BIOS mappings and holes.
That's utter garbage. 32bit operating systems have been addressing considerably more than 4GB of RAM for many years using PAE - the maximum address space using PAE is 64GB.
See here for a more detailed explanation.
He's talking about the Apollo 13 mission CO2 filters.
Sigh... it's a freaking analogy, OK? 'Melt' doesn't have to be pedantically correct.
For the guy who wanted a car analogy... it's like trying to run a formula 1 engine at full load with the cooling rig from a 1980s civic.
You're thinking of the low-power versions. If you look at something higher-powered, such as a Cree XR-E, then yes - you will need decent heatsinking to prevent the LED from frying itself.
Your assumption is like talking about a P4 CPU, and assuming it has the same thermal requirements as a low-end ARM CPU. Without heatsinking, the P4 will melt in short order - but the ARM will be just fine.
Quite apart from anything else, this means that you are running an ancient, unpatched system...
You could try subscribing!