Can I add: * Not require being connected to the internet to work on your saved media.
i.e. i don't want this DRM checking against a server that will probably dissapear in 20 years.
AFAIAC whatever I can do with a book, I should be able to do with other content. i.e. I can copy a book for my own use(difficult, but possible), I can lend a book to a friend when I say "This is brilliant", I can always read a book regardless of if the provider goes out of buisness.
What sucks about DRM is not that I don't own the media, but that I am reliant upon the goodwil of the provider to keep providing what i have bought! Either provide pay per view style at pay per voew prices, or give me something perminant that is totally perminant. It's theis fannying around in the middle that I find annoying...
Simple look at the number of LOC that guy wrote - hey he was working at 3am on a caffine high - He must be a better person to employ!
Oh wait, how many bugs did that code have? Why was the code written so late in the first place? Oh you mean we'll have to re-architect that system in a year when the new guy's moved onto a new company and no-one understands it.
I don't see what that definition changes. (Although citing wikipedia asa a source is a questionable activity). I have written error free code, that under its intended operating conditions always gives the correct result. I'll grant the only code I am certain of it being error free is relatively simple code (some micro-controller stuff doing some line pulse detection); but bug free code as you define it does exist. Scaling it is difficult, but I see no reason why it is impossible (in the dictionary sense of the term)
Except that re-processing pebble bed fuel is currently nearly impossible - so many of the advantages of nuclear power are lost. And MUCH more (if lower grade) waste to store
Thought experiment: So I come up with a way to get bountiful fusion working tomorrow. The whole world switches to an equivalent lifestyle (differences in climate mean we wouldn't have the same lifestyle)
Is consuming more energy still the problem? (assuming we don't care about damaging the environment - all the extra heat probably would...)
Do you agree nuclear power is a useful thing? Do you accept there exists waste that needs disposal? Other countries are trying to and have been dealing with nuclear waste.
All buildable machines are none turing complete Some langauges are turing complete, some aren't. Turing complete can solve any problem solvable. None turing complete may be able to solve your problem depending on your problem. If a language restricts me so I can't solve a problem that includes memory leaks and buffer overflows, that is probably a good thing.
Please be careful when you measure productivity and indeed size of project in LOC.
To me a program is "better" if it can do the required function in fewer LOC, that probably means the program is specified correctly and implemented efficiently. People complain about bloat, but then marvel at "heros" who write millions of lines. Give me a Guru who can do the same function in 100 lines anyday.
Disclaimer - I am aware sometimes you trade code size against execution speed, but that's what our friend Knuth is for:-)
This is where my experience differs from yours then: The systems we tried to get bugless were much more likely to be delivered on time because (I believe) we didn't spend the last 90% of the design time debugging unexpected bugs, instead we followed the project paln and little was unexpected. Project slips we found were therefore quite rare.
To expand on 3: I see a number of possible flaws: 1) Specification errors - the spec says to do something (or neglects to say something) that even if implemented correctly will not cause the correct result 2) Implementation errors - Producing code that does not match the spec. 3) coding errors - producing code that is just wrong (memory leeks etc).
Whether these errors come from your design, or interactions with other parts of the system is another question...
"Completely bug free software is impossible to write" Utter Rubbish!
Write a piece of software to print hello world to the screen, on your current computer for your current os. How can that have bugs in it if I have both complete control over both hardware and software? Yes writing bug free gets harder as the system is more complex can become proportonatly more complex, but not impossible.
Now if you're talking about fault tollerence that's a different kettle of fish! But bug free is possible. Reliability is different to bug free.
Actully part of designing a reliable system is coping with faulty hardware! If you're writing software for satellites (for example) you often can't rely on anything working.
This is completely opposite to the state at the moment, where people assume perfect hardware and buggy software; it should be "hardware that can and does fail" and "software that expects this and deals with it" because software doesn't age or have different faults depending upon which copy it is.
A rigid airframe is much simpler, cheaper, easier, and sturdier.
Unless that is part of the innovation, a way to build a deformable structure cheaper, easier, and sturdier? I'm reminded if the willow tree vs an oak in the storm - the oak may be stringer, but I'm taking bets as to which structure will most likely survive the stress of the storm...
I wonder if this lends its way to a new propulsion scheme? mode 1) {when you're high enough}Take the gas in the bag and compress it into internal cylinders so that you loose lift - then glide as above. mode 2) {when you're too low} Release gas from cylinders into bag providing lift.
Or is that what you're describing above? I also wonder if waste heat from the engines is used to warm the gas to provide extra lift?
My impression was that it was a true compromise, it wasn't as fat as a blimp, so could go faster and was less susceptable to cross-wind; but also had some of the fuel economy advantages of a blimp. But lost in speed compared to a try aeroplane and was less fuel economical than a full blimp. Also it would have limited hovering capabilities not quite up to that of a helecoptor or true blimp...
Slight nit pick! I'd have said that bt is optimised for big files with many users. The number of files is immaterial, as soon as I have a file over X size to be downloaded by Y people it'll make sense to do it via bt rather than via (say) FTP.
True, but we all have to start somewhere. Let me give an example:
I'd have called myself an expert "computer user" (whatever that means) and certainly a proficient Gimp user(the closest to video editing I have got), but trying to work Adobe premiere was beyond me when I tried.
I'm not knocking Premiere for anything, I needed some training wheels to get myself started in a new field. Maybe through formal training, or maybe through a simpler "crippled" tool. So there is and should be some way so that people can start on the easy tools (the Tricycle?) and move on. No I'm not saying everyone should use a Tricycle, but it should exist as an option until people are comfortable to move onto a real uncrippled bicycle.
Choices are your friend! The joys of a free world, other people can do what they want with their time and if they want to produce crippled tools for themselves, or others then that is their call!
More a matter of my own perspective here, but when I'm trying to hack something to get it to work, I like a large toolkit that I can pipe around and have full control over everything through a large collection of tools. i.e. if I'm fluent in a field I want control over every knob. (e.g. logic synthesys scripts at work where I want control over the find command that prunes the tree, and the perl scrip that hacks the file syntax)
If i just want something to work in a field I'm not fluent in or do not need control over, then I like suites that just work. Every second I can save not having to do a file save to translate between applications is another second of my life that is useful! And every hour I can spend not having to learn a new tool is a good hour.
The right tool for the right job, I don't care/understand the dependencies required for my desktop, so aptget does that for me; I do care about the dependencies for my SOC build, so I hand write scripts to do that for me. Sometimes you care about control, some times it's better to wrap it all up in a layer of abstraction at leave is as someone else's problem.
I don't see either approach as inherently superiour, provided I have access to both. Why are people dissing this, it's like when winzip was first released, so many people asked what the point was when they could command line it. How many people these days regualarly command line zip operations? (and running tar -czf in a script doesn't count:-) I mean run the zip program from a dos box:-))
Slashdot Mirror
Can I add:
* Not require being connected to the internet to work on your saved media.
i.e. i don't want this DRM checking against a server that will probably dissapear in 20 years.
AFAIAC whatever I can do with a book, I should be able to do with other content. i.e. I can copy a book for my own use(difficult, but possible), I can lend a book to a friend when I say "This is brilliant", I can always read a book regardless of if the provider goes out of buisness.
What sucks about DRM is not that I don't own the media, but that I am reliant upon the goodwil of the provider to keep providing what i have bought! Either provide pay per view style at pay per voew prices, or give me something perminant that is totally perminant. It's theis fannying around in the middle that I find annoying...
Simple look at the number of LOC that guy wrote - hey he was working at 3am on a caffine high - He must be a better person to employ!
Oh wait, how many bugs did that code have? Why was the code written so late in the first place? Oh you mean we'll have to re-architect that system in a year when the new guy's moved onto a new company and no-one understands it.
But look at the LOC stats!
I don't see what that definition changes. (Although citing wikipedia asa a source is a questionable activity).
I have written error free code, that under its intended operating conditions always gives the correct result.
I'll grant the only code I am certain of it being error free is relatively simple code (some micro-controller stuff doing some line pulse detection); but bug free code as you define it does exist.
Scaling it is difficult, but I see no reason why it is impossible (in the dictionary sense of the term)
Except that re-processing pebble bed fuel is currently nearly impossible - so many of the advantages of nuclear power are lost. And MUCH more (if lower grade) waste to store
Thought experiment:
So I come up with a way to get bountiful fusion working tomorrow. The whole world switches to an equivalent lifestyle (differences in climate mean we wouldn't have the same lifestyle)
Is consuming more energy still the problem? (assuming we don't care about damaging the environment - all the extra heat probably would...)
This is why policy makers hopefully look at facts rather than gut feelings.
Public opinion is important, but I hope they consider the facts too...
Do you agree nuclear power is a useful thing?
Do you accept there exists waste that needs disposal?
Other countries are trying to and have been dealing with nuclear waste.
Or is this just a case of NIMBY??
All buildable machines are none turing complete
Some langauges are turing complete, some aren't.
Turing complete can solve any problem solvable.
None turing complete may be able to solve your problem depending on your problem. If a language restricts me so I can't solve a problem that includes memory leaks and buffer overflows, that is probably a good thing.
Please be careful when you measure productivity and indeed size of project in LOC.
:-)
To me a program is "better" if it can do the required function in fewer LOC, that probably means the program is specified correctly and implemented efficiently.
People complain about bloat, but then marvel at "heros" who write millions of lines.
Give me a Guru who can do the same function in 100 lines anyday.
Disclaimer - I am aware sometimes you trade code size against execution speed, but that's what our friend Knuth is for
This is where my experience differs from yours then:
The systems we tried to get bugless were much more likely to be delivered on time because (I believe) we didn't spend the last 90% of the design time debugging unexpected bugs, instead we followed the project paln and little was unexpected. Project slips we found were therefore quite rare.
To expand on 3:
I see a number of possible flaws:
1) Specification errors - the spec says to do something (or neglects to say something) that even if implemented correctly will not cause the correct result
2) Implementation errors - Producing code that does not match the spec.
3) coding errors - producing code that is just wrong (memory leeks etc).
Whether these errors come from your design, or interactions with other parts of the system is another question...
"Completely bug free software is impossible to write"
Utter Rubbish!
Write a piece of software to print hello world to the screen, on your current computer for your current os.
How can that have bugs in it if I have both complete control over both hardware and software?
Yes writing bug free gets harder as the system is more complex can become proportonatly more complex, but not impossible.
Now if you're talking about fault tollerence that's a different kettle of fish! But bug free is possible. Reliability is different to bug free.
Actully part of designing a reliable system is coping with faulty hardware! If you're writing software for satellites (for example) you often can't rely on anything working.
This is completely opposite to the state at the moment, where people assume perfect hardware and buggy software; it should be "hardware that can and does fail" and "software that expects this and deals with it" because software doesn't age or have different faults depending upon which copy it is.
A rigid airframe is much simpler, cheaper, easier, and sturdier.
Unless that is part of the innovation, a way to build a deformable structure cheaper, easier, and sturdier?
I'm reminded if the willow tree vs an oak in the storm - the oak may be stringer, but I'm taking bets as to which structure will most likely survive the stress of the storm...
I wonder if this lends its way to a new propulsion scheme?
mode 1) {when you're high enough}Take the gas in the bag and compress it into internal cylinders so that you loose lift - then glide as above.
mode 2) {when you're too low} Release gas from cylinders into bag providing lift.
Or is that what you're describing above?
I also wonder if waste heat from the engines is used to warm the gas to provide extra lift?
Yeah they're a thing of the past, the future is getting into space, oh hang on:
http://www.jpaerospace.com/
Don't forget those barrage balloons then that protected London :-)
not really ships though...
My impression was that it was a true compromise, it wasn't as fat as a blimp, so could go faster and was less susceptable to cross-wind; but also had some of the fuel economy advantages of a blimp. But lost in speed compared to a try aeroplane and was less fuel economical than a full blimp.
Also it would have limited hovering capabilities not quite up to that of a helecoptor or true blimp...
I guess no one ever said "look it's the Good Year blimp" to you, and then ran off?
Slight nit pick!
I'd have said that bt is optimised for big files with many users.
The number of files is immaterial, as soon as I have a file over X size to be downloaded by Y people it'll make sense to do it via bt rather than via (say) FTP.
True, but we all have to start somewhere. Let me give an example:
I'd have called myself an expert "computer user" (whatever that means) and certainly a proficient Gimp user(the closest to video editing I have got), but trying to work Adobe premiere was beyond me when I tried.
I'm not knocking Premiere for anything, I needed some training wheels to get myself started in a new field. Maybe through formal training, or maybe through a simpler "crippled" tool.
So there is and should be some way so that people can start on the easy tools (the Tricycle?) and move on. No I'm not saying everyone should use a Tricycle, but it should exist as an option until people are comfortable to move onto a real uncrippled bicycle.
Choices are your friend! The joys of a free world, other people can do what they want with their time and if they want to produce crippled tools for themselves, or others then that is their call!
More a matter of my own perspective here, but when I'm trying to hack something to get it to work, I like a large toolkit that I can pipe around and have full control over everything through a large collection of tools. i.e. if I'm fluent in a field I want control over every knob. (e.g. logic synthesys scripts at work where I want control over the find command that prunes the tree, and the perl scrip that hacks the file syntax)
:-) I mean run the zip program from a dos box :-))
If i just want something to work in a field I'm not fluent in or do not need control over, then I like suites that just work. Every second I can save not having to do a file save to translate between applications is another second of my life that is useful! And every hour I can spend not having to learn a new tool is a good hour.
The right tool for the right job, I don't care/understand the dependencies required for my desktop, so aptget does that for me; I do care about the dependencies for my SOC build, so I hand write scripts to do that for me. Sometimes you care about control, some times it's better to wrap it all up in a layer of abstraction at leave is as someone else's problem.
I don't see either approach as inherently superiour, provided I have access to both.
Why are people dissing this, it's like when winzip was first released, so many people asked what the point was when they could command line it. How many people these days regualarly command line zip operations? (and running tar -czf in a script doesn't count
And this all comes down to semantics as to what natural is.
In the same way we see nest building of birds as natural, a hypothetical ET might see our building of cars as natural for us.
Maybe this material makes light "swing the other way"
Or maybe it makes light want to relax
Note on alternate meanings of Bent:
England: Bent = Gay
Australia: Bent = massive cannabis smoker
I know I have more trouble in mud than my landrover used to.