from the obvious recumbent fan in that interview: "uphill a little bit slower, where as on the flats they might go about a third faster."
you know how fast tour de france riders go downhill? ever seen footage from inside a team car trying to keep up with them, tires screaming around the corners? aerodynamics is not really the limiting factor when going down from l'alpe d'huez for example.
and besides, with the ratio between the aerodynamic disadvantage of cycling in the lead or solo and power needed for mountains etc changed so much, it would be a very different sport. like you would not put more people in a soccer game to get more goals - ah wait, this is/. people don't know what that is anyway...
starting up a jvm just to notice that the user typed "littlejavacommandlineapp --help"? java might be not as slow as the cliche says for some things, but startup times are still less than interactive. maybe this could change with some demon thing that can just fork out when needed or something, but i could well imagine that there would be too many api blocks that had to be initialized individually for the individual configuration of every app.
too bad it's specified so loosely, developers have to care a lot about different presumably compatible hosts that it can easily be simpler to make the plugin work with different hosts on the same OS than with the same host on different OS. host development is said to be even more a pita, you have to basically decide between emulating the bugs of old cubase implementatins and those of logic, or both, switching between emulations depending on what plugin is loaded.
only if you assume that driver support in linux will be on par with windows (personally i do not think that is too far off), since reactos is meant to be able to be compatible with windows driver binaries.
the drawback of that certainly is that you get the source of most os instabilitiy in current windows incarnations when loading those drivers... just think brooktree-based tv *shudders*
from what i've heard i got the impression that reactOS is all about making an nt style _kernel_, and most of the higher level win32 api stuff is mainly ported from wine, so it is more a non-unix system with a "unix-style win32-api" running on top of it.
but the end result being useful or not, the efforts of the reactOS project have already resulted in some advances in the mingw flavour of gcc, so i could easily see the wine api development profiting from this as well. (and don't come at me with "then they'd better invest their time directly in wine, spare time projects - reactOS certainly falls into that category - just don't work that way)
ps: and hey, who knows, maybe this thing will get really really good and one day they can make a better foss unix by adding a unix subsystem on top of their kernel;-) (and while i am really just jesting, remember that nt was designed to support multiple "subsystem" OS frontents, every good joke has some truth in it)
not to mention the quality joy of reencoded music...
if i buy once, i want a proper cd. even if the first thing i do is drop it into eac (or plug in spdif)
thinking of this, one has to wonder when the riaa members start filling their cds with material that already went through some obscure psychoacoustic based lossy compression/decompression cycle just to handicap encodings of the raw cd with the "reencoding stigma"... fun is, when this happens they will lose the goodwill of the last customer, while pirate hobbyists will be empowered with the means to copy without coding down, by moore's law.
"Uh, if you are buying the album and you're going to rip it to iTunes why not just buy it from the iTunes Music Store in the first place?"
erm, maybe because i trust my cd shelf a little bit more than i trust my computer? i trust my computer a lot, but since any event that would fukc up my cd shelf would kill my computer as well, and the opposite is not true, i know where my preferences are.
and then comes all the hassle in case you some day feel like you want some "alternative-ipod" even if it is just itms taking all your legitimately bought songs hostage to make you buy a possibly over-priced future generation ipod. just look at what sony does with their mem-stick. in case of a cd that is compatible with a cd player i know at least that i can get proper copies with all the hassle, getting past a drm solution either involves software more illegal than an spdif cable (or good converters..) or recoding, or both.
(on the ceap&legal point, i certainly agree with you. but honestly, i don't see that anywhere, do you?)
while this screams for that silly old boring "drink+drive? take drugs+fly" joke, i wonder if a drunk person in one of those would really be more a problem. i mean, there is just so much more room in the air than on a street, try to hit a tree when you're on 200 ft. and for this m400 to be anything practical, i'd expect stuff like starting/landing to be quite automated anyway. but the most important point is still: you can cause so much destruction with a high powered car if you really loose any self control due to drunkenness, it would not matter much if you'd sit in a high powered flying car instead. so in a way, said device would be a good idea for any form of high powered transpoertation.
heh, and then they would still be alone with their fuel efficiency measurement, because everyone else uses liters per 100 kilometers.
ps: now the little hobby psychologist could argue that americans obviously want to know "i have x units of fuel, how far can i get away from here?" while the rest of the world thinks "i want to reach point B, how many units of fuel do i need?", but i don't feel really pushing this kind of argument today.
those are a lot more fun, and you don't even need a power supply. yes, it won't go down to 0 celsius, but there are hughe differences between reasonably cool beer, warm beer, and stupidly cold beer.
oh, and these things are already in use, i happened to enjoy one already some years ago.
when i read the article, i was surprised to read something that reasonable by a bsa person. seeing a difference between some people in the know spending their spare time with some-not-so-legal-things-to-do-with-ip and Unlimited Piracy For The Masses is close to the exact opposite of the usual copying==terrorism non-logic.
for me it makes the effect so much more real, someone telling who is not caring for linguistic perfection, but for pure content delivery, to borrow some jargon from media convergence capitalists.
(ps: sorry, no intention to excuse my own poor english)
i really don't think c will ever be the language to run on top of a bytecode layer. there are enough languages which at least look like variants of c that are much better fitting for those projects that are suspect of being run inside a bytecode box.
instead, what i could imagine in a future in which nearly everything goes the bytecode way, is c at some day being the only remaining language for the down&dirty stuff that is compiled to native machine code, although certain variants of c are unlikely to completely move to bytecode land as well.
the whole discussion here seems to be based on the assumption that intel will roughly adpopt the infamous "PR" rating (####+ where #### is the clock speed of an imaginary cpu that performs equivalently to the cpu being named).
the way i interpreted the article, the new naming scheme would be more similar to the way opterons are named, some longer number consisting of shorter numbers representing various features of the cpu. cache size, fsb, core voltage would be my candidates.
when you have to use cables anyway, wouldn't it be the smartest move to integrate data and power transmission in one? sure, usb tried it and failed, but the execution was broken, not the concept.
my guess is that in the initial specification they put so much focus on the ability to branch one controller to a ton of devices, that they did not dare to allow too high currents to a single device.
now as the number of usb sockets on an average mainboard slowly approaches the number of pins in a parallel printer port, this is moving more and more into the background. wouldn't it be time to revive the idea and do it right this time? i'd be looking forward to a world where dc conversion is centralized on the workstation level.
i want to see someone doing make install with a gun.
on a related note: 4 marines died from a software bug? so what? how many people are dying every day from non-specialists unaware of the security issues driving a car? the motorized pearl harbour is happening every day. obviously, the people who wrote that article just summed numbers over a global range to get some impressive zeros behind a leading non-zero, without ever doing a reality check to find out that people obviously develop little demand for a lockdown on anything just based on high numbers.
yeah, those turbines at altamont pass are quite famous for their age - don't they date back to the seventies or something? energy crisis time? in addition to those anachronistic fast spinning blades their open-frame towers attract birds for resting or even building their nests, which certainly increases the bird killing rate even more in comparison to modern wind power systems. still the numbers are not _that_ drametic, as so many people have already pointed out.
in the end: you get a mac if you want a mac, and yuo et an amd if you don't want intel.
(do any of us x86 guys really think about getting a mac? i think not: either we are happy with linux and don't bother _any_ commercial os, be it bill-os or steve-os, or we think about switching to linux but don't do, for this or the other reason, all of those reasons applying as well to mac-os.)
Slashdot Mirror
from the obvious recumbent fan in that interview: "uphill a little bit slower, where as on the flats they might go about a third faster."
/. people don't know what that is anyway...
you know how fast tour de france riders go downhill? ever seen footage from inside a team car trying to keep up with them, tires screaming around the corners? aerodynamics is not really the limiting factor when going down from l'alpe d'huez for example.
and besides, with the ratio between the aerodynamic disadvantage of cycling in the lead or solo and power needed for mountains etc changed so much, it would be a very different sport. like you would not put more people in a soccer game to get more goals - ah wait, this is
starting up a jvm just to notice that the user typed "littlejavacommandlineapp --help"? java might be not as slow as the cliche says for some things, but startup times are still less than interactive. maybe this could change with some demon thing that can just fork out when needed or something, but i could well imagine that there would be too many api blocks that had to be initialized individually for the individual configuration of every app.
try that with a linux build put into a sealed box in early 2k ;)
(really no flame intended, it is a very very good thing that linux is coming closer and closer to supporting everything from the first day on)
too bad it's specified so loosely, developers have to care a lot about different presumably compatible hosts that it can easily be simpler to make the plugin work with different hosts on the same OS than with the same host on different OS. host development is said to be even more a pita, you have to basically decide between emulating the bugs of old cubase implementatins and those of logic, or both, switching between emulations depending on what plugin is loaded.
only if you assume that driver support in linux will be on par with windows (personally i do not think that is too far off), since reactos is meant to be able to be compatible with windows driver binaries.
the drawback of that certainly is that you get the source of most os instabilitiy in current windows incarnations when loading those drivers... just think brooktree-based tv *shudders*
hmmm
;-) (and while i am really just jesting, remember that nt was designed to support multiple "subsystem" OS frontents, every good joke has some truth in it)
from what i've heard i got the impression that reactOS is all about making an nt style _kernel_, and most of the higher level win32 api stuff is mainly ported from wine, so it is more a non-unix system with a "unix-style win32-api" running on top of it.
but the end result being useful or not, the efforts of the reactOS project have already resulted in some advances in the mingw flavour of gcc, so i could easily see the wine api development profiting from this as well. (and don't come at me with "then they'd better invest their time directly in wine, spare time projects - reactOS certainly falls into that category - just don't work that way)
ps: and hey, who knows, maybe this thing will get really really good and one day they can make a better foss unix by adding a unix subsystem on top of their kernel
not to mention the quality joy of reencoded music...
if i buy once, i want a proper cd. even if the first thing i do is drop it into eac (or plug in spdif)
thinking of this, one has to wonder when the riaa members start filling their cds with material that already went through some obscure psychoacoustic based lossy compression/decompression cycle just to handicap encodings of the raw cd with the "reencoding stigma"... fun is, when this happens they will lose the goodwill of the last customer, while pirate hobbyists will be empowered with the means to copy without coding down, by moore's law.
"Uh, if you are buying the album and you're going to rip it to iTunes why not just buy it from the iTunes Music Store in the first place?"
erm, maybe because i trust my cd shelf a little bit more than i trust my computer? i trust my computer a lot, but since any event that would fukc up my cd shelf would kill my computer as well, and the opposite is not true, i know where my preferences are.
and then comes all the hassle in case you some day feel like you want some "alternative-ipod" even if it is just itms taking all your legitimately bought songs hostage to make you buy a possibly over-priced future generation ipod. just look at what sony does with their mem-stick. in case of a cd that is compatible with a cd player i know at least that i can get proper copies with all the hassle, getting past a drm solution either involves software more illegal than an spdif cable (or good converters..) or recoding, or both.
(on the ceap&legal point, i certainly agree with you. but honestly, i don't see that anywhere, do you?)
while this screams for that silly old boring "drink+drive? take drugs+fly" joke, i wonder if a drunk person in one of those would really be more a problem. i mean, there is just so much more room in the air than on a street, try to hit a tree when you're on 200 ft. and for this m400 to be anything practical, i'd expect stuff like starting/landing to be quite automated anyway. but the most important point is still: you can cause so much destruction with a high powered car if you really loose any self control due to drunkenness, it would not matter much if you'd sit in a high powered flying car instead. so in a way, said device would be a good idea for any form of high powered transpoertation.
heh, and then they would still be alone with their fuel efficiency measurement, because everyone else uses liters per 100 kilometers.
ps: now the little hobby psychologist could argue that americans obviously want to know "i have x units of fuel, how far can i get away from here?" while the rest of the world thinks "i want to reach point B, how many units of fuel do i need?", but i don't feel really pushing this kind of argument today.
pity that we do not use a base12 numeric system (but still, who would not vote for base13 if he had the chance? ;)
why develop?
it is already developed: same site or other site with some breweries who use it (jever seems to do so as well)
or for the multimedia fanatics, a flash
those are a lot more fun, and you don't even need a power supply. yes, it won't go down to 0 celsius, but there are hughe differences between reasonably cool beer, warm beer, and stupidly cold beer.
oh, and these things are already in use, i happened to enjoy one already some years ago.
"opposable digits technology" is indeed a good one
when i read the article, i was surprised to read something that reasonable by a bsa person. seeing a difference between some people in the know spending their spare time with some-not-so-legal-things-to-do-with-ip and Unlimited Piracy For The Masses is close to the exact opposite of the usual copying==terrorism non-logic.
"poor command of the english language"?
for me it makes the effect so much more real, someone telling who is not caring for linguistic perfection, but for pure content delivery, to borrow some jargon from media convergence capitalists.
(ps: sorry, no intention to excuse my own poor english)
i really don't think c will ever be the language to run on top of a bytecode layer. there are enough languages which at least look like variants of c that are much better fitting for those projects that are suspect of being run inside a bytecode box.
instead, what i could imagine in a future in which nearly everything goes the bytecode way, is c at some day being the only remaining language for the down&dirty stuff that is compiled to native machine code, although certain variants of c are unlikely to completely move to bytecode land as well.
the whole discussion here seems to be based on the assumption that intel will roughly adpopt the infamous "PR" rating (####+ where #### is the clock speed of an imaginary cpu that performs equivalently to the cpu being named).
the way i interpreted the article, the new naming scheme would be more similar to the way opterons are named, some longer number consisting of shorter numbers representing various features of the cpu. cache size, fsb, core voltage would be my candidates.
when you have to use cables anyway, wouldn't it be the smartest move to integrate data and power transmission in one? sure, usb tried it and failed, but the execution was broken, not the concept.
my guess is that in the initial specification they put so much focus on the ability to branch one controller to a ton of devices, that they did not dare to allow too high currents to a single device.
now as the number of usb sockets on an average mainboard slowly approaches the number of pins in a parallel printer port, this is moving more and more into the background. wouldn't it be time to revive the idea and do it right this time? i'd be looking forward to a world where dc conversion is centralized on the workstation level.
but this sounds very much like straight out of efnet #buzz
the ultimate geek ability: find a scifi computer game reference to every Nature story. today: Sid Meyer's Alpha Centauri.
(k' fungii are not exactly plants, but who cares...)
oh, not with compilers? ;)
i want to see someone doing make install with a gun.
on a related note: 4 marines died from a software bug? so what? how many people are dying every day from non-specialists unaware of the security issues driving a car? the motorized pearl harbour is happening every day. obviously, the people who wrote that article just summed numbers over a global range to get some impressive zeros behind a leading non-zero, without ever doing a reality check to find out that people obviously develop little demand for a lockdown on anything just based on high numbers.
yeah, those turbines at altamont pass are quite famous for their age - don't they date back to the seventies or something? energy crisis time? in addition to those anachronistic fast spinning blades their open-frame towers attract birds for resting or even building their nests, which certainly increases the bird killing rate even more in comparison to modern wind power systems. still the numbers are not _that_ drametic, as so many people have already pointed out.
omfg, then i stop wanting to be an american!
in the end: you get a mac if you want a mac, and yuo et an amd if you don't want intel.
(do any of us x86 guys really think about getting a mac? i think not: either we are happy with linux and don't bother _any_ commercial os, be it bill-os or steve-os, or we think about switching to linux but don't do, for this or the other reason, all of those reasons applying as well to mac-os.)