All too often open source tools are used and the developer doesn't have any feedback as to whether their software is being used successfully or not.
Any feedback is telling a developer that his/her software is being used. After all: if nobody was, where would that feedback come from?
More feedback (bug reports, specifically) could mean a couple of things: that your software is really crap, OR that lots of people are using it, some of those have encountered a bug, and out of those 'some', somebody made the effort to report it back. I guess as developer you should appreciate that, AND be able to tell apart 'lots of bugs' from 'lots of users'. And if you're developing something and didn't get a single (as in: 1) response about it, then I guess you're really doing it for yourself.
And to add, something I'm missing in almost any documentation: write documentation that serves absolute beginners. Why? Because non-beginners already know how to use the [whatever]. So if they need more info, assume they're totally new to the subject you're documenting.
For example: so far I haven't found (online) a guide on 'how to use a computer, that has Ubuntu Linux on it' for beginners. How to configure Ubuntu: sure. What is different in Ubuntu vs. other distro's: sure. What is different in Linux vs. Windows: sure. But that's all documentation for people who are already experienced computer users. But a guide to using Ubuntu, for people who have hardly ever touched a computer: where? Show me. Let alone in localized versions...
Equally important: write docs to be read by users of the software first, not docs for co-developers. If developers need docs: do that later, but write the user documentation first. In fact, it wouldn't be bad to start a project by writing the user documentation first (and code later).
Read (among others) as "i386 or derivative processor (AMD64 and x86_64 are fine as well)" (emphasis mine).
Really? I know that for x86 systems usually the only relevant distinction is 32-bit vs. 64-bit CPU, but the above says 'compiled for i386'. Somehow I doubt that:
I've seen much older kernels than the 2.6.32 mentioned, generate some compiler warnings when configured for i386 (and compiled with older verions of GCC). Also IIRC, recent Glibc versions require at least a 486 because it uses intructions that enable atomic operations (either fail or succeed, nothing in between) for some of the included features. Read: on a 386 these instructions wouldn't be available, and use a (less-reliable?) software workaround. And I doubt the included software would be obsolete versions of things like kernel/Glibc/GCC.
Maybe it's just my uninformed me here, or this "i386" is bullshit and should probably read "486", "Pentium", or even "generic 686 class CPU". Can anyone clarify?
Not really - for oil deposites as they're found today: they've been sitting where they are for the millions of years it took to form them, without major leakage. So what are the chances of natural leakage within the few centuries that mankind has been looking? And perhaps where major leakage has happened (loooonggg ago), that oil deposit just wouldn't be there anymore.
Also no one is saying there aren't any oil leaks with natural causes - it's just that the vast majority has human causes (or at least I'd guess that to be the case).
If they're not able to obtain meaningful results (for example if something goes wrong, or the signal/noise ratio somehow gets botched so that results aren't trustworthy), it'll just improve the state of the art of the engineering involved (=not worth it).
If OTOH obtained measurements are solid, then any result is useful, even if 'the meter reads zero'. Remember this experiment would serve to support or dis-prove a theory, so either result would advance the science fields involved.
Damn, I thought one could just write papers to prove something. Now we have to spend millions.
In science, the only things you can prove by writing papers is that you are able to write, or that you understand math (since ultimately, math is a matter of definition - by humans).
Proving anything else requires field-testing one way or another. Where 'field-testing' may be done in your kitchen sink, if possible.
In short, imagine the robot arm in TFA swinging too far to the side, cutting a passerby, because it "thinks" that it's more centered than it really is. Collision detection would be likely disabled if the robot's job was to cut stuff!
That's not a 'safe robot' issue, but a 'proper shielding between humans and robot work area' issue. If insufficient: take it up with your boss. If there really is an unsafe situation and your boss doesn't fix it (read: work safety is not no.1 priority within the company), you shouldn't work there, period.
As for me: I'm all for giving robots sharp tools. Because whatever they'll be doing with those sharp tools, means fewer humans need to do the same (potentially dangerous) job. So that the humans can do more interesting / safer things while the robots are busy cutting stuff.
So far, resources here on Earth have been practically unlimited for us humans, such as living space, food, and energy sources.
Ehm... yeah, sure. The fact that wars have been fought (and are being fought) over each of those items you mention, says otherwise. Let's face it: we're all on a big spaceship here (Earth). It's big and can take a lot of abuse, but in terms of resources, it's like a closed shell - hardly 'unlimited'. And there are lots of us - more every day.
I recently found a cache of old disks, and I'm wondering what would be an environmentally friendly way to dispose of the little space wasters???
For starters: re-purpose them for your own use wherever possible. 2nd best option: find someone in your area that can re-use them as is.
Failing that: drop them off at a place where recycling the actual materials is done nearby, that is: a recycling company / organization that doesn't ship the goods to the other side of the world before extracting the raw materials.
Recycling saves energy if the raw materials take more energy to be extracted from other sources; for example, this is often the case for (precious) metals. Recycling also costs energy: to turn old junk back into raw material. Some of that energy goes into the recycling process itself, another large chunk is energy used to pick up that junk / collect / sort / transport to recycling facility. The first depends on process used, the latter is something you have a big influence on. It may be be hard to find a suitable drop-off point though (and be sure they'll do as they claim).
How hard is it to actually operate an obsolete system with something vaguely like the original parts?
A bit like maintaining a classic car, I suppose: a combination of using old replacement part stocks, and (occasionaly) newly fabricated parts where it doesn't hurt the overall look & feel. Or hurts the owner's taste...
If you're careful with your classic [whatever] and don't use it everyday, such old stocks can go a long way. And there's always the option to take 3 halfway broken ones, and make 2 working ones out of those.
At one point, you'll start using it. After some time, you'll stop using it. In between, the system that requires the smallest number of mouseclicks to make it do what you want, is the best. And for this measuring method, each commandline key-press counts as 10 mouseclicks (100 if you're a newbie).
They will do this because the tools needed to make really cool things have become cheaper and because humans feel good when they make really cool things.
If the bar on creating "really cool things" gets lowered, that also raises the bar on what's "really cool". Creating cool stuff takes time, effort and usually includes a learning curve. That said: you can start small, and take on bigger/harder projects as you go.
I suspect that it might make heat pipes built into the memory boards to be a highly desirable option, (..)
Hardly - the maximum amount of heat loss would be limited by the application.
If you'd use this technology to build a SSD for a laptop or a portable media player, there are some hard upper limits on how much power (=heat) that SSD could draw. Things like battery life, the amount of heat a full system can deal with, acceptable noise levels for cooling fans, etc. If bandwidth = heat, the application would limit the maximum available bandwidth for a given power consumption.
With that constraint as a given, I suspect that even a 100- or 1000-layer thick stack of memory cells would be capable of transferring the heat to its surroundings. Each memory cell wouldn't need a good 'heat connection' to the outside world - just a heat transfer to neighbouring cells good enough to prevent hot spots. Also memory cells could be arranged such, that areas that appear close from a logical (programmer's) point of view, are widely distributed from a physical point of view.
The majority of users I have contact with resent having to enter passwords/user-verification at all.
Yeah, personally I'd prefer to use a custom-built USB key for this purpose. An USB key provided by the bank, that doubles as a crypto device to proof you are who you say you are (because you have that particular device). Perhaps in combination with something simple like a PIN number that people use anyway. Built-in software maintained by the bank over secure connection, read-only when running, perhaps a small user-area that's only writeable after authentication.
Problems come when people want to use it for more than just banking. What if you want to do online shopping with it? Find your deal, reboot, make payment, then reboot again to continue shopping? That wouldn't work. So the bank-provided USB key would have to support basic web browsing. Add some more use scenario's, and you need a lot of things that users have on their computer anyway - and many of the same maintenance headaches (for the bank, in updating that USB key).
So if you can limit the functionality enough to minimize maintenance headaches & still be practical at the same time, it just may work. If included functionality would keep ballooning: dead end.
Because it takes 10 times as long to write code that is totally formally verified?
Good point. Except:
This may be important for proof-of-concept apps, where some party can profit from a first-mover advantage. For most everyday apps: not so much. For OS code: irrelevant. For most users, an OS should just work (and IMHO, be boring).
Much of the work is maintaining software after release. If you can slash the need for updates significantly, spending more time on the initial code may just be worth it. Fewer bugs also means: lower support costs.
Regardless of how big an effort, getting code right the 1st time is a one-time effort. Updating code after release OTOH, is an effort that is multiplied by the number of users (even if individual updates are easy & painless).
While I'm all for tight code where every byte is important, one could just as well argue that languages used aren't high-level enough.
Operating systems and apps are often coded in languages like C or C++, that allow a lot of things, which turn into vulnerabilities down the road. Assembly is king of this: it allows a progammer to do anything, including things that aren't safe, smart or correct. No matter how good the code you produce or how comprehensive your testing procedures are, the sheer size of software systems guarantees a number of bugs to be lurking.
Personally I think that security is dead as long as these languages are the tools, testing code is the norm (vs. some sort of formal verification), and coders are looking for bugs rather than proving they're not there. Fixing this will take a combination of new methods for building software, new design principles to manage system complexity, and safe(r) languages to write the code in. There's a lot of research around (see seL4 microkernel or Coyotos for example), but results rarely finds its way into mainstream products. There's a long way to go still... or users just don't care enough.
However XP + ie is basically an invitation to be hacked / malwared / infected / ripped off.
Although I'm inclined to agree with you, you're making an overly broad statement here.
XP != XP SP1 != XP SP2 != XP SP3.
2 year old, never updated install != fresh + patched install.
IE6 != IE7 != IE8.
Browsing random pornsites != browsing a small set of trusted sites != using apps on corporate intranet.
So with "XP + ie = unsafe" you're lumping things together that in reality are many, vastly different things, and how (un)safe their use is depends on many factors.
As long as the source of the spam/malware problem isn't held accountable, nothing much will change.
The ultimate source (not cause!) of this problem is of course users that get spam, and then go on to send money to the folks that spammed them. But next in line are those companies that use spam, spread through malware-infected PC's, to sell their products (or sell worthless/dangerous crap, for that matter). Such shady companies should be put out of business, their CEO's thrown in jail ASAP (through whatever -legal- means), and profits confiscated to support the anti-spam operation.
Focussing on botnets is a good thing, but IMHO useless. Focussing on the folks running them is better, but the next botnet-operator-wannabee will step right in. Instead, efforts should focus on the businesses paying these fuckers.
There's no such thing as a cancer cure until the day we can re-write our genetic code to prevent mutation due to time, transcription errors, ionizing radiation and interference from thousands of different chemicals.
You're looking at it from the wrong angle: I doubt you could ever prevent "transcription errors, ionizing radiation and interference from thousands of different chemicals" from happening. A cancer cure would not be about that, but rather about minimizing the damage after it happens. For example by killing (or even repairing?) damaged cells before they turn into runaway growth.
If I'm not mistaken, any proscecution should (among other things) also pass a test of "be in the interest of society". I doubt that is the case here. You lock up criminals:
If it's necessary to protect society from them. Which IMHO would not apply here, since the chance of repeat is, well, 0.
To serve as example, to scare other potential criminals out of doing the same. Which wouldn't apply here either: as a parent, you'd be scared to leave a gun+ammo around because your kid might hurt/kill someone with it, not because some other fool got 5 years jailtime for doing the same. There's already enough examples that guns+kids don't mix well.
Also jail time would serve as punishment. Hardly a point for that: no bigger punishment thinkable than losing your own 3 year old.
So, no charges (?, left to be decided I suppose) because it serves no purpose, these parents are already punished enough (for the rest of their lives), and resources/court time is better spent on other cases. A thorough investigation to get a clear picture of what happened: yes, that might be useful.
I can imagine Google would cache intermediate results, possibly improve those results from time to time, and create a good coupling to its own search engine. Other search engines might have to 'distill' searchable text from the video (=difficult?), so that Google can search YouTube video content better than other search engines? Just a guess, FWIW.
Slashdot Mirror
.. most of the penguins I know ..
Wow, I gotta say, that's some fucked up shit. You sick pedo^H^H^H^H ehmm... how do you call someone that 'does penguins' ?
All too often open source tools are used and the developer doesn't have any feedback as to whether their software is being used successfully or not.
Any feedback is telling a developer that his/her software is being used. After all: if nobody was, where would that feedback come from?
More feedback (bug reports, specifically) could mean a couple of things: that your software is really crap, OR that lots of people are using it, some of those have encountered a bug, and out of those 'some', somebody made the effort to report it back. I guess as developer you should appreciate that, AND be able to tell apart 'lots of bugs' from 'lots of users'. And if you're developing something and didn't get a single (as in: 1) response about it, then I guess you're really doing it for yourself.
And to add, something I'm missing in almost any documentation: write documentation that serves absolute beginners. Why? Because non-beginners already know how to use the [whatever]. So if they need more info, assume they're totally new to the subject you're documenting.
For example: so far I haven't found (online) a guide on 'how to use a computer, that has Ubuntu Linux on it' for beginners. How to configure Ubuntu: sure. What is different in Ubuntu vs. other distro's: sure. What is different in Linux vs. Windows: sure. But that's all documentation for people who are already experienced computer users. But a guide to using Ubuntu, for people who have hardly ever touched a computer: where? Show me. Let alone in localized versions...
Equally important: write docs to be read by users of the software first, not docs for co-developers. If developers need docs: do that later, but write the user documentation first. In fact, it wouldn't be bad to start a project by writing the user documentation first (and code later).
Read (among others) as "i386 or derivative processor (AMD64 and x86_64 are fine as well)" (emphasis mine).
Really? I know that for x86 systems usually the only relevant distinction is 32-bit vs. 64-bit CPU, but the above says 'compiled for i386'. Somehow I doubt that:
I've seen much older kernels than the 2.6.32 mentioned, generate some compiler warnings when configured for i386 (and compiled with older verions of GCC). Also IIRC, recent Glibc versions require at least a 486 because it uses intructions that enable atomic operations (either fail or succeed, nothing in between) for some of the included features. Read: on a 386 these instructions wouldn't be available, and use a (less-reliable?) software workaround. And I doubt the included software would be obsolete versions of things like kernel/Glibc/GCC.
Maybe it's just my uninformed me here, or this "i386" is bullshit and should probably read "486", "Pentium", or even "generic 686 class CPU". Can anyone clarify?
Not really - for oil deposites as they're found today: they've been sitting where they are for the millions of years it took to form them, without major leakage. So what are the chances of natural leakage within the few centuries that mankind has been looking? And perhaps where major leakage has happened (loooonggg ago), that oil deposit just wouldn't be there anymore.
Also no one is saying there aren't any oil leaks with natural causes - it's just that the vast majority has human causes (or at least I'd guess that to be the case).
If they're not able to obtain meaningful results (for example if something goes wrong, or the signal/noise ratio somehow gets botched so that results aren't trustworthy), it'll just improve the state of the art of the engineering involved (=not worth it).
If OTOH obtained measurements are solid, then any result is useful, even if 'the meter reads zero'. Remember this experiment would serve to support or dis-prove a theory, so either result would advance the science fields involved.
Damn, I thought one could just write papers to prove something. Now we have to spend millions.
In science, the only things you can prove by writing papers is that you are able to write, or that you understand math (since ultimately, math is a matter of definition - by humans).
Proving anything else requires field-testing one way or another. Where 'field-testing' may be done in your kitchen sink, if possible.
In short, imagine the robot arm in TFA swinging too far to the side, cutting a passerby, because it "thinks" that it's more centered than it really is. Collision detection would be likely disabled if the robot's job was to cut stuff!
That's not a 'safe robot' issue, but a 'proper shielding between humans and robot work area' issue. If insufficient: take it up with your boss. If there really is an unsafe situation and your boss doesn't fix it (read: work safety is not no.1 priority within the company), you shouldn't work there, period.
As for me: I'm all for giving robots sharp tools. Because whatever they'll be doing with those sharp tools, means fewer humans need to do the same (potentially dangerous) job. So that the humans can do more interesting / safer things while the robots are busy cutting stuff.
So far, resources here on Earth have been practically unlimited for us humans, such as living space, food, and energy sources.
Ehm... yeah, sure. The fact that wars have been fought (and are being fought) over each of those items you mention, says otherwise. Let's face it: we're all on a big spaceship here (Earth). It's big and can take a lot of abuse, but in terms of resources, it's like a closed shell - hardly 'unlimited'. And there are lots of us - more every day.
I recently found a cache of old disks, and I'm wondering what would be an environmentally friendly way to dispose of the little space wasters???
For starters: re-purpose them for your own use wherever possible. 2nd best option: find someone in your area that can re-use them as is.
Failing that: drop them off at a place where recycling the actual materials is done nearby, that is: a recycling company / organization that doesn't ship the goods to the other side of the world before extracting the raw materials.
Recycling saves energy if the raw materials take more energy to be extracted from other sources; for example, this is often the case for (precious) metals. Recycling also costs energy: to turn old junk back into raw material. Some of that energy goes into the recycling process itself, another large chunk is energy used to pick up that junk / collect / sort / transport to recycling facility. The first depends on process used, the latter is something you have a big influence on. It may be be hard to find a suitable drop-off point though (and be sure they'll do as they claim).
How hard is it to actually operate an obsolete system with something vaguely like the original parts?
A bit like maintaining a classic car, I suppose: a combination of using old replacement part stocks, and (occasionaly) newly fabricated parts where it doesn't hurt the overall look & feel. Or hurts the owner's taste...
If you're careful with your classic [whatever] and don't use it everyday, such old stocks can go a long way. And there's always the option to take 3 halfway broken ones, and make 2 working ones out of those.
What makes one Linux better than another?
In a nutshell:
At one point, you'll start using it. After some time, you'll stop using it. In between, the system that requires the smallest number of mouseclicks to make it do what you want, is the best. And for this measuring method, each commandline key-press counts as 10 mouseclicks (100 if you're a newbie).
From the article:
They will do this because the tools needed to make really cool things have become cheaper and because humans feel good when they make really cool things.
If the bar on creating "really cool things" gets lowered, that also raises the bar on what's "really cool". Creating cool stuff takes time, effort and usually includes a learning curve. That said: you can start small, and take on bigger/harder projects as you go.
I suspect that it might make heat pipes built into the memory boards to be a highly desirable option, (..)
Hardly - the maximum amount of heat loss would be limited by the application.
If you'd use this technology to build a SSD for a laptop or a portable media player, there are some hard upper limits on how much power (=heat) that SSD could draw. Things like battery life, the amount of heat a full system can deal with, acceptable noise levels for cooling fans, etc. If bandwidth = heat, the application would limit the maximum available bandwidth for a given power consumption.
With that constraint as a given, I suspect that even a 100- or 1000-layer thick stack of memory cells would be capable of transferring the heat to its surroundings. Each memory cell wouldn't need a good 'heat connection' to the outside world - just a heat transfer to neighbouring cells good enough to prevent hot spots. Also memory cells could be arranged such, that areas that appear close from a logical (programmer's) point of view, are widely distributed from a physical point of view.
It's called a condom (..)
Just one? That won't get you very far...
The majority of users I have contact with resent having to enter passwords/user-verification at all.
Yeah, personally I'd prefer to use a custom-built USB key for this purpose. An USB key provided by the bank, that doubles as a crypto device to proof you are who you say you are (because you have that particular device). Perhaps in combination with something simple like a PIN number that people use anyway. Built-in software maintained by the bank over secure connection, read-only when running, perhaps a small user-area that's only writeable after authentication.
Problems come when people want to use it for more than just banking. What if you want to do online shopping with it? Find your deal, reboot, make payment, then reboot again to continue shopping? That wouldn't work. So the bank-provided USB key would have to support basic web browsing. Add some more use scenario's, and you need a lot of things that users have on their computer anyway - and many of the same maintenance headaches (for the bank, in updating that USB key).
So if you can limit the functionality enough to minimize maintenance headaches & still be practical at the same time, it just may work. If included functionality would keep ballooning: dead end.
Because it takes 10 times as long to write code that is totally formally verified?
Good point. Except:
While I'm all for tight code where every byte is important, one could just as well argue that languages used aren't high-level enough.
Operating systems and apps are often coded in languages like C or C++, that allow a lot of things, which turn into vulnerabilities down the road. Assembly is king of this: it allows a progammer to do anything, including things that aren't safe, smart or correct. No matter how good the code you produce or how comprehensive your testing procedures are, the sheer size of software systems guarantees a number of bugs to be lurking.
Personally I think that security is dead as long as these languages are the tools, testing code is the norm (vs. some sort of formal verification), and coders are looking for bugs rather than proving they're not there. Fixing this will take a combination of new methods for building software, new design principles to manage system complexity, and safe(r) languages to write the code in. There's a lot of research around (see seL4 microkernel or Coyotos for example), but results rarely finds its way into mainstream products. There's a long way to go still... or users just don't care enough.
However XP + ie is basically an invitation to be hacked / malwared / infected / ripped off.
Although I'm inclined to agree with you, you're making an overly broad statement here.
XP != XP SP1 != XP SP2 != XP SP3.
2 year old, never updated install != fresh + patched install.
IE6 != IE7 != IE8.
Browsing random pornsites != browsing a small set of trusted sites != using apps on corporate intranet.
So with "XP + ie = unsafe" you're lumping things together that in reality are many, vastly different things, and how (un)safe their use is depends on many factors.
Competitors? More like it kicked a parasite off its back.
As long as the source of the spam/malware problem isn't held accountable, nothing much will change.
The ultimate source (not cause!) of this problem is of course users that get spam, and then go on to send money to the folks that spammed them. But next in line are those companies that use spam, spread through malware-infected PC's, to sell their products (or sell worthless/dangerous crap, for that matter). Such shady companies should be put out of business, their CEO's thrown in jail ASAP (through whatever -legal- means), and profits confiscated to support the anti-spam operation.
Focussing on botnets is a good thing, but IMHO useless. Focussing on the folks running them is better, but the next botnet-operator-wannabee will step right in. Instead, efforts should focus on the businesses paying these fuckers.
There's no such thing as a cancer cure until the day we can re-write our genetic code to prevent mutation due to time, transcription errors, ionizing radiation and interference from thousands of different chemicals.
You're looking at it from the wrong angle: I doubt you could ever prevent "transcription errors, ionizing radiation and interference from thousands of different chemicals" from happening. A cancer cure would not be about that, but rather about minimizing the damage after it happens. For example by killing (or even repairing?) damaged cells before they turn into runaway growth.
Well, after all this is Slashdot.... so: who wants the Nintendo?
If I'm not mistaken, any proscecution should (among other things) also pass a test of "be in the interest of society". I doubt that is the case here. You lock up criminals:
Also jail time would serve as punishment. Hardly a point for that: no bigger punishment thinkable than losing your own 3 year old.
So, no charges (?, left to be decided I suppose) because it serves no purpose, these parents are already punished enough (for the rest of their lives), and resources/court time is better spent on other cases. A thorough investigation to get a clear picture of what happened: yes, that might be useful.
I can imagine Google would cache intermediate results, possibly improve those results from time to time, and create a good coupling to its own search engine. Other search engines might have to 'distill' searchable text from the video (=difficult?), so that Google can search YouTube video content better than other search engines? Just a guess, FWIW.