Ext3 doesn't increase the maximum file size. The maximum file size continues to depend on the block size. On a file system with 4k blocks, the maximum file size continues to be 2048GB.
There is a great number of packages that all fail because virtual inheritance in a multiple-inheritance scenario doesn't work, kde and ORBacus among them. Just ask the GCC GNATS database for all "open" or "analyzed" bugs to see what we are talking about. gcc 3.0.2 won't fix this specific problem, either.
Python will use a "GPL compatible" license, not the GPL. The current license is already an Open Source license; it's just that RMS claims that it is incompatible with the GPL.
> At the risk of sounding anglo-centric, isn't this a big blow against interoperability?
No. First, interoperability is about technical systems working together. I'm certain that any solution will provide interoperability: Any client will be capable of working with any name server.
If you can't type the Asian characters easily, there is a good chance that you can't read the page you get, either. If they also provide contents in English, they may chose to provide an all-ASCII domain name, too.
See http://www.gnu.org/philosophy/x.html. X11R6.4 was licensed restrictively, requiring a per-user fee as I recall. It was only when XFree86 decided not to adopt R6.4 and stay with R6.3 instead that The Open Group reversed its decision and returned to the original (i.e. the current license),
This is an interesting opinion. I have no doubt the experience you made is real, and the conclusions are valid (based on the experience). However, somebody else in a quite similar situation might have a completely different experiences, and arrive at different conclusions.
IMO, there are some factual errors and misconceptions in the text, putting them in a different light might help.
# RPC, ILU, CORBA, DCE, Java RMI and DCOM to name but the most common.
This seems like comparing apples and oranges, partially. Some of them are specifications, some are implementations, and some are both. In particular, ILU is an implementation which supports (Sun) RPC, CORBA. AFAIK, DCE, DCOM, and Java RMI are supported in an experimental stage.
Java RMI is not necessarily exclusive with CORBA, as future RMI implementations in the JDK will use the CORBA wire protocol (i.e. IIOP). Also, DCE and DCOM have great similarities.
# Commercially there are a few good ORBs but they are terribly # expensive.
(Some of) the terribly expensive ORBs are not good. In particular, Orbix has many features, but also many bugs and poor performance. There are some good commercial ORBs that are free for non-commercial use, e.g. ORBacus.
# Additionally most of the commercial ORBS support as few platforms as # they possibly can.
This is true for "most" indeed. Again, ORBacus comes with full source, and supports a wide variety of platforms - it easily installs from source.
# On the Open Source side... some great code out there
This is definitely true.
# What I cannot find at the moment is a system that targets multiple # platforms and multiple languages.
This is a misconception. You don't need a single implementation that targets multiple platforms and multiple languages. For one language, using the same system on all platforms definitely helps (although portability of CORBA code is very high, across CORBA implementations). For a different language, you can use a different implementation: CORBA implementations *do* interoperate.
# Want to use Perl to talk to C++ back ends?
Well, with Perl you are quite stuck, AFAIK, which is unfortunate. There is COPE (on top of Mico, or ORBacus, or Orbix), and there is an ILU integration, but I don't think the code is portable between these two.
For C++, you can do whatever you please - no matter what you were using for Perl. C++ is very well supported in CORBA.
# Want to use the same code on Windows NT as well?
Don't know about ILU-Perl-NT, or COPE-XYZ-NT. C++ support on NT is also very good.
# Want to use Java Applets to talk to C? You have problems.
For Java Applets, I'd either use the VisiBroker for Java inside Netscape, or the JDK ORB, or any other CORBA-for-Java (which would work on any browser, but requires to download the CORBA runtime system). CORBA-based Java applets port to another ORB on the byte code level, since the API for the stubs is defined in terms of interfaces.
For C, you can chose either ILU, or ORBit. Both work great, and also on a wide variety of platforms (ILU probably on more than ORBit). Portability is adequate, you'll have to modify names of header files, and perhaps some function names, because the C mapping is not specified as thoroughly as the Java or C++ mappings.
[More on C Java]
# Problematic at best, and probably not possible at the moment.
Not true at all if you are willing to use different run-time systems for different languages. If you insist on getting both C and Java support from the same source, you'll probably have to use ILU. Due to the interoperability, there is no need to do so.
# Are these very strange requirements/wishes or would other people be # willing to sacrifice ratified standards compliance and possibly # performance for orthogonality of language/platform availability? Neither, nor. The requirements stated above are all reasonable, and can be achieve without sacrificing standards compliance, or performance.
# I would like to be able to write code... (for me this would be # Perl, Java and C++) without having to use multiple implementations # on the different platforms.
Well, *that* is the strange requirement. If that requirement is dropped (and it can be dropped easily), everything is possible.
For these three languages, there is a singe source, though: ORBacus offers built-in support for C++ and Java, and COPE runs on top of ORBacus as well (AFAIK). Starting with ILU 2.0b1, the same set of languages is supported.
Slashdot Mirror
My serial number format lasts longer than Verisign's
Verisign's scheme will last indefinitely. First, the serial number is an unsigned value, so in seconds since the epoch, it will last until 2106.
More importantly, these are serial numbers, not integers. So when they wrap around, they still increase. 1000 > 4294967040
as long as it increases whenever the zone is changed?
Of course, it won't increase on the day this change is made. 1076370400 2004020900
So how do you do "atomic add" with just what the C standard offers you? On i386, you write
:"=m" (v->counter)
:"ir" (i), "m" (v->counter));
static __inline__ void atomic_add(int i, atomic_t *v)
{
__asm__ __volatile__(
LOCK "addl %1,%0"
}
Just tell me how to write this in plain C.
On your system, fsck will still be run on bootup, to repair an uncleanly-unmounted ext3 partition. Of course, all it will do is to replay the journal.
Ext3 doesn't increase the maximum file size. The maximum file size continues to depend on the block size. On a file system with 4k blocks, the maximum file size continues to be 2048GB.
There is a great number of packages that all fail because virtual inheritance in a multiple-inheritance scenario doesn't work, kde and ORBacus among them. Just ask the GCC GNATS database for all "open" or "analyzed" bugs to see what we are talking about. gcc 3.0.2 won't fix this specific problem, either.
Python will use a "GPL compatible" license, not the GPL. The current license is already an Open Source license; it's just that RMS claims that it is incompatible with the GPL.
> At the risk of sounding anglo-centric, isn't this a big blow against interoperability?
No. First, interoperability is about technical systems working together. I'm certain that any solution will provide interoperability: Any client will be capable of working with any name server.
If you can't type the Asian characters easily, there is a good chance that you can't read the page you get, either. If they also provide contents in English, they may chose to provide an all-ASCII domain name, too.
See http://www.gnu.org/philosophy/x.html. X11R6.4 was licensed restrictively, requiring a per-user fee as I recall. It was only when XFree86 decided not to adopt R6.4 and stay with R6.3 instead that The Open Group reversed its decision and returned to the original (i.e. the current license),
IMO, there are some factual errors and misconceptions in the text, putting them in a different light might help.
# RPC, ILU, CORBA, DCE, Java RMI and DCOM to name but the most common.
This seems like comparing apples and oranges, partially. Some of them are specifications, some are implementations, and some are both. In particular, ILU is an implementation which supports (Sun) RPC, CORBA. AFAIK, DCE, DCOM, and Java RMI are supported in an experimental stage.
Java RMI is not necessarily exclusive with CORBA, as future RMI implementations in the JDK will use the CORBA wire protocol (i.e. IIOP). Also, DCE and DCOM have great similarities.
# Commercially there are a few good ORBs but they are terribly
# expensive.
(Some of) the terribly expensive ORBs are not good. In particular, Orbix has many features, but also many bugs and poor performance. There are some good commercial ORBs that are free for non-commercial use, e.g. ORBacus.
# Additionally most of the commercial ORBS support as few platforms as
# they possibly can.
This is true for "most" indeed. Again, ORBacus comes with full source, and supports a wide variety of platforms - it easily installs from source.
# On the Open Source side ... some great code out there
This is definitely true.
# What I cannot find at the moment is a system that targets multiple
# platforms and multiple languages.
This is a misconception. You don't need a single implementation that targets multiple platforms and multiple languages. For one language, using the same system on all platforms definitely helps (although portability of CORBA code is very high, across CORBA implementations). For a different language, you can use a different implementation: CORBA implementations *do* interoperate.
# Want to use Perl to talk to C++ back ends?
Well, with Perl you are quite stuck, AFAIK, which is unfortunate. There is COPE (on top of Mico, or ORBacus, or Orbix), and there is an ILU integration, but I don't think the code is portable between these two.
For C++, you can do whatever you please - no matter what you were using for Perl. C++ is very well supported in CORBA.
# Want to use the same code on Windows NT as well?
Don't know about ILU-Perl-NT, or COPE-XYZ-NT. C++ support on NT is also very good.
# Want to use Java Applets to talk to C? You have problems.
For Java Applets, I'd either use the VisiBroker for Java inside Netscape, or the JDK ORB, or any other CORBA-for-Java (which would work on any browser, but requires to download the CORBA runtime system). CORBA-based Java applets port to another ORB on the byte code level, since the API for the stubs is defined in terms of interfaces.
For C, you can chose either ILU, or ORBit. Both work great, and also on a wide variety of platforms (ILU probably on more than ORBit). Portability is adequate, you'll have to modify names of header files, and perhaps some function names, because the C mapping is not specified as thoroughly as the Java or C++ mappings.
[More on C Java]
# Problematic at best, and probably not possible at the moment.
Not true at all if you are willing to use different run-time systems for different languages. If you insist on getting both C and Java support from the same source, you'll probably have to use ILU. Due to the interoperability, there is no need to do so.
# Are these very strange requirements/wishes or would other people be
# willing to sacrifice ratified standards compliance and possibly
# performance for orthogonality of language/platform availability?
Neither, nor. The requirements stated above are all reasonable, and can be achieve without sacrificing standards compliance, or performance.
# I would like to be able to write code ... (for me this would be
# Perl, Java and C++) without having to use multiple implementations
# on the different platforms.
Well, *that* is the strange requirement. If that requirement is dropped (and it can be dropped easily), everything is possible.
For these three languages, there is a singe source, though: ORBacus offers built-in support for C++ and Java, and COPE runs on top of ORBacus as well (AFAIK). Starting with ILU 2.0b1, the same set of languages is supported.