> I'm not sure we can count on accurate of translationedspecific words in article, however... > I'm not sure exactly what property is the most significant in stopping bullets
Well, the article clearly uses the word "hardness", not "strength" (I do speak German), and given the context in which it is used (research into bullet-stopping materials), I'd say it's pretty clear that the bullet-stopping type of hardness is meant here. If it had the properties of jello WRT stopping bullets, I don't think they'd waste their time on it.
hart (Härte): hard (hardness) stark (Stärke): strong (strength)
I do speak German, I've read the article, and they're saying exactly what you think they're saying: it's three times harder than hardened steel. Now they just need to make it a bit more transparent and less milky.
> but will it consume considerably more space on our shelves?
I don't see why it would have to. A cartridge could be the same size as current half-width CD cases, and even smaller because the hinge area wouldn't be needed. They could even replace the sliding metal cover with a molded-in slow window to make it even cheaper and more robust--although I don't know how close to the CD surface the lens has to be to focus properly.
Well, he's right, the Tommys developed those laser guns to fight the secret German UFOs, which we NOW all know were almost ready for combat.
HP used to do something similar on their scanner
on
Harddrive Speakers
·
· Score: 2
A ScanJet 4c (I think) we got back in 1994 had a Jukebox.exe program on the driver disk. It's been a while, but I believe it let you play MIDI files on the scanner stepper. Quite clearly, too. I think they yanked the program later on, though, I've never been able to find it again.
Re:Classes and APIs more important than language
on
What is .NET?
·
· Score: 2
I think DrPizza's only failing was to fully bring over to you the notion that Java bytecodes are higher level than IL: they make considerably more assumptions about the nature of the high-level language than do IL instructions. IL is essentially platform-neutral assembly language, so any code you could express in assembly you pretty much can in IL. You should be able to write an IL compiler for any existing language, provided you don't expect the resulting code to be reusable in any OO fashion by other.NET languages. The.NET-ness you object to only comes in when you are trying to expose a reusable object hierarchy that other.NET languages can inherit from, or when you want to take advantage of the CLR infrastructure (such as gc). In that case, the (high-level) language has to impose conforming restrictions.
Take things like C++ templates, or operator overloading, or multiple inheritance, or contracts: all these high-level constructructs are things that only the respective compilers have to worry about. The resulting object code knows nothing about any of this. A weak analogy: you can write a DLL that exposes a single function which fills in a buffer with memory offsets that your code (and only your code) can use as function pointers to call, or you can write a DLL that exposes all those "proprietary" functions as regular DLL entry points which any program can use. Both DLLs will work just fine, but only the latter will be of any use to a wider audience.
Since they're "open" to new languages (although, given the specificity of the requirements, it seems someone already made up their mind), Delphi would make a very good choice. They seem to want a good RAD IDE and OO, which are both a "check" with Delphi. It doesn't do gc, but then again, how many x-platform languages with operator overloading do? Many people tend to mean Unix (and often Linux) and Windows when demanding x-platform capabilities, and Delphi addresses both to a very large extent (except the few percent of non-x86 Linux machines). Plus, it's got real to-the-metal horsepower, as opposed to most gc'ed languages.
...with increased non-linearity of television. Just like web-based advertising is struggling because of its awkward fit with the medium, so will traditional commercials with on-demand or pseudo-on-demand (e.g. TiVo) television. They will simply HAVE to rethink their revenue model, which may very well end up very different from what we have today. They might try DVD-like forced viewing, where embedded codes prevent the playback device from skipping certain segments (i.e. commercials), but I don't know how well this scheme would go over with the much larger TV-watching public. Still, I fear that it's in our future, simply because it's technically feasible and requires a minimal change of revenue model.
With on-demand programming, a more natural model would be pay-per-view, but where the viewers pay the actual cost of producing the content. Of course, adjustments would have to be made at both ends: PPV costs would be higher, and content producers would have to learn to cut costs (i.e. get budgets back down to earth). It seems that one of the upshots of on-demand television will be less programming, since only saleable programs will make the list. Then again, with broadband distribution many more small shops with more modest budgets and salaries could get access to your living room, increasing the choice of programming.
> why has this whole thread been taken as a troll?
Mainly because the original post was extremely unclear in meaning. Here's an example:
> OK, in say about 85, how many german computers were on the market and popular ? Ok now remeber
> back and look at the computers in the american market?
I have no idea if you mean that there were many popular German computers, or few. The answer certainly isn't self-evident. All I know is that every kid in the early to mid 80s in Germany craved first a C64, then an Amiga. Not terribly German AFAIK. German computer manufacturers were mainly in the minicomputer and mainframe business, IIRC.
Anyway, I'm German but have lived for the last 15 years in Australia and the US, so I can tell you from experience that Germans and Americans are more alike than different. Germans (used to) hate to buy on credit, they value education and the arts, and they speak German, not English. Other than that, the similarities are striking: both are pathologically self-important, both pine for a house on their own piece of land, both love cars, both work too hard for not enough money. The German love for quality is either a myth, or dying fast, because I haven't seen any more quality conscious Germans (at the production end) than Americans. Sure, both like BUYING quality, but if it's lacking, all they do is whine. Incidentally, the similarity is hardly accidental, considering the percentage of German ancestry in the US.
Ok, I can see the words, and individually I can even look them up and find them in the dictionary. But taken as a whole--what do they mean? I'm stymied.
-the "mindset is different"--how?
-usability not important--how? As an aside, the "form follows function" school of design was born in Germany. The US prefer the "mine is bigger than yours" approach.
-pushing something on them isn't going to fly--what on earth do you mean?
Overall, I'd rate the entropy of this post at 95 on a scale of 0 to 100.
> The United States has been a Very Rich nation for a long while, without a war on our soil for
> over 125 years.
You keep bringing this up, what's its relevance to the point(s) you're trying to make? For the record, major contributors to America's wealth were its richness in resources and the constant influx of immigrants with tireless work ethics. The lack of wars is due in no small part to the scarcity of international borders to nations of similar size. This was achieved by usurping the land of the natives without any serious resistance.
Again, for the record, several European nations have pined for those lofty goals (i.e. resource richness, large workforce, few bordering foes) throughout the period of America's statehood. But alas, the natives resisted more forcefully, not understanding the full benefits of large-nationhood and homogenized language and values.
> Kylix is slow as hell, mainly because most of
> its GUI components are driven through Wine.
<sigh> Wrong. The Kylix IDE uses WINE and is slow as molasses, the compiled executables only use Qt and are much less so. Still, the compiled GUI code is slower than it could be for various reasons, probably also because of the necessary OP to C++ binding. There's something to be said for plain C environments.
> Your faith in the harmlessness of DRM in the face of open honest competition is touching. (:
Hardly faith, I'm just not convinced that the issue of DRM gets worse by moving the codec to the medium. If DRM is embedded in the hardware, all content providers will have to interact with it. If it's in a codec that is read off the medium, you're free to create content that uses DRM-free codecs, and to not buy content that does use DRM.
I admit that it could open a whole new chapter of nastiness on the part of thusly inclined content vendors. However, it would also open the door for the "good guys", allowing small production companies to use open codecs to play their stuff in an unrestricted fashion on the same hardware that the big houses are using to enforce their DRM nonsense. In the end, it could give you, the consumer, more power, allowing you to vote for playback technology with your wallet, while still not being limited in the range of hardware you can buy. For example, try buying an Ogg Vorbis hardware player today.
Move the codec from the player to the content. Hardware manufacturers would get together and establish an Open Player Platform or something, which essentially standardizes the instruction set and capabilities of the player and the image format of the codec executable. When you insert a medium and hit play, the player first examines the content file for the required codec, which must also reside on the same medium. It then loads the codec image from the medium and executes it against the content file.
This approach would have several advantages: allow content creators to use different codecs optimized for the content (e.g. action/animation/quality-vs-runtime etc.), eliminate codec costs to the manufacturer, and future-proof the players to a certain extent. Currently, the main disadvantage would be the high(er) cost of the player.
> Linus used a PC and Linux was a few years old
> before it ran on the Amiga.
I was talking about Minix, which ran on the Amiga before Linux ran on the PC.
> I don't think any of Linus' decisions back then had anything to do with Amigas.
You're most likely right, and I did say as much.
> Do you really like Amigas *that* much?
Did, not do. There simply was no equivalent to Linux today during the late 80s on the PC, and certainly not before the 386. If you wanted a preemptively multitasking system with flat memory that was supremely hackable and yet affordable to the average home user, there was little choice besides the Amiga. In terms of pure MHz the early 386s might have been ok, but given their plain framebuffer (VGA if you were lucky) displays and no sound to speak of, their overall performance quite sucked.
Eventually though, the PC hardware far surpassed anything the Amiga had to offer, and the plethora of OS choices made the switch to Intel a no-brainer. Today I would certainly need very strong arguments to move away from the PC.
> Yes, that's why Linux was first developed on Amigas.
> Man, where would you *ever* get such an idea?
From being there, mainly. Linux originally evolved from Minix, which existed on many more platforms than just the PC. When Linus started dabbling on the kernel, the Amiga had already peaked and was declining, what with Commodore not doing anything whatsoever. Linus either saw the writing on the wall, or maybe he always was a clone guy, I don't know. I'm not saying everyone was an Amiga nut back then. In hindsight he certainly chose wisely.
> Bullshit. The really 7337 hackers were on the Atari 8-bits and C64's.
Not at the time the original poster mentioned, not anymore. Flamebait or not, but during the mid- to late 80s there was the Amiga, and then there was everything else.
> There was a HUGE PC demo scene in the early 90s.
Early 90s? We're talking mid- to late 80s here, back when the PC was spending 80% of its CPU cycles servicing the keyboard. There wasn't much to demo on the PC back then.
> I was S000 37337!
> Man I wish I had Linux 2.4 and Debian back then !:)
Sorry to burst your bubble, but the really 7337 hackers back then were busy writing Amiga demos (and zillion disk copier progs). Many of them went on to become part of the first generation of Linux hackers. The closest thing to the Linux community (in terms of size and enthusiasm) back then was the Amiga community. The only ones bothering with the PC were Leisure Suit Larry addicts.
if someone presented an attempt at a proof of free energy using established formal methodologies, and showing a full understanding of the existing body of knowledge, one might be willing to sit down and give them the benefit of the doubt. But claims of breakthroughs in harnessing free energy invariably always come from individuals proposing new configurations of magnets, crystals, capacitors, or any other easily obtainable items with properties poorly understood by the ignorant.
Whenever the harnessing of a new source of energy will eventually take place, you can rest quite assured that it won't come through the banal realization that "oh, we've never tried arranging curiously strong magnets in the shape of the Number Of The Beast" or any other such nonsense.
> When FedEx starts delivering for $0.34, let me know and I'll also gladly switch.
Well, maybe there's such as thing as too cheap.
> BTW: compare the delivery area of US -vs- Deutschland. Alaska itself is bigger than that.
That is true, but doesn't explain the stack of munged letters I've received over the last decade. Tearing up a letter in a machine and then sending it to you with a simple "sorry" doesn't exactly qualify as "amazing" service. Passable, but not amazing.
Slashdot Mirror
> I'm not sure we can count on accurate of translationedspecific words in article, however...
> I'm not sure exactly what property is the most significant in stopping bullets
Well, the article clearly uses the word "hardness", not "strength" (I do speak German), and given the context in which it is used (research into bullet-stopping materials), I'd say it's pretty clear that the bullet-stopping type of hardness is meant here. If it had the properties of jello WRT stopping bullets, I don't think they'd waste their time on it.
hart (Härte): hard (hardness)
stark (Stärke): strong (strength)
I do speak German, I've read the article, and they're saying exactly what you think they're saying: it's three times harder than hardened steel. Now they just need to make it a bit more transparent and less milky.
> but will it consume considerably more space on our shelves?
I don't see why it would have to. A cartridge could be the same size as current half-width CD cases, and even smaller because the hinge area wouldn't be needed. They could even replace the sliding metal cover with a molded-in slow window to make it even cheaper and more robust--although I don't know how close to the CD surface the lens has to be to focus properly.
Well, he's right, the Tommys developed those laser guns to fight the secret German UFOs, which we NOW all know were almost ready for combat.
A ScanJet 4c (I think) we got back in 1994 had a Jukebox.exe program on the driver disk. It's been a while, but I believe it let you play MIDI files on the scanner stepper. Quite clearly, too. I think they yanked the program later on, though, I've never been able to find it again.
I think DrPizza's only failing was to fully bring over to you the notion that Java bytecodes are higher level than IL: they make considerably more assumptions about the nature of the high-level language than do IL instructions. IL is essentially platform-neutral assembly language, so any code you could express in assembly you pretty much can in IL. You should be able to write an IL compiler for any existing language, provided you don't expect the resulting code to be reusable in any OO fashion by other .NET languages. The .NET-ness you object to only comes in when you are trying to expose a reusable object hierarchy that other .NET languages can inherit from, or when you want to take advantage of the CLR infrastructure (such as gc). In that case, the (high-level) language has to impose conforming restrictions.
Take things like C++ templates, or operator overloading, or multiple inheritance, or contracts: all these high-level constructructs are things that only the respective compilers have to worry about. The resulting object code knows nothing about any of this. A weak analogy: you can write a DLL that exposes a single function which fills in a buffer with memory offsets that your code (and only your code) can use as function pointers to call, or you can write a DLL that exposes all those "proprietary" functions as regular DLL entry points which any program can use. Both DLLs will work just fine, but only the latter will be of any use to a wider audience.
Cute, but how would that work for the more awkward products in life: tampons, itch cream, SUVs that don't fit in NYC apartments?
Since they're "open" to new languages (although, given the specificity of the requirements, it seems someone already made up their mind), Delphi would make a very good choice. They seem to want a good RAD IDE and OO, which are both a "check" with Delphi. It doesn't do gc, but then again, how many x-platform languages with operator overloading do? Many people tend to mean Unix (and often Linux) and Windows when demanding x-platform capabilities, and Delphi addresses both to a very large extent (except the few percent of non-x86 Linux machines). Plus, it's got real to-the-metal horsepower, as opposed to most gc'ed languages.
...with increased non-linearity of television. Just like web-based advertising is struggling because of its awkward fit with the medium, so will traditional commercials with on-demand or pseudo-on-demand (e.g. TiVo) television. They will simply HAVE to rethink their revenue model, which may very well end up very different from what we have today. They might try DVD-like forced viewing, where embedded codes prevent the playback device from skipping certain segments (i.e. commercials), but I don't know how well this scheme would go over with the much larger TV-watching public. Still, I fear that it's in our future, simply because it's technically feasible and requires a minimal change of revenue model.
With on-demand programming, a more natural model would be pay-per-view, but where the viewers pay the actual cost of producing the content. Of course, adjustments would have to be made at both ends: PPV costs would be higher, and content producers would have to learn to cut costs (i.e. get budgets back down to earth). It seems that one of the upshots of on-demand television will be less programming, since only saleable programs will make the list. Then again, with broadband distribution many more small shops with more modest budgets and salaries could get access to your living room, increasing the choice of programming.
> And what the hell is that coocoo-land and how is that different from laalaa-land ?
In coocoo-land cuckoos sing laalaa...
-
> why has this whole thread been taken as a troll?
Mainly because the original post was extremely unclear in meaning. Here's an example:
> OK, in say about 85, how many german computers were on the market and popular ? Ok now remeber
> back and look at the computers in the american market?
I have no idea if you mean that there were many popular German computers, or few. The answer certainly isn't self-evident. All I know is that every kid in the early to mid 80s in Germany craved first a C64, then an Amiga. Not terribly German AFAIK. German computer manufacturers were mainly in the minicomputer and mainframe business, IIRC.
Anyway, I'm German but have lived for the last 15 years in Australia and the US, so I can tell you from experience that Germans and Americans are more alike than different. Germans (used to) hate to buy on credit, they value education and the arts, and they speak German, not English. Other than that, the similarities are striking: both are pathologically self-important, both pine for a house on their own piece of land, both love cars, both work too hard for not enough money. The German love for quality is either a myth, or dying fast, because I haven't seen any more quality conscious Germans (at the production end) than Americans. Sure, both like BUYING quality, but if it's lacking, all they do is whine. Incidentally, the similarity is hardly accidental, considering the percentage of German ancestry in the US.
-
Ok, I can see the words, and individually I can even look them up and find them in the dictionary. But taken as a whole--what do they mean? I'm stymied.
-the "mindset is different"--how?
-usability not important--how? As an aside, the "form follows function" school of design was born in Germany. The US prefer the "mine is bigger than yours" approach.
-pushing something on them isn't going to fly--what on earth do you mean?
Overall, I'd rate the entropy of this post at 95 on a scale of 0 to 100.
-
Ok, your logic is not unlike the "You started it" argument in Fawlty Tower's "The Germans":
German: "Will you stop mentioning the War?"
Basil: Well, you started it.
German: No, we did not!
Basil: Yes, you did. You invaded Poland!
Notice the subtle shift from the current topic to coocoo-land?
-
> The United States has been a Very Rich nation for a long while, without a war on our soil for
> over 125 years.
You keep bringing this up, what's its relevance to the point(s) you're trying to make? For the record, major contributors to America's wealth were its richness in resources and the constant influx of immigrants with tireless work ethics. The lack of wars is due in no small part to the scarcity of international borders to nations of similar size. This was achieved by usurping the land of the natives without any serious resistance.
Again, for the record, several European nations have pined for those lofty goals (i.e. resource richness, large workforce, few bordering foes) throughout the period of America's statehood. But alas, the natives resisted more forcefully, not understanding the full benefits of large-nationhood and homogenized language and values.
-
> Kylix is slow as hell, mainly because most of
> its GUI components are driven through Wine.
<sigh> Wrong. The Kylix IDE uses WINE and is slow as molasses, the compiled executables only use Qt and are much less so. Still, the compiled GUI code is slower than it could be for various reasons, probably also because of the necessary OP to C++ binding. There's something to be said for plain C environments.
-
> Your faith in the harmlessness of DRM in the face of open honest competition is touching. (:
Hardly faith, I'm just not convinced that the issue of DRM gets worse by moving the codec to the medium. If DRM is embedded in the hardware, all content providers will have to interact with it. If it's in a codec that is read off the medium, you're free to create content that uses DRM-free codecs, and to not buy content that does use DRM.
-
I admit that it could open a whole new chapter of nastiness on the part of thusly inclined content vendors. However, it would also open the door for the "good guys", allowing small production companies to use open codecs to play their stuff in an unrestricted fashion on the same hardware that the big houses are using to enforce their DRM nonsense. In the end, it could give you, the consumer, more power, allowing you to vote for playback technology with your wallet, while still not being limited in the range of hardware you can buy. For example, try buying an Ogg Vorbis hardware player today.
-
Move the codec from the player to the content. Hardware manufacturers would get together and establish an Open Player Platform or something, which essentially standardizes the instruction set and capabilities of the player and the image format of the codec executable. When you insert a medium and hit play, the player first examines the content file for the required codec, which must also reside on the same medium. It then loads the codec image from the medium and executes it against the content file.
This approach would have several advantages: allow content creators to use different codecs optimized for the content (e.g. action/animation/quality-vs-runtime etc.), eliminate codec costs to the manufacturer, and future-proof the players to a certain extent. Currently, the main disadvantage would be the high(er) cost of the player.
-
> Linus used a PC and Linux was a few years old
> before it ran on the Amiga.
I was talking about Minix, which ran on the Amiga before Linux ran on the PC.
> I don't think any of Linus' decisions back then had anything to do with Amigas.
You're most likely right, and I did say as much.
> Do you really like Amigas *that* much?
Did, not do. There simply was no equivalent to Linux today during the late 80s on the PC, and certainly not before the 386. If you wanted a preemptively multitasking system with flat memory that was supremely hackable and yet affordable to the average home user, there was little choice besides the Amiga. In terms of pure MHz the early 386s might have been ok, but given their plain framebuffer (VGA if you were lucky) displays and no sound to speak of, their overall performance quite sucked.
Eventually though, the PC hardware far surpassed anything the Amiga had to offer, and the plethora of OS choices made the switch to Intel a no-brainer. Today I would certainly need very strong arguments to move away from the PC.
-
> Yes, that's why Linux was first developed on Amigas.
> Man, where would you *ever* get such an idea?
From being there, mainly. Linux originally evolved from Minix, which existed on many more platforms than just the PC. When Linus started dabbling on the kernel, the Amiga had already peaked and was declining, what with Commodore not doing anything whatsoever. Linus either saw the writing on the wall, or maybe he always was a clone guy, I don't know. I'm not saying everyone was an Amiga nut back then. In hindsight he certainly chose wisely.
-
> Bullshit. The really 7337 hackers were on the Atari 8-bits and C64's.
Not at the time the original poster mentioned, not anymore. Flamebait or not, but during the mid- to late 80s there was the Amiga, and then there was everything else.
-
> There was a HUGE PC demo scene in the early 90s.
Early 90s? We're talking mid- to late 80s here, back when the PC was spending 80% of its CPU cycles servicing the keyboard. There wasn't much to demo on the PC back then.
-
> I was S000 37337! :)
> Man I wish I had Linux 2.4 and Debian back then !
Sorry to burst your bubble, but the really 7337 hackers back then were busy writing Amiga demos (and zillion disk copier progs). Many of them went on to become part of the first generation of Linux hackers. The closest thing to the Linux community (in terms of size and enthusiasm) back then was the Amiga community. The only ones bothering with the PC were Leisure Suit Larry addicts.
-
if someone presented an attempt at a proof of free energy using established formal methodologies, and showing a full understanding of the existing body of knowledge, one might be willing to sit down and give them the benefit of the doubt. But claims of breakthroughs in harnessing free energy invariably always come from individuals proposing new configurations of magnets, crystals, capacitors, or any other easily obtainable items with properties poorly understood by the ignorant.
Whenever the harnessing of a new source of energy will eventually take place, you can rest quite assured that it won't come through the banal realization that "oh, we've never tried arranging curiously strong magnets in the shape of the Number Of The Beast" or any other such nonsense.
-
> When FedEx starts delivering for $0.34, let me know and I'll also gladly switch.
Well, maybe there's such as thing as too cheap.
> BTW: compare the delivery area of US -vs- Deutschland. Alaska itself is bigger than that.
That is true, but doesn't explain the stack of munged letters I've received over the last decade. Tearing up a letter in a machine and then sending it to you with a simple "sorry" doesn't exactly qualify as "amazing" service. Passable, but not amazing.
-