Because now, everyone will have to use a third-largest wind tunnel, and just dream about the days when there was a second largest wind tunnel and even a largest wind tunnel.
Riding on the sidewalk doesn't necessarily make you safer. I have been nailed by a car TWICE in the same year while riding my bike, and both times is was ON THE SIDEWALK!
Yeah, well they do make riding on the pavement illegal for a reason, sonny. I've been riding my bike on the road since time immemorial and have only had one accident. That was on an oil patch on a junction on a wet road; luckily the thing coming the other way was a motorbike so I could simply roll out of its way.
This item claims that computers have become 10000 times faster in the last 20 years, but I hasten to disagree. Application of Moore's Law suggests they have become 10321 times faster...;-)
Oh I agree, I use it (version 0.80 I believe) as my default WM here. However, that's because I've a few years experience of using NeXTStep under my belt. My colleague had a number of years of Windows experience behind him, so Window Maker probably wouldn't have been very intuitive to him. KDE3, on the other hand, is pretty much designed to behave like Windows (especially XP), so it was a much better choice for a beginner.
After he's got comfortable with using the OS, I'll mention things like memory footprint and loading times and get him to try something else...:-)
Without UV radiation that comes from the sun through windows, humans would become very ill or die
I can assure you, having done practicals in Atmospheric Physics involving UV spectroscopy, that glass is opaque to UV light, by and large. Hint to anyone taking a Physics degree: you're not too lazy to throw the detector out the window, then pull it back in when the spectrograph is complete...
What I really don't understand is why some distros supply screenshots on their webpage, or why there is screenshots in reviews.
Because not all desktop PC users have used KDE 3.1 before, perchance?
I recently helped a friend to install RedHat 8 on his laptop (no mean achievement...the PCMCIA hardware wouldn't play ball but that's a different thread), and the one thing he was most worried about was whether or not he'd be able to work out how to use the browser/mail client/office software/etc. As you could probably imagine, he wanted to know whether he could do normal stuff first, kernel hacking later.
So to him, the ability to see screenshots of the window manager in advance would have definitely been A Good Thing, and the distributors should supply such screen shots if they would like newbies to come to their distro. Imagine if he'd installed it, wanted to check his e-mail and found that it defaulted to twm, or even Window Maker.
If this was redhat, with it's special kde & gnome mixture thing (correct me if i am wrong)
RedHat doesn't mix GNOME and KDE, it supplies both but defaults to GNOME. What you're probably thinking of is BlueCurve, their custom home-grown skins for both window managers that are intended to nullify the difference between the two. Also in an abstract way it makes them look not dissimilar to Windows XP user interface, which is another bonus for switchers.
Perhaps I might be, if I used a.NET Passport for any serious work. I don't, and the state of the world is not yet at the point where it should be deemed necessary for anything.
I have a couple of passport accounts, one for.LINUX AMSN, and one for my WinXP account. Past my name (which is also in my Slashdot account details;-) they contain no real information about me.
Come to that, I don't tend to use long-term authentification information for anything. All of my online transactions are done once-off through companies with SSL transactions, and if they cannot provide this then I deal with them in person or not at all. I most definitely leave all One-Click-type functions off.
So what am I wittering on about? Well, I think your Orwellian view of the Passport is not relevant now, nor do I think it is likely to be in the future. I know people who use their WinMachines for surfing the web and reading e-mail, maybe the occasional game of Minesweeper, who will not use Passport or any similar system, no matter how secure they claim to be, on the basis that it's stupid to. If you put all of your private information under the protection of someone you don't know then you effectively have no control over 0wn0rship of that information.
During a talk here in Oxford University's computing lab, Eric Raymond proclaimed that "UNIX died because it was closed-source", and then refused to accept that Microsoft's multi-billion dollar success suggested that otherwise.
In a more recent talk at the Comlab, a Microsoft demonstrator said that one of the most exciting things about.NET was the shared source scheme, through which you could obtain source code for the CLR.
He then explained that this wasn't the same source code as that which the CLR actually used. Kindof suggests that although Microsoft are paying attention to the increasing call for Open Source, they still don't quite get the point.
I realise I've gone offtopic now, I just wanted to prove what a useful tool the 'net can be. Two people a few tens of yards away from each other can now communicate via a server in America, ain't technology wonderful?:-)
The part of this post I found the most interesting, was after having written a full screen (although this is, of course, an implementation-dependent quantity) of text explaining how we should never rely on written definitions of words, but should instead rely on the dictionary definition[1] (which is, umm....), you followed up with this tour de force:
Get over it and move on. Find a more fruitful battle to fight.
This would presumably be further fuel for the adage do as I say, but not as I do.
BTW there's no such thing as a byte data type in C. The C spec does, however, specify the byte as a unit of store.
More BTWage: to disprove the validity of a dictionary in defining the use of a word, one merely needs to look in another dictionary. For instance, two dictionaries spell the word meaning to prefer over other alternatives as favour and as favor. One dictionary calls artificial flying machines airplanes, another aeroplanes, a further Flugzeugs and yet another avions.
I think the moral here is probably that I should avoid countering one joke with another flippant comment around here. And possibly that as long is one is sensible in clearing ambiguities of definition, one should not be challenged over one's use of a word. For instance I clearly stated that I was using the C definition of a byte, only to be replied to by either ignoramuses or bigots who couldn't believe that their "one true byte" was only one possible definition. Not including you in that statement, BTW.
[1]Which is something I refuse to do in certain cases, as this would require me to acknowledge the existence of leverage as a transitive verb. Which it most blatantly isn't. it is and always will be a noun.
Neither the Jargon File nor the C specification is a sufficient source of authority to redefine the byte as you see fit.
IYHO. IMHO, the C standard is sufficient, and the independent corroboration from a well-researched source like the jargon file confirms the definition. We'll just have to agree to disagree. BTW if the definition I quoted was a "redefinition", then so is the eight-bit byte. The original use of the word byte by IBM programmers referred to the size of whatever information chunk they were considering.
Furthermore, if a byte's definition is so fluid, what does this say about other units of data width, such as the nybble?
It leaves them as arbitrary as they always were. It's obvious to anyone who's ever programmed cross-platform (or bought a hard drive) that the only unit of data guaranteed to be the same everywhere is the bit. For instance I wouldn't rely on the eight-bit byte when using a serial port for communication, because it could require sending two chunks of data, if the DTE and DCE were configured for seven bits + chuvmey.
A byte is a bite of information. However, the word bite can easily be misspelt bit, while byte cannot. The byte is not eight bits by definition, and you blatantly did not read the reference I gave to the correct definition of byte, nor any of the other fine references available. You're not only wrong, but ignorant and I claim my five pounds.
Most of the early IBM mainframes were pertty two-bit, yes. Actually the byte as in what IBM are going to call this lump of data varied from one to six bits according to that AC post earlier in the thread, until they decided on EBCDIC as a character coding when it became eight bits. It's likely that if they had some process that had three or four output levels (e.g. OK, garbage in input, run out of cards, printer on fire) then they would have referred to its output as a byte and used two bits to store it.
You have to buy it from the ISO, AFAIK [though it's pretty cheap, 44 Swiss Francs]. Assuming that you're in America (which I have no reason to do whatsoever, but at least it's a start;-) you can purchase it through The American National Standards Institute, you're looking for standard ISO 9899:1999, "Programming Languages -- C".
It's pretty much a necessity to have a reference copy of this if you intend to be writing any cross-platform C code. While Kernighan+Ritchie only deals with platform-agnostic C code, they don't always tell you where the mistakes that they are avoiding lie.
Indeed they were, and as an AC points out elsewhere on this thread with reference to the Jargon File; the byte was originally defined as the size of a useful chunk of information on an IBM machine. Back then the byte was smaller than an octet, and its size varied depending upon the size of the information chunk in use. Note further that the jargon file also defines the byte in the same way as the C standard; I just happen to have more respect for ISO than I do for ESR (though Nethack is a fine game), and thought the C99 document to carry more weight than a hacker's dictionary. Perhaps I was wrong on that last count.
But the punchline is strengthened; the byte is defined in multiple sources as the size of a character variable. One use of this form of the word byte has been shown to predate the incorrect definition of a byte as strictly equal to an octet. Case rests.
You're failing to read the C standard, in which a byte is defined as the smallest addressable unit of memory in which a single character from the execution character set may reside.
Just because you're using 16 bit unicode does not change the size of the byte, it simply means that your "char" is two "bytes" (if your bytes are 8 bits). Why would a unicode system half the resolution of memory just because of the character set used?
It wouldn't. However it would mean that the byte becomes sixteen bits long, even if the smallest physically addressable unit of store is eight bits long. You're confusing "byte" with "octet". BTW if I used a 16bit Unicode system as my execution character set, then the byte would be two octets long. The computer would still be able to address a snigle octet, I'm not arguing that this somehow magically changes. However the execution platform would have no need for the odd-numbered octet locations as they all lie halfway along units of storage. Think of it like this: I could have a seven-bit character set and an eight-bit byte, but be using a processor that can address four-bit locations (call 'em nybbles). The fact that my char variable is now longer than an addressable unit of store is immaterial; the byte is still an octet even though the computer can address quartets.
You could have a byte of 8 bits, a character of two bytes, or a byte of 128 bits and a character of 256 bits.
No you can't. See above, see the standard, learn, comprehend, become enlightened.
I don't know about you, but where I come from all bytes are pretty much 8 bits in size.
You work with pretty old computers like the IA32 then, and ancient character sets to boot:-P
Where I come from (which is C), the byte is defined as the smallest addressable unit of store (memory, IOW) that can hold one character from the execution character set (i.e. the number of bits in a char). If I'm using ASCII, then the character set is seven bits wide and the smallest addressable unit of store on an i686 is 8 bits, so the byte would be 8 bits. If I'm using EBCDIC on a computer that can address eight-bit-wide units of store, then the byte is still 8 bits.
But now consider a computer that can address eight-bit-wide areas of store, but my OS uses 16-bit Unicode. The byte is now 16 bits, as that's the smallest chunk of memory that can hold a single char. Or a computer that deals in 32-bit-wide chunks only, but I'm (for some Godforsaken reason) using Baudot coding as my execution character set. Now my character set only takes up five bits, but as the minimum addressable unit of store is 32 bits wide, the byte has to be 32 bits.
Man, I need to get me some of them new magic size-changing bytes! Down with the tyranny of 8-bit bytes!
A common misconception is to think that the byte and the octet are interchangable concepts. They aren't. The octet is eight bits, the byte is defined as above (see the ISO C99 standard, for example). It's probable that every system you've used has an 8-bit byte; but don't start thinking that's a universal concept.
I own a speccy, a QL and a Z88 (those are the Sinclair machines, I own more computers in total). I did indeed know that there were cartridges available for the interfaces, and had you read my post before replying to it you would have known this. Here, just for you I'll give you another try.
You may be thinking of the very very VERY small number of cartridge games (i.e. 2) that were available for extensions like the multiface, etc.
Now even if irony's a difficult concept for you to grasp, the fact that I mentioned the cartridge games ought to be a giveaway that I knew the cartridge games existed. You mentioned two games, I mentioned two games, I believe we are in brilliant agreement. However, I believe (having used the site for a number of years) that most of the WoS stuff is either RAM snapshots or audio tape image files. Not ROMs:-) Anyway, let's move on from that.
My sister's just got a PS2; it's reasonably nice but I think I'll stick with Chuckie Egg on the Dragon 32 for now. Oh and The Ring of Darkness, the game that was then what ADOM and nethack would like to be now.
Your P.S. was correct. The Donkey Kong name, the characters Mario, Donkey Kong and Daisy etc. were all licensed from/ripped from Nintendo. In either case, Nintendo have the right to claim distribution denied if they so wish.
A similar thing occurred on the Dragon32 (now there was a nice computer) when Microdeal created a rip-off version of Donkey Kong which, imaginatively, they entitled Donkey King. Nintendo got in a huff, and made them change the name of their program to The King. Which they did. Shortly they released a rather good game called Junior's Revenge, in which Kong's son Junior kidnapped Mario and Luigi had to go through about five screens of dodgy platform-style japes in order to rescue him.
FWIW there are licensed games on the site which are still actively protected: e.g. Sega's Frogger.
Slashdot Mirror
I'm posting this on a ZX Spectrum via home-rolled TCP/IP stack. Do I win a 12" powerbook?
The first bit made sense: Students Use 802.11g To Save Cable. After that it went downhill a little.
Because now, everyone will have to use a third-largest wind tunnel, and just dream about the days when there was a second largest wind tunnel and even a largest wind tunnel.
Yeah, well they do make riding on the pavement illegal for a reason, sonny. I've been riding my bike on the road since time immemorial and have only had one accident. That was on an oil patch on a junction on a wet road; luckily the thing coming the other way was a motorbike so I could simply roll out of its way.
This item claims that computers have become 10000 times faster in the last 20 years, but I hasten to disagree. Application of Moore's Law suggests they have become 10321 times faster... ;-)
Oh I agree, I use it (version 0.80 I believe) as my default WM here. However, that's because I've a few years experience of using NeXTStep under my belt. My colleague had a number of years of Windows experience behind him, so Window Maker probably wouldn't have been very intuitive to him. KDE3, on the other hand, is pretty much designed to behave like Windows (especially XP), so it was a much better choice for a beginner.
After he's got comfortable with using the OS, I'll mention things like memory footprint and loading times and get him to try something else... :-)
I can assure you, having done practicals in Atmospheric Physics involving UV spectroscopy, that glass is opaque to UV light, by and large. Hint to anyone taking a Physics degree: you're not too lazy to throw the detector out the window, then pull it back in when the spectrograph is complete...
Because not all desktop PC users have used KDE 3.1 before, perchance?
I recently helped a friend to install RedHat 8 on his laptop (no mean achievement...the PCMCIA hardware wouldn't play ball but that's a different thread), and the one thing he was most worried about was whether or not he'd be able to work out how to use the browser/mail client/office software/etc. As you could probably imagine, he wanted to know whether he could do normal stuff first, kernel hacking later.
So to him, the ability to see screenshots of the window manager in advance would have definitely been A Good Thing, and the distributors should supply such screen shots if they would like newbies to come to their distro. Imagine if he'd installed it, wanted to check his e-mail and found that it defaulted to twm, or even Window Maker.
RedHat doesn't mix GNOME and KDE, it supplies both but defaults to GNOME. What you're probably thinking of is BlueCurve, their custom home-grown skins for both window managers that are intended to nullify the difference between the two. Also in an abstract way it makes them look not dissimilar to Windows XP user interface, which is another bonus for switchers.
Perhaps I might be, if I used a .NET Passport for any serious work. I don't, and the state of the world is not yet at the point where it should be deemed necessary for anything.
I have a couple of passport accounts, one for .LINUX AMSN, and one for my WinXP account. Past my name (which is also in my Slashdot account details ;-) they contain no real information about me.
Come to that, I don't tend to use long-term authentification information for anything. All of my online transactions are done once-off through companies with SSL transactions, and if they cannot provide this then I deal with them in person or not at all. I most definitely leave all One-Click-type functions off.
So what am I wittering on about? Well, I think your Orwellian view of the Passport is not relevant now, nor do I think it is likely to be in the future. I know people who use their WinMachines for surfing the web and reading e-mail, maybe the occasional game of Minesweeper, who will not use Passport or any similar system, no matter how secure they claim to be, on the basis that it's stupid to. If you put all of your private information under the protection of someone you don't know then you effectively have no control over 0wn0rship of that information.
In other news, the world is round, Bill Gates is rich, twice two is four, and the England cricket team haven't won anything.
In a more recent talk at the Comlab, a Microsoft demonstrator said that one of the most exciting things about .NET was the shared source scheme, through which you could obtain source code for the CLR.
He then explained that this wasn't the same source code as that which the CLR actually used. Kindof suggests that although Microsoft are paying attention to the increasing call for Open Source, they still don't quite get the point.
I realise I've gone offtopic now, I just wanted to prove what a useful tool the 'net can be. Two people a few tens of yards away from each other can now communicate via a server in America, ain't technology wonderful? :-)
You know, I've spoken to people who think it iWorks.
The part of this post I found the most interesting, was after having written a full screen (although this is, of course, an implementation-dependent quantity) of text explaining how we should never rely on written definitions of words, but should instead rely on the dictionary definition[1] (which is, umm....), you followed up with this tour de force:
This would presumably be further fuel for the adage do as I say, but not as I do.
BTW there's no such thing as a byte data type in C. The C spec does, however, specify the byte as a unit of store.
More BTWage: to disprove the validity of a dictionary in defining the use of a word, one merely needs to look in another dictionary. For instance, two dictionaries spell the word meaning to prefer over other alternatives as favour and as favor. One dictionary calls artificial flying machines airplanes, another aeroplanes, a further Flugzeugs and yet another avions.
I think the moral here is probably that I should avoid countering one joke with another flippant comment around here. And possibly that as long is one is sensible in clearing ambiguities of definition, one should not be challenged over one's use of a word. For instance I clearly stated that I was using the C definition of a byte, only to be replied to by either ignoramuses or bigots who couldn't believe that their "one true byte" was only one possible definition. Not including you in that statement, BTW.
[1]Which is something I refuse to do in certain cases, as this would require me to acknowledge the existence of leverage as a transitive verb. Which it most blatantly isn't. it is and always will be a noun.
IYHO. IMHO, the C standard is sufficient, and the independent corroboration from a well-researched source like the jargon file confirms the definition. We'll just have to agree to disagree. BTW if the definition I quoted was a "redefinition", then so is the eight-bit byte. The original use of the word byte by IBM programmers referred to the size of whatever information chunk they were considering.
It leaves them as arbitrary as they always were. It's obvious to anyone who's ever programmed cross-platform (or bought a hard drive) that the only unit of data guaranteed to be the same everywhere is the bit. For instance I wouldn't rely on the eight-bit byte when using a serial port for communication, because it could require sending two chunks of data, if the DTE and DCE were configured for seven bits + chuvmey.
As it happens I'm usually pissed off when I buy a 40Gig hard drive, only to find that they meant 4*10^9 octets.
A byte is a bite of information. However, the word bite can easily be misspelt bit, while byte cannot. The byte is not eight bits by definition, and you blatantly did not read the reference I gave to the correct definition of byte, nor any of the other fine references available. You're not only wrong, but ignorant and I claim my five pounds.
A code magpie :-)
Most of the early IBM mainframes were pertty two-bit, yes. Actually the byte as in what IBM are going to call this lump of data varied from one to six bits according to that AC post earlier in the thread, until they decided on EBCDIC as a character coding when it became eight bits. It's likely that if they had some process that had three or four output levels (e.g. OK, garbage in input, run out of cards, printer on fire) then they would have referred to its output as a byte and used two bits to store it.
You have to buy it from the ISO, AFAIK [though it's pretty cheap, 44 Swiss Francs]. Assuming that you're in America (which I have no reason to do whatsoever, but at least it's a start ;-) you can purchase it through The American National Standards Institute, you're looking for standard ISO 9899:1999, "Programming Languages -- C".
It's pretty much a necessity to have a reference copy of this if you intend to be writing any cross-platform C code. While Kernighan+Ritchie only deals with platform-agnostic C code, they don't always tell you where the mistakes that they are avoiding lie.
There is no "byte" data type in C. What does exist is a byte, defined as:
This whole language thing gets a lot simpler when you refer to the dictionary :-)
Indeed they were, and as an AC points out elsewhere on this thread with reference to the Jargon File; the byte was originally defined as the size of a useful chunk of information on an IBM machine. Back then the byte was smaller than an octet, and its size varied depending upon the size of the information chunk in use. Note further that the jargon file also defines the byte in the same way as the C standard; I just happen to have more respect for ISO than I do for ESR (though Nethack is a fine game), and thought the C99 document to carry more weight than a hacker's dictionary. Perhaps I was wrong on that last count.
But the punchline is strengthened; the byte is defined in multiple sources as the size of a character variable. One use of this form of the word byte has been shown to predate the incorrect definition of a byte as strictly equal to an octet. Case rests.
You're failing to read the C standard, in which a byte is defined as the smallest addressable unit of memory in which a single character from the execution character set may reside.
It wouldn't. However it would mean that the byte becomes sixteen bits long, even if the smallest physically addressable unit of store is eight bits long. You're confusing "byte" with "octet". BTW if I used a 16bit Unicode system as my execution character set, then the byte would be two octets long. The computer would still be able to address a snigle octet, I'm not arguing that this somehow magically changes. However the execution platform would have no need for the odd-numbered octet locations as they all lie halfway along units of storage. Think of it like this: I could have a seven-bit character set and an eight-bit byte, but be using a processor that can address four-bit locations (call 'em nybbles). The fact that my char variable is now longer than an addressable unit of store is immaterial; the byte is still an octet even though the computer can address quartets.
No you can't. See above, see the standard, learn, comprehend, become enlightened.
You work with pretty old computers like the IA32 then, and ancient character sets to boot :-P
Where I come from (which is C), the byte is defined as the smallest addressable unit of store (memory, IOW) that can hold one character from the execution character set (i.e. the number of bits in a char). If I'm using ASCII, then the character set is seven bits wide and the smallest addressable unit of store on an i686 is 8 bits, so the byte would be 8 bits. If I'm using EBCDIC on a computer that can address eight-bit-wide units of store, then the byte is still 8 bits.
But now consider a computer that can address eight-bit-wide areas of store, but my OS uses 16-bit Unicode. The byte is now 16 bits, as that's the smallest chunk of memory that can hold a single char. Or a computer that deals in 32-bit-wide chunks only, but I'm (for some Godforsaken reason) using Baudot coding as my execution character set. Now my character set only takes up five bits, but as the minimum addressable unit of store is 32 bits wide, the byte has to be 32 bits.
A common misconception is to think that the byte and the octet are interchangable concepts. They aren't. The octet is eight bits, the byte is defined as above (see the ISO C99 standard, for example). It's probable that every system you've used has an 8-bit byte; but don't start thinking that's a universal concept.
I own a speccy, a QL and a Z88 (those are the Sinclair machines, I own more computers in total). I did indeed know that there were cartridges available for the interfaces, and had you read my post before replying to it you would have known this. Here, just for you I'll give you another try.
Now even if irony's a difficult concept for you to grasp, the fact that I mentioned the cartridge games ought to be a giveaway that I knew the cartridge games existed. You mentioned two games, I mentioned two games, I believe we are in brilliant agreement. However, I believe (having used the site for a number of years) that most of the WoS stuff is either RAM snapshots or audio tape image files. Not ROMs :-) Anyway, let's move on from that.
My sister's just got a PS2; it's reasonably nice but I think I'll stick with Chuckie Egg on the Dragon 32 for now. Oh and The Ring of Darkness, the game that was then what ADOM and nethack would like to be now.
Official Frogger by Sega is, AFAIK, owned by Sega. News just in: joint owned by EA/Microsoft ;-)
Your P.S. was correct. The Donkey Kong name, the characters Mario, Donkey Kong and Daisy etc. were all licensed from/ripped from Nintendo. In either case, Nintendo have the right to claim distribution denied if they so wish.
A similar thing occurred on the Dragon32 (now there was a nice computer) when Microdeal created a rip-off version of Donkey Kong which, imaginatively, they entitled Donkey King. Nintendo got in a huff, and made them change the name of their program to The King. Which they did. Shortly they released a rather good game called Junior's Revenge, in which Kong's son Junior kidnapped Mario and Luigi had to go through about five screens of dodgy platform-style japes in order to rescue him.
FWIW there are licensed games on the site which are still actively protected: e.g. Sega's Frogger.