The checkbook sits at home, whenever I need to mail a payment and the recipient does not accept credit cards (not too many anymore).
Hello? That's the whole point. Sure, American citizens have credit cards that can be used in stores and for purchasing stuff online -- but they have no easy, consistent way of sending money to each other.
That's why a company like PayPal can exist in the US. In many European countries, PayPal is mostly obsolete.
Coming from Norway, PayPal and assorted services do not make much sense to me. I recently had to explain to a friend why personal checks are more or less obsolete in my country.
Within Norway, you can wire money to anybody with a bank account, regardless of which bank I, or they, use. To pay bills, I go online to my bank's Internet service, enter the account number of the person to transfer to, the amount, and the date at which the transaction should execute. Setting up recurring payments is also possible. Transferring between countries is also quite simple using the SWIFT system.
Now, I can appreciate why PayPal appeals to Americans, if only as a temporary stopgap until all your banks allow sending money to each other. In the meantime, my American friends keep "writing checks". Sheesh. Welcome to the future, guys:)
(I once cashed an American check in my home country. It took one month to clear, and the intermediates took a huge bite out of the total amount. Next time I used SWIFT and it took three days and the money were more or less intact.)
As an aside, PayPal only works with American credit cards. I am currently in the US, and in a recent eBay payment my Norwegian credit card was rejected because they could not verify the billing address (and there was no country field available for the billing address). I have also totally failed to buy stuff from MassMerchandise, where they consider my Norwegian email address to be "high risk" (duh!) and their billing-address verification system has problems even verifying American cards.
Many sites actually insist on, or used to insist on, *cough* FrontPage Extensions *cough* for that.
The real solution for the future is WebDAV (and being worked on by the W3C), which fully supports named servers and authentication, and is designed to replace FTP and the various ugly "web posting" systems out there, including the uploading aspects of FrontPage Extensions.
They also used Windows NT for 1/3 of the machines, which explains the presence of (and need for) of those KVM switches.:-)
The article is a good read, explaining the rationale behind their choice of Linux, and comparing their experience to NT, Digital UNIX and other platforms. (There's even the gratuitous server-room shot, looking very much like a 90s version of the "Mother" computer room in Alien -- probably the same picture you saw.)
ADSI has little to do with Active Directory. True, ADSI provides a uniform interface to AD and other directories so you can write apps that (in theory) easily port between directories, and Microsoft's ADSI Active Directory provider also serves as the primary AD API for developers.
However, my understanding is that the Windows domain client components do not use ADSI, but rather are hardwired to use Active Directory. Therefore, a Windows client will not be able to use a different directory service than AD for domain authentication and configuration management.
If Microsoft permitted this, they would effectively be saying, "Sure, you can replace your Win2k server with a Novell box, or a Linux box, or anything that speaks LDAP." They can't afford to give users that flexibility, or Win2k Server would not sell.
In other words, simply having a "Linux ADSI provider" does not help. I am not saying it's not possible -- I am sure that hackers will eventually be able to duplicate AD in an open-source product, just like Samba duplicated NT4's SMB/RPC/SAM stuff -- just that this ain't it.
(Also, I do not believe those links you included are exactly what you think they are. They seem to be libraries to help porting Windows-based ADSI apps to Linux.)
All MSDN documentation, plus most SDKs (not the DDKs) is available for free from Microsoft's MSDN site, and has been for a long while.
Also, ADSI is an abstraction layer over directory services implemented as COM servers, not an pluggable authentication layer -- that's would be the SSPI (Security Service Provider Interface).
(I would like to add that SSPI and the crypto APIs in Windows are, while complex, two well-designed APIs. Probably the accidental work of some summer interns.)
Sorry Earlybird, but if you don't know by now that C++ has late binding and RTTI (which is directly implied by the ext preceeding that part I quoted), there really isn't much point continuing this thread.
Late binding and RTTI have nothing to do with it.
Um, thank you for so courteously implying that I don't know my C++. I have clocked about four years more experience with C++ (back to the time where there was a draft standard that didn't look much like what we have now) than Java.
C++ does not have an ABI. You can't argue against that.
C++ is hellishly unsuited to sharing and using component-like objects. And templates and operator overloading and other tricks do not work across process boundaries. With C++ you end up reinventing Java to do anything useful -- sharing objects, managing memory, and dynamically loading functionality.
To turn the concept around, can you foresee an alternate universe where JINI is written in C++?:)
No, no one has implemented a Java RDBMS, at least in the sense that they ever expected anyone else to use it.
Just because Hypersonic, JDataStore and all the others don't fit your definition of an RDBMS doesn't mean they can't, or that such beasts can't be written (as practical, competetive solutions).
You didn't answer my question, though. What makes a language an "application language" versus a "system/platform language"?
If you can write operating systems in Java (and this Slashdot article implies you can), why not a relational database? In fact, I can't think of a single major OS that was written in C++. Even BeOS is apparently all ANSI C below its high-level application framework.
In fact, I am arguing that Java is particularly suited to systems programming, simply because it leverages OO principles to a higher level in the same way that C++ drags you down to the bottom. Garbage collection and class loading and object sharing can all be added to C++ post-mortem, but once you have dealt for a few months with home-grown reference-counting template classes, strings that can't painlessly box/unbox char*s, and other wrapping stuff that is supposedly so transparent and flexible and elegant, you really wish these things are first-class citizens in your country of residence.
C++ has its good sides, but Java often puts it to shame.
Maybe you misinterpret my conviction of C++ as being a "dead end".
Consider a program you write. You have got all these classes and things. You compile and release. All the information about your program is now embedded implicitly in your program. There's no way for me to take any of those classes and reuse them. That's a dead end.
C++ is very binary-oriented: If I write a web server and servlet framework in C++, then the only viable way for servlets to communicate with the server is through some sort of well-defined binary interface, say DLLs/shared objects or RPC or CORBA or DCOM. Or on a source-code level. I would have to recompile the server each time I added a servlet. Does C++ need an ABI? I don't know. It would have to cover a lot more than just classes.
One of Java's best assets is its notion of dynamic class loading, which could just as easily be done in a native-binary model, although the use of bytecode makes Java's approach more flexible, more adaptive, and of course logistically simpler for porting purposes.
C++ could have had this, but I tend to believe that it has too much crust -- from the preprocessor and reliance on include files and defines, to templates, to its object model (one of my major hassles with C++ is that two classes cannot contain automatic [ie., non-pointer] members of each others' types, because for one of the classes, the other class will be "unfinished" at the point of declaration) -- that does not make the language as suitable for opening up.
I don't buy your argument about system/platform language vs. application language. Plenty of people have successfully implemented forms/servlets in C++ and RDBMS or similar things in Java. What's your point? That Java is too heavyweight or bloated for that sort of thing? Requires a large runtime, what? What makes a language an "application language" versus a "system/platform language"?
As for Ruby, I remember looking briefly at it once and being befuddled by its syntax, but thanks for the reminder -- will check it out again. Are libraries plentiful? Does it connect well with other languages?
There are tons of cool applications of Java, but you chose to show mostly the bad ones.
Standardized (albeit by Sun), extensible APIs, especially on the server end, and extensible products, is part of what makes Java thrive today. Transaction API, J2EE, JNDI, Java2D/imaging, Java3D, servlets, JDBC, CORBA. Plus a host of pre-packaged libraries for things like sockets and RMI. Products: object databases (Ozone, the Castor O/R mapping framework), transaction managers (Tyrex), web servers (Resin, Jetty, Orion, Enhydra), XML etc.
Above all, Java connect to anything, provides a lot of freebies (garbage collection, a simple object model), is high-level and easy to learn, and lets you be more productive right out of the box as opposed to languages such as C++. No wonder new stuff is sprouting up like mushrooms -- a phenomenon that I suppose Bjarne Stroustrup is mildly annoyed about and doesn't quite understand. Once you've written a C++ app, it's a dead end. It not reusable. Unless you wired it up with magical strings and CORBA and reinventing all sorts of technologies, it just sits there.
This is much the same reason Python is thriving, really. Unfortunately, Java currently does not have anything that comes close to Zope. Turbine and Cocoon sound like two different projects aimed at this area, but they're not even close.
Who cares about Amex or set-top boxes? Unless I can write TiVo-like apps on my desktop computer that controls the box in interesting and hitherto-unrealized ways, it's useless, just another closed implementation. And Amex, well, how do I connect to my card, then?
Now:
Both Oracle 8i and IBM's DB2 use Java extensively both for their DB administration GUIs as well as for middleware code. If you didn't know, these are the number 1 and number 2 Enterprise database systems in the world
I wish you hadn't mentioned that. Oracle's bloated, clunky Java GUI stuff is their big black sheep. I wish they never screwed this part up -- Oracle's native NT tools used to be at least adequate. Compare Oracle's present, slow, unstable, overdesigned, Microsoft Bob-like Java GUIs with Microsoft SQL Server 7.0's flashy, fast, and hugely functional tools and you just want to crawl into your mama's arms and cry like a baby.
Java servlets and JSP are used extensively on the web from sites like mail.com to Firstunion.com. Hundreds of sites use Java(TM) to deliver dynamic content these two are simply the most prominent that come to mind.
Servlets is hardly Java's finest moment, same goes for JSP. True, servlets replace CGI in a nice way, and anything is better than ASP and assorted horrors, but that's about it.
Servlets make up a very low-level layer, and servlets themselves are quite isolated entities, compared to the riches of Zope's DTML documents.
Please, developers, do yourselves a favour and read up on how to properly divide content, logic, and presentation. Hint: Putting Java inside HTML gives you no cigar. Look instead at things like Freemarker and Webmacro, or even that bastard son of template processing, XSLT. Even so, these are quite weak tools, and you need to buy a $35,000-per-CPU app server to get any sense of an integrated package.
... you can download the SVG plug-in (2.4meg, Win32/Mac)...
Even taking shoddy engineering into consideration, that's pretty bloated -- compared to Flash plug-in (actually, ActiveX control) which is about 150KB.
Of course, general-purpose compression like gzip is excellent when applied to text.
However, it will never reduce the animation file size down to Flash's extreme bit-tweaked precision (see the Flash format specification for all the tricks they use to reduce size; they sensibly apply dictionary compression techniques to avoid repetition in the data), which is the first reason why we would want an SVG-specific compression algorithm. I have written a conversion tool for turning Flash into XML and back, and there is no reason why a binary representation of [parts of] SVG could not exist.
The talk so far of compression has ignored something extremely central to Flash, which is streaming. Streaming is what made Flash the popular format and product it is today.
In order to compress SVG and still support streaming we would need a multi-part compression system and/or add another XML layer that can hold compressed SVG frame batches as CDATA elements.
Finally, you don't cite your resolution and pixel depth, which affects the size of the PNG file you're comparing to, so your data point doesn't make much sense.
"The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place." (Douglas Adams)
Actually, the iPAQ is based on the operating system formerly known as Windows CE. It uses a 206MHz StrongARM processor. Here's a picture and the specs.
It's an idea that has been used before -- particularly in British SF writer Robert Rankin's The Brentford Chainstore Massacre. The book is not about cloning just one Jesus. The (very mad) scientist in question clones a whole bunch of them. Of course, little goes exactly according to plan. Good book, not Rankin's best, but still a great read, with a typically high chuckle factor.
A year ago or so, a little after Rankin's book came out, an award-winning [for the documentary The Silent Witness: An Investigation into the Shroud of Turin (1982)] British producer named David W. Rolfe announced he was going to produce a film about -- guess what -- Jesus being cloned from the Turin shroud.
One of the original ideas behind CE was to use it as a 'network computer' OS, and also as a settop box system (XBox? WebTV?). The big problem with it is that it's never really gotten used for these things
Not so fast. CE is being used today precisely for use in network computers. Many vendors are currently selling cheap CE-based NCs that connect to Windows NT Terminal Server (now built into into Win2k Server, and no longer a separate product). It's not particularly original, but apparently it works.
Aside from the fact that Terminal Server requires a *stupendous* amount of horsepower (RAM, CPU, motherboard, disk system) to run well with many users, this is, in fact, a great solution -- we're evaluating it for our office, as we find it somewhat pointless to have many employees, who only browse the net and use the same productivity/email apps, sit with $3,000 PCs when they can each connect from $400 terminals to a $10,000 terminal server.
The SIS (Single Instance Storage) service is part of Windows 2000's Remote Installation Service (RIS) which is part of the Zero Administration for Windows (ZAW -- no shortage of acronyms here!) initiative.
Put simply, SIS was designed for NT administrators for the purpose of cloning OS installations to client desktops. With NT 4.0, you're forced to use a third-party disk imaging tool, or use NT's "unattended setup" mode where the installation program installs NT from a script. In large corporations, admins often roll out hundreds or thousands of identical NT installations, and even with just a few copies this process is a huge pain. (I'm saying this as a human being, not as an NT admin. I prefer Linux.)
With Windows 2000, however, you use the Remote Install Server software, which is set up to host all the images you want to copy to desktops -- for example, you can create an image containing a stripped-down NT with Internet Explorer and DHCP client; and another image containing an installation tailored to laptop use. Additionally (as I understand it), the RIS software generates a boot disk containing network drivers and the stub code to load the image from the RIS server.
However, when Microsoft designed this software, they discovered that images take up a lot of disk space -- and that the most of the files are repeated files through the images.
The solution, SIS, is a background service that employs a piece of code amusingly called the "groveler" to scan designated parts of your NTFS volumes. Duplicate files are moved to a special, hidden, top-level system folder called the "SIS Common Store", and a symbolic link (which Win2000 calls junctions) is left behind pointing to the actual file.
It's worth pointing out that SIS was not originally designed to work as an all-purpose, automatic symlinker. Since files are physically moved to a special location on each disk, it could potentially wreak havoc with backup software, as well be extremely confusing to users and admins alike. You can set up SIS for all your files, but none of my documentation indicates that this is particularly wise -- also, there is little to gain from "compressing" regular volumes this way.
Re:Unix programmers need to clean up after themsel
on
The New Garbage Man
·
· Score: 1
Wrong -- Windows (NT, 2000, and even Win95 and Win98) does release process memory.
NT has had numerous issues about system processes and apps leaking memory while running. This is different, though.
If you manage to run an NT box for more than 14 days -- and some people do -- then you might experience a different kind of "leak": The build-up of strange, inexplicable crust-like matter that slowly sticks into the cracks of the system -- a kind of electronic, cholestrerol-like kipple. You feel it, but you can't pin it down. Reboot the machine and it starts up fresh and strangely more agile.
Some have pointed out that NT has problems with memory fragmentation. I have not seen any solid evidence of this. Whatever it is, Linux ain't got it.
It's funny how we're getting closer and closer to Philip K. Dick's reality in his Do Androids Dream of Electric Sheep? (for many people better known as the source material Blade Runner).
In his visionary novel, set in a dystopian, post-apocalyptic future, live animals are mostly extinct, and artificial (designed and genetically engineered, although not robotic) animals and humans exist as luxury objects.
It's ironic and sad that we keep looking for, and hoping to discover, life on other planets, when at the same time we're eliminating those on our own. Someday, as spaceships probe planet after planet for life in remote galaxies and come up emptyhanded, and we realize how special and precious our little ecological fluke of a planet is, we will understand this better. Until then we're doomed to shoot ourselves in our feet, collectively, and unknowingly.
Perhaps one day we'll learn to develop such artificial creatures complex enough to serve as substitutes for the real kind, and we'll forget about the real ones. As human settlements expand (and they do), we'll eventually overrun the animal kingdom, which already has a large number of endangered species.
I suspect that, sometime in the future, not too far off, we will have ceased to look upon the idea of a robotic animal only as a quaint, cute, and practical toy with a convenient "off" button, but as the only available alternative. Welcome to a penguin-less future.
Canticle's ideas about science versus faith are significant and have survived the test of time -- and its ideas about information preserval are if anything more valid today than some forty years ago.
The book is a gold mine of literary pleasures.
Notice, for example, how the tempo of each book is deliberately chosen as time and technology progress, hand in hand -- like a train pushing gradually towards an inevitable crash: The first book is almost mind-wrenchingly slow in its characterization of an earth thrown back to the dark ages; the second part picks up speed as technological inventions are introduced, throwing us hundreds of years into a new middle-ages; and finally the third book, as mankind reaches the culmination of a new "modern civilization".
Brother Francis may seem "deliberately dumb or obtuse", but consider that he lives in a world that precedes your mindset by more than a thousand years. You have the benefit of hindsight as well as a modern education.
There's one thing that few people mention when comparing Linux with Unix, and it's the prime reason why most big companies (eg., Fortune 200) aren't even considering Linux yet:
In hacker terms, it's somebody you can sue if something goes wrong.
In legal terms, it's a liable party -- a legal counterpart whom you can hold responsible for defects. With Linux there's no such thing; there is no "Linus, Inc." You can't sue Red Hat if there are bugs in the kernel. You can sue Compaq or Sun or HP or whomever if their Unix products (Compaq's Tru64, Sun's Solaris, HP's HP-UX, whatever) fail. Red Hat et al, however, only sell "distributions", and they're not liable for damages.
This admittedly curious artifact might not matter to hackers, but for big companies that's the number one. Here's an example: A friend of mine works for a large commerce institution here in Norway, and essentially he told me they'd benched an untuned, default installation of Sybase ASE 11.4 (the free, 10-user-or-so Linux version that you can download) on a well-tuned Linux box (a well-specced PII), comparing it to a well-tuned, commercial Sybase installation on an extremely well-specced, extremely expensive HP-UX box. I can't vouch for their testing skills, but the benching scripts did something like insert 100,000 random records into a table, then manipulated them. While HP-UX is a pretty high-end, high-performing OS, the Linux box proved about 10 times as fast in the tests. This was on inexpensive hardware, but equally significant is the fact that Sybase licenses on Linux are iirc about half the price of that of other platforms. So moving to Linux would save lots of bucks and give them a tenfold speed increase. And still this company said no. No Linux for production servers. Why? They needed a liable party.
Thankfully, things are changing with vendors such as IBM -- and, I think, SGI (can anybody confirm this?) -- becoming full-fledged Linux system supporters. Ironically, even HP is providing Linux support engineers nowadays.
The difference between merely preinstalling Linux on machines (which IBM, Dell, etc. all currently provide) and selling Linux-based systems might not be much more than a subtle difference in semantics, but for large companies, this is the alpha and the omega, the yin and the yang, and the difference between relying on Linux, and merely using it.
Sometimes, as the adoption of Windows so prominently illustrates, politics is all that matters.
The VCL wraps the native controls. The VCL wrapper control classes themselves are, unlike the MFC, fairly generic. Examine the decls and you'll find there's little there that tells you this is Windows, or even ties you to Windows. Generally speaking, the internals can be swapped out for something Linux-specific.
Delphi does not support or use the MFC directly. The Common Controls API on Win32 may be implemented using the MFC, but this stands for most MS GUI systems, including Windows itself. Delphi's VCL wraps this API in a generic way, with few references to the underlying wiring -- which makes it fairly portable.
The real problem of porting a Delphi app -- bar WINE or WINElib or any other compatibility layer, heaven forbid -- would be the Win32-specific stuff. Within the scope of the VCL, a very real problem is the window message queue. The VCL would need to emulate this system within the context of another OS.
Let's hope that Delphi/C++Builder on Linux will produce native apps.
ky-lix n. pl. <ky-li-kes> 1. a shallow, two-handled drinking cup of ancient Greece, set upon a stem terminating in a foot. Often <cylix.>
Borland/Inprise has a thing about using Greek code names for their betas, such as "Calypso" (Delphi 3), "Allegro" (Delphi 4.02), and "Delphi", which was the code name for Delphi 1.0, a name which people liked so much that Borland stuck to it for the release.
In this case, I very much doubt it has any connection with the KDE. Speculation is tenuous at this point.
As for Zope, it looked to me to be a simpler language than PHP, although powerful. I think it is good for dynamic web pages, but big web apps (such as the sort I create) are out of its scope.
Certainly not. First of all, Zope isn't a language -- Zope's DTML language is just a small component in a large system. You don't even need to use DTML in order to reap Zope's benefits.
Secondly, Zope's strength is its open-ended, object-oriented nature. Comparing Zope to PHP is largely meaningless. PHP is a preprocessor; Zope is a middleware platform. Zope has been specifically tailored for enormous, complex, high-volume web systems.
With the recent introduction of the Zope Enterprise Objects (ZEO), which will let you set up multiple object database servers that may mirror their data through replication, Zope grows to even higher planes of scalability and capacity. Combine ZEO with round-robin DNS and you have a good load-balanced failover solution.
A little research into what Zope really is might have helped. You're just spreading disinformation.
> NT is an interesting design, but I'm not sure I'd call it a "microkernel" - more of a hybrid.
Right. The technical term is, I believe, "modified microkernel". Since the NT kernel system services share the same process (ntoskrnl.exe), their intercommunication is in-process, obviating the need for the message protocol-type cross-process communication used by typical microkernel designs. Apparently this was done for ease and performance:
A disadvantage to pure microkernel design is slow performance. Every interaction between operating system components in microkernel design requires an interprocess message. For example, if the Process Manager requires the Virtual Memory Manager to create an address map for a new process, it must send a message to the Virtual Memory Manager. In addition to the overhead costs of creating and sending messages, the interprocess message requirement results in two context switches: the first from the Process Manager to the Virtual Memory Manager, and the second back to the Process Manager after the Virtual Memory Manager carries out the request.
NT takes a unique approach, known as modified microkernel, that falls between pure microkernel and monolithic design. In NT's modified microkernel design, operating system environments execute in user mode as discrete processes, including DOS, Win16, Win32, OS/2, and POSIX (DOS and Win16 are not shown in Figure 1). The basic operating system subsystems, including the Process Manager and the Virtual Memory Manager, execute in kernel mode, and they are compiled into one file image. These kernel-mode subsystems are not separate processes, and they can communicate with one another by using function calls for maximum performance. NT's user-mode operating system environments implement separate operating system APIs. The degree of NT support for each environment varies, however. Support for DOS is limited to the DOS programs that do not attempt to access the computer's hardware directly. OS/2 and POSIX support stops short of user-interface functions and the advanced features of the APIs. Win32 is really the official language of NT, and it's the only API Microsoft has expanded since NT was first released.
NT's operating system environments rely on services that the kernel mode exports to carry out tasks that they can't carry out in user mode. The services invoked in kernel mode are known as NT's native API. This API is made up of about 250 functions that NT's operating systems access through software-exception system calls. A software-exception system call is a hardware-assisted way to change execution modes from user mode to kernel mode; it gives NT control over the data that passes between the two modes.
(from Inside NT Architecture, Mark Russinovich, Windows NT Magazine, March-April 1998).
See http://www.sysinternals.com/ntdll.htm and Mark Russinovich' other publications here: http://www.sysinternals.com/publ.htm (Note: Unfortunately this page simply points to Windows NT Magazine's article database, which requires a valid subscription to view. If you can overlook the often ignorant, opinionated, partial, pro-NT, pro-Microsoft editorial content -- it's nowhere near the Nazi attitude of the amateurish "Dr. Dobbs"-wannabe Windows NT Systems Journal -- the subscription is almost worth the price, I think).
Slashdot Mirror
Hello? That's the whole point. Sure, American citizens have credit cards that can be used in stores and for purchasing stuff online -- but they have no easy, consistent way of sending money to each other.
That's why a company like PayPal can exist in the US. In many European countries, PayPal is mostly obsolete.
Within Norway, you can wire money to anybody with a bank account, regardless of which bank I, or they, use. To pay bills, I go online to my bank's Internet service, enter the account number of the person to transfer to, the amount, and the date at which the transaction should execute. Setting up recurring payments is also possible. Transferring between countries is also quite simple using the SWIFT system.
Now, I can appreciate why PayPal appeals to Americans, if only as a temporary stopgap until all your banks allow sending money to each other. In the meantime, my American friends keep "writing checks". Sheesh. Welcome to the future, guys :)
(I once cashed an American check in my home country. It took one month to clear, and the intermediates took a huge bite out of the total amount. Next time I used SWIFT and it took three days and the money were more or less intact.)
As an aside, PayPal only works with American credit cards. I am currently in the US, and in a recent eBay payment my Norwegian credit card was rejected because they could not verify the billing address (and there was no country field available for the billing address). I have also totally failed to buy stuff from MassMerchandise, where they consider my Norwegian email address to be "high risk" (duh!) and their billing-address verification system has problems even verifying American cards.
The real solution for the future is WebDAV (and being worked on by the W3C), which fully supports named servers and authentication, and is designed to replace FTP and the various ugly "web posting" systems out there, including the uploading aspects of FrontPage Extensions.
Notably WebDAV implementations include Zope and mod_dav for Apache.
The article is a good read, explaining the rationale behind their choice of Linux, and comparing their experience to NT, Digital UNIX and other platforms. (There's even the gratuitous server-room shot, looking very much like a 90s version of the "Mother" computer room in Alien -- probably the same picture you saw.)
However, my understanding is that the Windows domain client components do not use ADSI, but rather are hardwired to use Active Directory. Therefore, a Windows client will not be able to use a different directory service than AD for domain authentication and configuration management.
If Microsoft permitted this, they would effectively be saying, "Sure, you can replace your Win2k server with a Novell box, or a Linux box, or anything that speaks LDAP." They can't afford to give users that flexibility, or Win2k Server would not sell.
In other words, simply having a "Linux ADSI provider" does not help. I am not saying it's not possible -- I am sure that hackers will eventually be able to duplicate AD in an open-source product, just like Samba duplicated NT4's SMB/RPC/SAM stuff -- just that this ain't it.
(Also, I do not believe those links you included are exactly what you think they are. They seem to be libraries to help porting Windows-based ADSI apps to Linux.)
Also, ADSI is an abstraction layer over directory services implemented as COM servers, not an pluggable authentication layer -- that's would be the SSPI (Security Service Provider Interface).
(I would like to add that SSPI and the crypto APIs in Windows are, while complex, two well-designed APIs. Probably the accidental work of some summer interns.)
Late binding and RTTI have nothing to do with it. Um, thank you for so courteously implying that I don't know my C++. I have clocked about four years more experience with C++ (back to the time where there was a draft standard that didn't look much like what we have now) than Java.
C++ does not have an ABI. You can't argue against that.
C++ is hellishly unsuited to sharing and using component-like objects. And templates and operator overloading and other tricks do not work across process boundaries. With C++ you end up reinventing Java to do anything useful -- sharing objects, managing memory, and dynamically loading functionality.
To turn the concept around, can you foresee an alternate universe where JINI is written in C++? :)
Just because Hypersonic, JDataStore and all the others don't fit your definition of an RDBMS doesn't mean they can't, or that such beasts can't be written (as practical, competetive solutions).
You didn't answer my question, though. What makes a language an "application language" versus a "system/platform language"?
If you can write operating systems in Java (and this Slashdot article implies you can), why not a relational database? In fact, I can't think of a single major OS that was written in C++. Even BeOS is apparently all ANSI C below its high-level application framework.
In fact, I am arguing that Java is particularly suited to systems programming, simply because it leverages OO principles to a higher level in the same way that C++ drags you down to the bottom. Garbage collection and class loading and object sharing can all be added to C++ post-mortem, but once you have dealt for a few months with home-grown reference-counting template classes, strings that can't painlessly box/unbox char*s, and other wrapping stuff that is supposedly so transparent and flexible and elegant, you really wish these things are first-class citizens in your country of residence.
C++ has its good sides, but Java often puts it to shame.
Consider a program you write. You have got all these classes and things. You compile and release. All the information about your program is now embedded implicitly in your program. There's no way for me to take any of those classes and reuse them. That's a dead end.
C++ is very binary-oriented: If I write a web server and servlet framework in C++, then the only viable way for servlets to communicate with the server is through some sort of well-defined binary interface, say DLLs/shared objects or RPC or CORBA or DCOM. Or on a source-code level. I would have to recompile the server each time I added a servlet. Does C++ need an ABI? I don't know. It would have to cover a lot more than just classes.
One of Java's best assets is its notion of dynamic class loading, which could just as easily be done in a native-binary model, although the use of bytecode makes Java's approach more flexible, more adaptive, and of course logistically simpler for porting purposes.
C++ could have had this, but I tend to believe that it has too much crust -- from the preprocessor and reliance on include files and defines, to templates, to its object model (one of my major hassles with C++ is that two classes cannot contain automatic [ie., non-pointer] members of each others' types, because for one of the classes, the other class will be "unfinished" at the point of declaration) -- that does not make the language as suitable for opening up.
I don't buy your argument about system/platform language vs. application language. Plenty of people have successfully implemented forms/servlets in C++ and RDBMS or similar things in Java. What's your point? That Java is too heavyweight or bloated for that sort of thing? Requires a large runtime, what? What makes a language an "application language" versus a "system/platform language"?
As for Ruby, I remember looking briefly at it once and being befuddled by its syntax, but thanks for the reminder -- will check it out again. Are libraries plentiful? Does it connect well with other languages?
Standardized (albeit by Sun), extensible APIs, especially on the server end, and extensible products, is part of what makes Java thrive today. Transaction API, J2EE, JNDI, Java2D/imaging, Java3D, servlets, JDBC, CORBA. Plus a host of pre-packaged libraries for things like sockets and RMI. Products: object databases (Ozone, the Castor O/R mapping framework), transaction managers (Tyrex), web servers (Resin, Jetty, Orion, Enhydra), XML etc.
Above all, Java connect to anything, provides a lot of freebies (garbage collection, a simple object model), is high-level and easy to learn, and lets you be more productive right out of the box as opposed to languages such as C++. No wonder new stuff is sprouting up like mushrooms -- a phenomenon that I suppose Bjarne Stroustrup is mildly annoyed about and doesn't quite understand. Once you've written a C++ app, it's a dead end. It not reusable. Unless you wired it up with magical strings and CORBA and reinventing all sorts of technologies, it just sits there.
This is much the same reason Python is thriving, really. Unfortunately, Java currently does not have anything that comes close to Zope. Turbine and Cocoon sound like two different projects aimed at this area, but they're not even close.
Who cares about Amex or set-top boxes? Unless I can write TiVo-like apps on my desktop computer that controls the box in interesting and hitherto-unrealized ways, it's useless, just another closed implementation. And Amex, well, how do I connect to my card, then?
Now:
I wish you hadn't mentioned that. Oracle's bloated, clunky Java GUI stuff is their big black sheep. I wish they never screwed this part up -- Oracle's native NT tools used to be at least adequate. Compare Oracle's present, slow, unstable, overdesigned, Microsoft Bob-like Java GUIs with Microsoft SQL Server 7.0's flashy, fast, and hugely functional tools and you just want to crawl into your mama's arms and cry like a baby.
Servlets is hardly Java's finest moment, same goes for JSP. True, servlets replace CGI in a nice way, and anything is better than ASP and assorted horrors, but that's about it.
Servlets make up a very low-level layer, and servlets themselves are quite isolated entities, compared to the riches of Zope's DTML documents.
Please, developers, do yourselves a favour and read up on how to properly divide content, logic, and presentation. Hint: Putting Java inside HTML gives you no cigar. Look instead at things like Freemarker and Webmacro, or even that bastard son of template processing, XSLT. Even so, these are quite weak tools, and you need to buy a $35,000-per-CPU app server to get any sense of an integrated package.
End of rant.
Even taking shoddy engineering into consideration, that's pretty bloated -- compared to Flash plug-in (actually, ActiveX control) which is about 150KB.
However, it will never reduce the animation file size down to Flash's extreme bit-tweaked precision (see the Flash format specification for all the tricks they use to reduce size; they sensibly apply dictionary compression techniques to avoid repetition in the data), which is the first reason why we would want an SVG-specific compression algorithm. I have written a conversion tool for turning Flash into XML and back, and there is no reason why a binary representation of [parts of] SVG could not exist.
The talk so far of compression has ignored something extremely central to Flash, which is streaming. Streaming is what made Flash the popular format and product it is today.
In order to compress SVG and still support streaming we would need a multi-part compression system and/or add another XML layer that can hold compressed SVG frame batches as CDATA elements.
Finally, you don't cite your resolution and pixel depth, which affects the size of the PNG file you're comparing to, so your data point doesn't make much sense.
"The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place." (Douglas Adams)
Actually, the iPAQ is based on the operating system formerly known as Windows CE. It uses a 206MHz StrongARM processor. Here's a picture and the specs.
It's an idea that has been used before -- particularly in British SF writer Robert Rankin's The Brentford Chainstore Massacre . The book is not about cloning just one Jesus. The (very mad) scientist in question clones a whole bunch of them. Of course, little goes exactly according to plan. Good book, not Rankin's best, but still a great read, with a typically high chuckle factor.
A year ago or so, a little after Rankin's book came out, an award-winning [for the documentary The Silent Witness: An Investigation into the Shroud of Turin (1982)] British producer named David W. Rolfe announced he was going to produce a film about -- guess what -- Jesus being cloned from the Turin shroud.
So, Jesus Park anyone?
Not so fast. CE is being used today precisely for use in network computers. Many vendors are currently selling cheap CE-based NCs that connect to Windows NT Terminal Server (now built into into Win2k Server, and no longer a separate product). It's not particularly original, but apparently it works.
Aside from the fact that Terminal Server requires a *stupendous* amount of horsepower (RAM, CPU, motherboard, disk system) to run well with many users, this is, in fact, a great solution -- we're evaluating it for our office, as we find it somewhat pointless to have many employees, who only browse the net and use the same productivity/email apps, sit with $3,000 PCs when they can each connect from $400 terminals to a $10,000 terminal server.
This Windows 2000 Magazine article explains the system in detail.
Put simply, SIS was designed for NT administrators for the purpose of cloning OS installations to client desktops. With NT 4.0, you're forced to use a third-party disk imaging tool, or use NT's "unattended setup" mode where the installation program installs NT from a script. In large corporations, admins often roll out hundreds or thousands of identical NT installations, and even with just a few copies this process is a huge pain. (I'm saying this as a human being, not as an NT admin. I prefer Linux.)
With Windows 2000, however, you use the Remote Install Server software, which is set up to host all the images you want to copy to desktops -- for example, you can create an image containing a stripped-down NT with Internet Explorer and DHCP client; and another image containing an installation tailored to laptop use. Additionally (as I understand it), the RIS software generates a boot disk containing network drivers and the stub code to load the image from the RIS server.
However, when Microsoft designed this software, they discovered that images take up a lot of disk space -- and that the most of the files are repeated files through the images.
The solution, SIS, is a background service that employs a piece of code amusingly called the "groveler" to scan designated parts of your NTFS volumes. Duplicate files are moved to a special, hidden, top-level system folder called the "SIS Common Store", and a symbolic link (which Win2000 calls junctions) is left behind pointing to the actual file.
It's worth pointing out that SIS was not originally designed to work as an all-purpose, automatic symlinker. Since files are physically moved to a special location on each disk, it could potentially wreak havoc with backup software, as well be extremely confusing to users and admins alike. You can set up SIS for all your files, but none of my documentation indicates that this is particularly wise -- also, there is little to gain from "compressing" regular volumes this way.
NT has had numerous issues about system processes and apps leaking memory while running. This is different, though.
If you manage to run an NT box for more than 14 days -- and some people do -- then you might experience a different kind of "leak": The build-up of strange, inexplicable crust-like matter that slowly sticks into the cracks of the system -- a kind of electronic, cholestrerol-like kipple. You feel it, but you can't pin it down. Reboot the machine and it starts up fresh and strangely more agile.
Some have pointed out that NT has problems with memory fragmentation. I have not seen any solid evidence of this. Whatever it is, Linux ain't got it.
In his visionary novel, set in a dystopian, post-apocalyptic future, live animals are mostly extinct, and artificial (designed and genetically engineered, although not robotic) animals and humans exist as luxury objects.
It's ironic and sad that we keep looking for, and hoping to discover, life on other planets, when at the same time we're eliminating those on our own. Someday, as spaceships probe planet after planet for life in remote galaxies and come up emptyhanded, and we realize how special and precious our little ecological fluke of a planet is, we will understand this better. Until then we're doomed to shoot ourselves in our feet, collectively, and unknowingly.
Perhaps one day we'll learn to develop such artificial creatures complex enough to serve as substitutes for the real kind, and we'll forget about the real ones. As human settlements expand (and they do), we'll eventually overrun the animal kingdom, which already has a large number of endangered species.
I suspect that, sometime in the future, not too far off, we will have ceased to look upon the idea of a robotic animal only as a quaint, cute, and practical toy with a convenient "off" button, but as the only available alternative. Welcome to a penguin-less future.
The book is a gold mine of literary pleasures.
Notice, for example, how the tempo of each book is deliberately chosen as time and technology progress, hand in hand -- like a train pushing gradually towards an inevitable crash: The first book is almost mind-wrenchingly slow in its characterization of an earth thrown back to the dark ages; the second part picks up speed as technological inventions are introduced, throwing us hundreds of years into a new middle-ages; and finally the third book, as mankind reaches the culmination of a new "modern civilization".
Brother Francis may seem "deliberately dumb or obtuse", but consider that he lives in a world that precedes your mindset by more than a thousand years. You have the benefit of hindsight as well as a modern education.
In hacker terms, it's somebody you can sue if something goes wrong.
In legal terms, it's a liable party -- a legal counterpart whom you can hold responsible for defects. With Linux there's no such thing; there is no "Linus, Inc." You can't sue Red Hat if there are bugs in the kernel. You can sue Compaq or Sun or HP or whomever if their Unix products (Compaq's Tru64, Sun's Solaris, HP's HP-UX, whatever) fail. Red Hat et al, however, only sell "distributions", and they're not liable for damages.
This admittedly curious artifact might not matter to hackers, but for big companies that's the number one. Here's an example: A friend of mine works for a large commerce institution here in Norway, and essentially he told me they'd benched an untuned, default installation of Sybase ASE 11.4 (the free, 10-user-or-so Linux version that you can download) on a well-tuned Linux box (a well-specced PII), comparing it to a well-tuned, commercial Sybase installation on an extremely well-specced, extremely expensive HP-UX box. I can't vouch for their testing skills, but the benching scripts did something like insert 100,000 random records into a table, then manipulated them. While HP-UX is a pretty high-end, high-performing OS, the Linux box proved about 10 times as fast in the tests. This was on inexpensive hardware, but equally significant is the fact that Sybase licenses on Linux are iirc about half the price of that of other platforms. So moving to Linux would save lots of bucks and give them a tenfold speed increase. And still this company said no. No Linux for production servers. Why? They needed a liable party.
Thankfully, things are changing with vendors such as IBM -- and, I think, SGI (can anybody confirm this?) -- becoming full-fledged Linux system supporters. Ironically, even HP is providing Linux support engineers nowadays.
The difference between merely preinstalling Linux on machines (which IBM, Dell, etc. all currently provide) and selling Linux-based systems might not be much more than a subtle difference in semantics, but for large companies, this is the alpha and the omega, the yin and the yang, and the difference between relying on Linux, and merely using it.
Sometimes, as the adoption of Windows so prominently illustrates, politics is all that matters.
The VCL wraps the native controls. The VCL wrapper control classes themselves are, unlike the MFC, fairly generic. Examine the decls and you'll find there's little there that tells you this is Windows, or even ties you to Windows. Generally speaking, the internals can be swapped out for something Linux-specific.
The real problem of porting a Delphi app -- bar WINE or WINElib or any other compatibility layer, heaven forbid -- would be the Win32-specific stuff. Within the scope of the VCL, a very real problem is the window message queue. The VCL would need to emulate this system within the context of another OS.
Let's hope that Delphi/C++Builder on Linux will produce native apps.
1. a shallow, two-handled drinking cup of ancient Greece, set upon a stem terminating in a foot. Often <cylix.>
Borland/Inprise has a thing about using Greek code names for their betas, such as "Calypso" (Delphi 3), "Allegro" (Delphi 4.02), and "Delphi", which was the code name for Delphi 1.0, a name which people liked so much that Borland stuck to it for the release.
In this case, I very much doubt it has any connection with the KDE. Speculation is tenuous at this point.
Certainly not. First of all, Zope isn't a language -- Zope's DTML language is just a small component in a large system. You don't even need to use DTML in order to reap Zope's benefits.
Secondly, Zope's strength is its open-ended, object-oriented nature. Comparing Zope to PHP is largely meaningless. PHP is a preprocessor; Zope is a middleware platform. Zope has been specifically tailored for enormous, complex, high-volume web systems.
With the recent introduction of the Zope Enterprise Objects (ZEO), which will let you set up multiple object database servers that may mirror their data through replication, Zope grows to even higher planes of scalability and capacity. Combine ZEO with round-robin DNS and you have a good load-balanced failover solution.
A little research into what Zope really is might have helped. You're just spreading disinformation.
Right. The technical term is, I believe, "modified microkernel". Since the NT kernel system services share the same process (ntoskrnl.exe), their intercommunication is in-process, obviating the need for the message protocol-type cross-process communication used by typical microkernel designs. Apparently this was done for ease and performance:
- A disadvantage to pure microkernel design is slow performance. Every interaction between operating system components in microkernel design requires an interprocess message. For example, if the Process Manager requires the Virtual Memory Manager to create an address map for a new process, it must send a message to the Virtual Memory Manager. In addition to the overhead costs of creating and sending messages, the interprocess message requirement results in two context switches: the first from the Process Manager to the Virtual Memory Manager, and the second back to the Process Manager after the Virtual Memory Manager carries out the request.
(from Inside NT Architecture, Mark Russinovich, Windows NT Magazine, March-April 1998).NT takes a unique approach, known as modified microkernel, that falls between pure microkernel and monolithic design. In NT's modified microkernel design, operating system environments execute in user mode as discrete processes, including DOS, Win16, Win32, OS/2, and POSIX (DOS and Win16 are not shown in Figure 1). The basic operating system subsystems, including the Process Manager and the Virtual Memory Manager, execute in kernel mode, and they are compiled into one file image. These kernel-mode subsystems are not separate processes, and they can communicate with one another by using function calls for maximum performance. NT's user-mode operating system environments implement separate operating system APIs. The degree of NT support for each environment varies, however. Support for DOS is limited to the DOS programs that do not attempt to access the computer's hardware directly. OS/2 and POSIX support stops short of user-interface functions and the advanced features of the APIs. Win32 is really the official language of NT, and it's the only API Microsoft has expanded since NT was first released.
NT's operating system environments rely on services that the kernel mode exports to carry out tasks that they can't carry out in user mode. The services invoked in kernel mode are known as NT's native API. This API is made up of about 250 functions that NT's operating systems access through software-exception system calls. A software-exception system call is a hardware-assisted way to change execution modes from user mode to kernel mode; it gives NT control over the data that passes between the two modes.
See http://www.sysinternals.com/ntdll.htm and Mark Russinovich' other publications here: http://www.sysinternals.com/publ.htm (Note: Unfortunately this page simply points to Windows NT Magazine's article database, which requires a valid subscription to view. If you can overlook the often ignorant, opinionated, partial, pro-NT, pro-Microsoft editorial content -- it's nowhere near the Nazi attitude of the amateurish "Dr. Dobbs"-wannabe Windows NT Systems Journal -- the subscription is almost worth the price, I think).