That is the beauty (or curse) of the Bible, almost everything in it can be interpreted in so many ways that you can disprove interpretations until the end of time.
It could be argued that the vast majority of written material can be interpreted in virtually infinitely many ways, not just the Bible. However, few other works have seen any need to be so very re-interpreted as the Bible has. Interpret that as you will.;)
I'd like you to meet a friend of mine: Mr. Question Mark. You know, he really likes being used at the end of sentences that are supposed to be questions (as his name would suggest) -- even rhetorical ones. See, for example, he could be used to construct a sentence such as "Where does it say he appealed?". See, he immediately makes it much easier for the reader to tell that the sentence is interrogative.
What do you say, would you consider making him an acquaintance?
Since he does not seem to, let me take the chance to elaborate on that one. One of the greatest problems with SPF is that you can't forward messages, so SPF would mean the doom of mailing lists. To be more specific about the problem, if I send a mail to a list, it might come from me@foo.com, and in foo.com's SPF DNS record, I have stated the IP address for the mail servers from which mails are allowed to arrive. The mailing list may check that and be content, but then it forwards it to all its members, using its own mail server, which, of course, isn't recorded in foo.com's SPF record. Hence, all receiving hosts (that support SPF) will refuse the message.
DomainKeys doesn't have a problem with that, though. It signs the message body and a select choice of headers (by default, all headers below the DomainKeys header) with a private key (which is only known to the submit servers). The receiving host checks foo.com's DNS for the public key, and verifies the signature. Obviously, this works with mailing lists as well, since it doesn't matter from which mail server the message arrives. All which matters is that the signature can be verified with the public key in the From address' domain's DNS records.
Naturally, it isn't just mailing lists which run into problems. A lot of mail systems rely on forwarding.
I see another situation which could turn out to be a win-win one. If you build into some P2P protocol that the implementing client needs to display a EULA (which comes from the tracker or equivalent), and the EULA from some specific tracker states that anyone affiliated with the RIAA is disallowed from using the tracker, then what would happen if the RIAA actually did make use of the tracker? Wouldn't that bring about either the end of RIAA lawsuits (once every tracker uses the EULA scheme) or the end of EULAs (if the RIAA wins in court)?
Then again, one might wonder if you really need perfect Microsoft Office compatibility to be able to communicate with others. It's not so bad as being unreadable, right?
"Dapper Drake" and "Feisty Fawn" are also official release names. I called them "code names" partly because the GGP did, and partly because they are code names in the sense that they are a code for the real version number. On the other hand, 5.0/5.1/6.0 are not just the versions of the Windows kernels (for one thing, I'm no Windows expert, but I think there was very little kernel change between 5.0 and 5.1, at least little change that wasn't backported), which is quiet visible: Just run winver on XP, and it will say "Microsoft Windows Version 5.1". The "XP" name is only located in the logo at the top of the window. The "ver" command will mention XP, but it does say "Microsoft Windows XP [Version 5.1.xxxx]", and I doubt it would just be reporting on the kernel version.
(in other words, code names suck, but there is no way around them)
Having someone say it so expressly almost makes me wonder if there truly is no way around them, since really everyone seems to use some kind of code names, including Ubuntu, Fedora and Microsoft. As for me, I have always been referring to Ubuntu and Fedora by their version numbers. I don't even know the code names when other people use them. I only use the code names for Windows versions because really everyone seems to do the same, and it just comes automatically (this is/., so people here really should know, but just in case someone doesn't: Windows 2000 is NT 5.0, XP is 5.1 and Vista is, IIRC, 6.0).
But really, why do they insist on these silly code names? I can't see that it makes anything any better, and they do make it worse, since code names cannot be compared like version numbers can. Is it really so that there is no way around it, and in that case, why is that?
B) After the last upgrade fiasco, the Ubuntu devs are putting special care to make sure the update tool works this time, so people can just install 6.06 and then use the update manager to update to 7.04 if they decide they want it.
Alas, how I wish this is something that the Fedora devs would get. The fact that it is so almost impossible to reliable upgrade between FC versions (and not just almost impossible to do it without rebooting), is by far the largest reason that I use Gentoo instead of Fedora.
You know, I would agree with you -- I don't really care if Microsoft lives or dies, because in the end, it's the problem of those using their products, which does not include me (except, of course, when I help people who use them...). However, when I try to browse to the odd webpage which needs ActiveX, or just right out refuses to do anything on any other browser than MSIE, or my university institution expects me to be able to read assignments in Microsoft Word format, or a Wii gaming review site only features gameplay movies in WMV/MMS, I get annoyed. I want to rectify that situation, and if you can tell me any way of rectifying it other than beating Microsoft, I would be very grateful.
Obviously not all platforms use PCI, nor BAR's directly. That's not a function of C, that's a function of the platform.
Most custom platforms just assume the developer knows the addresses of MMIO. In which case you plomp it into registers.
You're arguing that C doesn't provide a portable hardware layer to the low level devices. Well... um neither does Java. A Java VM on, say a gameboy, has no more access to PCI registers than a C program does. What's your point?
I didn't write a single word about PCI (that was you). I was writing about pointer management in general, from the standpoint of C. In case I've made myself unclear, I will summarize our discussion so far, from my perspective:
I explained to the OP that the problem with writing a kernel purely in Java is only that there needs to be a VM, which needs to be written in a language that is runnable on the native CPU.
You argued that it is impossible to write a kernel in a language without pointers, seemingly implying that Java doesn't have pointers.
I tried to explain that Java indeed has pointers. They're just called arrays instead, and have an additional length constraint. I also tried to imply that there is a difference between the existence of pointers and the ability to create arbitrary pointers, and that, while certain (most) compilers have indeed extended the C language to permit creation of arbitrary pointers on most architectures, the C99 standard leaves such actions as "invoking undefined behavior", so there's very little difference between Java and C in that regard.
You argued that you can just read a BAR from PCI and plomp that value down in a register in C and use it as a pointer, and that the same would be impossible to do in Java without resorting to lower layers such as JNI.
I repeated that the pointer creation ability ("plomping") is not at all guaranteed in C, but is created as a language extension in certain (most) compilers. I also cited some specific examples of architectural aspects that would impose constraints on pointer creation. I then argued that you seem to be much more strict with Java than with C, requiring to stick to Sun's Java Language Specification, while with C you allow the arbitrary extensions that are just part of certain (most) compilers. I argued that if you were to do the same with C -- sticking to the C99 standard -- then pointer creation would be impossible, and you would have to resort to lower layers such as assembler to do that, just like in Java, and that it is similarly possible to create a language or library extension in Java to do pointer creation.
Then we come to your latest post:
And yes, some platforms have different memory layouts, addressing rules [e.g. dword aligned], but that's all easily addressable in C. If you look at the Linux kernel for instance, most of it is C with VERY little asm.
I'm not sure what your point is here. If you're arguing against my architectural examples, then I can only say that 1) they were rather unimportant examples to cite possible constraints on pointer creation in C and 2) they were quite more fundamental than just bus alignment constraints or memory map layouts. To show that, let me infer the pointer creation constraints in each of my examples:
A CPU where address register loading is a privileged operation: User-mode programs will suffer bus errors when doing things such as "char *p = (char *)0xdeadbeef;". Malloc would need to be a syscall.
An architecture with separate memory and I/O busses: Where does "(char *)0xdeadbeef" refer -- memory or I/O? C cannot even handle these things.
An architecture with separate byte and word address spaces: If you have an "int *p", you cannot do "char *cp = (char *)p;", since cp and p would then refer to two entirely different memory locations.
Even MMIO can be controlled via C. Often you only have to drop to ASM when the exa
Well PCI hardware [for instance] is not part of the C standard either. But if I read a BAR and get 0x1337BABE as the base address of some register, I can plomp that down into a pointer and use it
Yeah, you happen to be able to do that with most compilers on i386, PPC and SPARC, but there's absolutely no guarantee that you can on any CPU, nor with any compiler. As such things invoke undefined behavior according to the standard, you may just as well get a bus exception, hard freeze or even a compile error when you try such things on an arbitrary architecture. Consider, for example, a CPU where loading an address register is a privileged operation, or an architecture with seperate I/O and memory busses, or an architecture with seperate byte and word address spaces. Although I'm not experienced enough to quote specific examples, I'm not making these examples up. You can browse through the comp.lang.c FAQ to find other amusing architectures.
You can't do that in Java. At least, not without resorting to JNI hacks. And if you're going to drop down to JNI to do all the nitty-gritty work, you might as well stay there.
As long as you're using the term "Java" to refer to "The Java Language Specification" from Sun, then you should also use the term "C" to refer to the ISO C99 standard, in which case you cannot do it in C either, as described above. At least, not without resorting to assembly hacks. And if you're going to drop to to assembly to do all the nitty-gritty work, you might as well stay there, no?
Just as well as Intel's CC, GCC and MSVC are able to extend C as to be able to do "char *p = (char *)0xbabecafe;", I don't see the problem extending the Java language to be able to do "byte[] p = System.createBytePointer(0xbabecafe, length);".
Building a desktop on top of Java, that kinda makes sense. A kernel? No way.
Again, did you ever look at JNode. It might be interesting, considering that they've, well, done that.
Of course, I might well agree that it doesn't make sense to write a kernel in Java -- believe me, you will have trouble finding a more stern opponent to Java as a language than me. It is definitely possible, though. The only difference between doing it in C vs. in Java, is that doing it in C requires less assembly programming.
I've never used C#, so I can't speak for it, but you seem to suffer from the delusion that Java doesn't have pointers. However, that's what Java arrays are. If you think about it, you'll realize that they are exactly the same thing as a pointer in C -- a base address and a size increment. They do have the added advantage of a length parameter, but that doesn't exactly hurt their function.;)
The "difference" between Java and C in this regard is that Java explicitly lacks that ability to create arbitrary pointers. However, ANSI C lacks this functionality as well. The standard leaves expressions such as "(int *)0x1337cafe" undefined. It is merely architecture-specific compilers that define them, to mean things such as loading a numeric constant into an address register. However, as I did mention, *every* kernel needs assembler code anyway, so there's no problem implement a static, native Java method in assembler to do numeric pointer allocation.
Again, just look at JNode (noting, again, that I never did say that I like JNode, but that it is a proof of concept).
Sorry, but the sibling seems to have been kind of clueless. The basic problem with a language like C#, that makes it impossible to use to write kernel code, is that it doesn't actually run on your actual, physical computer. It requires an emulator (what is commonly called a virtual machine), which does run on your physical computer. Obviously, when you write code that runs on a physical computer, you need to write it in a language that is compilable to the binary code of that computer, and the best language currently available for that purpose is, you guessed it, C.
Some might argue that C# and Java code is compilable to native code ("just look at gcj"), but the fact is that those compilers include a huge lump of library code into the final binary which is both written in another language (often C) and that depends heavily on OS functionality.
Of course, in the end, even C isn't enough. When writing kernel code, one will always need assembler in a couple of places to do the really low-level things like setting process control registers in order to do context switching and set virtual memory parameters.
Once the VM code has been written in a low-level language like C or assembly, though, the vast majority of kernel code can be written in a language like Java -- Just look at JNode, which has a small VM written purely in assembler, with all the high level kernel code like scheduling, drivers or the network stack implemented in Java. I do have criticisms against such systems, but it does prove that it is possible to write a large part of the operating system in Java.
And the Microsoft people noted that they will go on drinking Microsoft Milk, since all they have are Microsoft Cups (from which only Microsoft Milk can be drunk) and since they've paid their Microsoft Milk-drinking licenses (which allow the holders to drink and taste Microsoft Milk, but not to look at, smell or listen to the Milk, or use it as a component in baking) anyway, they can at least go on drinking Microsoft Milk until they expire.
Call me weird, but I think that if they test the hardware against a vanilla kernel from kernel.org, then I'd say you can be pretty sure it'll work with any distro.
...and not wondering if you got special discount "Dell hardware" where Dell demanded that reliability or performance be compromised for cost on the Dell system.
I'm really curious about this, as it isn't the first I've heard bad things being said about Dell reliability. At home, I run three old Dell systems as Linux servers ("old" as in one 2x350 MHz P2 PowerEdge, one 400 MHz P2 Dimension and one 500 MHz P3 Dimension), and I've never experienced anything close to hardware instability on any of them. While it is true that I reboot them every once in a while to upgrade the kernel or add hardware, they have all experienced uptime of more than one year, and I have never had any actual hardware problems with them.
I also had three older Dells (two 166 PMMX and one 200 MHz Pentium something) which are now retired due to taking up too much space. I am also running a Dell 900 MHz P3 (Coppermine) as a media computer (playing to the television) and I have a 1998 Latitude CP running FreeBSD for personal computing. I've only ever had a problem with the 200 MHz Pentium system, which had a case of bad PSU (which could most likely have been fixed, but it was due to be retired anyway -- it had actually been running for over a year, and it was only after I had taken it down and just wanted to play with it that I discovered it didn't want to boot --- It should also be added that that particular computer was found at the local scrapyard). The only recurring problem I've had have been failing batteries for the laptop, but I wouldn't expect laptop batteries to lost almost ten years anyway.
Thus, I'm wondering: Whence comes all this animosity to Dell hardware? Has quality worsened since 2000, have I just been very lucky with these systems, or are people just trolling?
P.S. In case you're wondering, I'm not such a Dell fan that I've actually bought all these Dells. It just so happens that my father has the nice habit to give me any old computers that are retired from his company, and I think they subscribe to Dell or something.:)
Now, don't worry -- it's just the same old PR-disguise. I found the second paragraph especially yielding, so I'll translate it for you:
Let's start with Hilf. Under his direction as general manager of platform strategy,...
"We hired Hilf, so that we have the appearance of being OSS-friendly. Under his guise..."
...Microsoft is crafting a multifaceted plan to approach open source from a number of different levels:
"...Microsoft is crafting a multifaceted strategy to attack open source on a number of different levels:"
Linux as an operating system competitor
Needs to be crushed, obviously. It's a competitor.
interoperability with Linux in mixed environments
We need to find a couple of new open protocols, like Kerberos, that we can subtly corrupt and claim interoperability. Hey, it's the other party's fault for not interoperating with our gracious offers, right?
partnering with open source ISVs
We need to make them realize the benefits of developing for Win32 instead. Oh, sorry -- not "make them realize"... I meant, "help them realize". PR, clean-up squad, please!
development of Shared Source Licensing
Embrace, Extend and Extinguish open source at its very base -- its licensing. Also, we should probably go to congress and make^W, umm, help them realize that Shared Source Licensing is the most liberal licensing necessary in this nation.
contributions to and support for community development sites.
While USE flags and such things are quite useful IMO, my primary reason for using Gentoo is the extreme ease with which the while system is updated through distro versions. In Fedora, this is virtually impossible (I've tried the distro upgrade a few times, but it always requires booting from the installation CD and invariably breaks things to the point where it's more convenient to reinstall the entire system and redo everything from scratch). In Ubuntu, it is possible, but it generally requires update ~150 packages and rebooting, and it might still break minor things. In Gentoo, you just change the/etc/make.profile symlink and do a normal update, in which normally about five or six packages have changed a bit.
Gentoo does leave quite a few other things to be wished for, but in my mind, that alone is reason enough to use Gentoo. I definitely don't hope it goes away.
I thought serial -> serial is merely a connection. Do I have to solder something?
You seem to think in strange ways. Indeed, serial -> serial is a connection, but surely, you realize that you have to make that connection with something, or did you think it was wireless?
Either way, to actually answer the question, you don't actually have to solder anything -- you should be able to buy a null modem cable anywhere. However, considering this is Slashdot, don't you think it would be easier to solder it yourself than going out to it? You wouldn't even have to leave your house.:)
What I don't understand is why they provide the listing for a 25 pin cable. Do any computers these days have anything but 9 pin RS-232 ports?
Instead of quoting specific companies, how about pointing to that well known study which shows that Samba is more than twice as fast as Windows Server 2003 for SMB serving?
Not going to end jpg - everyone dissatisfied with JPG is already using RAW. Everyone satisified with jpg will stick with jpg.
You might say that now, but would you bet that's going to be verified once the photo import program shipped with Vista is "updated" to save to WMP by default? It's not exactly as if Microsoft doesn't have a history of using their Windows "monopoly" to push other things. If I'm not entirely mistaken, Vista's new and "improved" sound recorded already saves to WMA by default.
Slashdot Mirror
What do you say, would you consider making him an acquaintance?
Isn't that arguably better than just having an imaginary life, though?
DomainKeys doesn't have a problem with that, though. It signs the message body and a select choice of headers (by default, all headers below the DomainKeys header) with a private key (which is only known to the submit servers). The receiving host checks foo.com's DNS for the public key, and verifies the signature. Obviously, this works with mailing lists as well, since it doesn't matter from which mail server the message arrives. All which matters is that the signature can be verified with the public key in the From address' domain's DNS records.
Naturally, it isn't just mailing lists which run into problems. A lot of mail systems rely on forwarding.
I see another situation which could turn out to be a win-win one. If you build into some P2P protocol that the implementing client needs to display a EULA (which comes from the tracker or equivalent), and the EULA from some specific tracker states that anyone affiliated with the RIAA is disallowed from using the tracker, then what would happen if the RIAA actually did make use of the tracker? Wouldn't that bring about either the end of RIAA lawsuits (once every tracker uses the EULA scheme) or the end of EULAs (if the RIAA wins in court)?
Then again, one might wonder if you really need perfect Microsoft Office compatibility to be able to communicate with others. It's not so bad as being unreadable, right?
"Dapper Drake" and "Feisty Fawn" are also official release names. I called them "code names" partly because the GGP did, and partly because they are code names in the sense that they are a code for the real version number. On the other hand, 5.0/5.1/6.0 are not just the versions of the Windows kernels (for one thing, I'm no Windows expert, but I think there was very little kernel change between 5.0 and 5.1, at least little change that wasn't backported), which is quiet visible: Just run winver on XP, and it will say "Microsoft Windows Version 5.1". The "XP" name is only located in the logo at the top of the window. The "ver" command will mention XP, but it does say "Microsoft Windows XP [Version 5.1.xxxx]", and I doubt it would just be reporting on the kernel version.
But really, why do they insist on these silly code names? I can't see that it makes anything any better, and they do make it worse, since code names cannot be compared like version numbers can. Is it really so that there is no way around it, and in that case, why is that?
Haha! That might be the greatest heap of bile I have seen in a great, long time. Do you feel relieved? :)
I didn't write a single word about PCI (that was you). I was writing about pointer management in general, from the standpoint of C. In case I've made myself unclear, I will summarize our discussion so far, from my perspective:
Then we come to your latest post:
I'm not sure what your point is here. If you're arguing against my architectural examples, then I can only say that 1) they were rather unimportant examples to cite possible constraints on pointer creation in C and 2) they were quite more fundamental than just bus alignment constraints or memory map layouts. To show that, let me infer the pointer creation constraints in each of my examples:
Just as well as Intel's CC, GCC and MSVC are able to extend C as to be able to do "char *p = (char *)0xbabecafe;", I don't see the problem extending the Java language to be able to do "byte[] p = System.createBytePointer(0xbabecafe, length);".
Again, did you ever look at JNode. It might be interesting, considering that they've, well, done that.Of course, I might well agree that it doesn't make sense to write a kernel in Java -- believe me, you will have trouble finding a more stern opponent to Java as a language than me. It is definitely possible, though. The only difference between doing it in C vs. in Java, is that doing it in C requires less assembly programming.
The "difference" between Java and C in this regard is that Java explicitly lacks that ability to create arbitrary pointers. However, ANSI C lacks this functionality as well. The standard leaves expressions such as "(int *)0x1337cafe" undefined. It is merely architecture-specific compilers that define them, to mean things such as loading a numeric constant into an address register. However, as I did mention, *every* kernel needs assembler code anyway, so there's no problem implement a static, native Java method in assembler to do numeric pointer allocation.
Again, just look at JNode (noting, again, that I never did say that I like JNode, but that it is a proof of concept).
Some might argue that C# and Java code is compilable to native code ("just look at gcj"), but the fact is that those compilers include a huge lump of library code into the final binary which is both written in another language (often C) and that depends heavily on OS functionality.
Of course, in the end, even C isn't enough. When writing kernel code, one will always need assembler in a couple of places to do the really low-level things like setting process control registers in order to do context switching and set virtual memory parameters.
Once the VM code has been written in a low-level language like C or assembly, though, the vast majority of kernel code can be written in a language like Java -- Just look at JNode, which has a small VM written purely in assembler, with all the high level kernel code like scheduling, drivers or the network stack implemented in Java. I do have criticisms against such systems, but it does prove that it is possible to write a large part of the operating system in Java.
And the Microsoft people noted that they will go on drinking Microsoft Milk, since all they have are Microsoft Cups (from which only Microsoft Milk can be drunk) and since they've paid their Microsoft Milk-drinking licenses (which allow the holders to drink and taste Microsoft Milk, but not to look at, smell or listen to the Milk, or use it as a component in baking) anyway, they can at least go on drinking Microsoft Milk until they expire.
Call me weird, but I think that if they test the hardware against a vanilla kernel from kernel.org, then I'd say you can be pretty sure it'll work with any distro.
I also had three older Dells (two 166 PMMX and one 200 MHz Pentium something) which are now retired due to taking up too much space. I am also running a Dell 900 MHz P3 (Coppermine) as a media computer (playing to the television) and I have a 1998 Latitude CP running FreeBSD for personal computing. I've only ever had a problem with the 200 MHz Pentium system, which had a case of bad PSU (which could most likely have been fixed, but it was due to be retired anyway -- it had actually been running for over a year, and it was only after I had taken it down and just wanted to play with it that I discovered it didn't want to boot --- It should also be added that that particular computer was found at the local scrapyard). The only recurring problem I've had have been failing batteries for the laptop, but I wouldn't expect laptop batteries to lost almost ten years anyway.
Thus, I'm wondering: Whence comes all this animosity to Dell hardware? Has quality worsened since 2000, have I just been very lucky with these systems, or are people just trolling?
P.S. In case you're wondering, I'm not such a Dell fan that I've actually bought all these Dells. It just so happens that my father has the nice habit to give me any old computers that are retired from his company, and I think they subscribe to Dell or something. :)
Gentoo does leave quite a few other things to be wished for, but in my mind, that alone is reason enough to use Gentoo. I definitely don't hope it goes away.
Either way, to actually answer the question, you don't actually have to solder anything -- you should be able to buy a null modem cable anywhere. However, considering this is Slashdot, don't you think it would be easier to solder it yourself than going out to it? You wouldn't even have to leave your house. :)
What I don't understand is why they provide the listing for a 25 pin cable. Do any computers these days have anything but 9 pin RS-232 ports?
Instead of quoting specific companies, how about pointing to that well known study which shows that Samba is more than twice as fast as Windows Server 2003 for SMB serving?